Beispiele sind Ködersysteme, -dienste, -zugangsdaten, -datensätze, -dateien oder -links, die legitime Benutzer und Produktionsprozesse nicht benötigen sollten. Eine Interaktion kann Gegnerverhalten oder defensive Lücken offenbaren.
Ein Deception-Programm beginnt mit Zielen und Bedrohungsmodellierung, nicht mit einer Produktkategorie. Designer entscheiden, wer darauf stoßen darf, was es auslösen soll, wie es eingedämmt wird, welche Beweise gesammelt werden und wie Responder handeln.
Wichtigste Punkte
DesignKöder plausibel machen, von Produktion unterscheiden, ihre Privilegien und Daten einschränken und verhindern, dass sie zu Angriffsinfrastruktur werden.
BetriebInteraktion und Zustand überwachen, Verwaltungspfade schützen, Eigentümerschaft dokumentieren, Reaktionsworkflows testen, Artefakte rotieren und veraltete Köder sicher außer Betrieb nehmen.
GovernanceAutorisierung, Sammlungszweck, Aufbewahrungs- und Zugriffsregeln, erforderliche Hinweise, rechtliche, Datenschutz- und Sicherheitsprüfung sowie Eskalationsregeln vor dem Einsatz definieren.
Wichtige EinschränkungEin Deception-Alarm ist nicht automatisch Beweis eines externen Angreifers, und Stille beweist keine fehlende Kompromittierung. Fehlkonfiguration, Scanner, Insider oder legitime Automatisierung können Köder auslösen; erfahrene Gegner können sie erkennen, meiden oder missbrauchen.