Dies ist der f\u00fcnfte Beitrag einer Serie \u00fcber\u00a0das Drei-Regeln-Framework\u00a0\u2014 Leerlassen erzwingen, Raten bestrafen, Quelle zeigen. Das Framework wurde bisher auf\u00a0Dokumentextraktion,\u00a0Worldbuilding,\u00a0Szenarioplanung\u00a0und\u00a0Implementierung im Organisationskontext\u00a0angewandt.<\/p>\n
Dieser Beitrag wendet es auf eine Dom\u00e4ne an, in der die Eins\u00e4tze so hoch sind wie kaum anderswo: Cybersecurity.<\/p>\n
Das strukturelle Problem ist bekannt. KI generiert selbstbewusst klingende Sicherheitsbewertungen, die verifizierte Befunde mit Inferenzen und Annahmen vermischen \u2014 und niemand kann unterscheiden, was was ist. Ein Schwachstellen-Scan-Ergebnis steht neben einer architektonischen Inferenz neben einer ungetesteten Annahme \u00fcber Netzwerksegmentierung, alles mit der gleichen Zuversicht pr\u00e4sentiert. Der Output sieht gr\u00fcndlich aus. Manches ist fundiert. Manches wurde erfunden, damit das Narrativ zusammenh\u00e4lt.<\/p>\n
Bei der Szenarioplanung kostet das Planungsressourcen. In der Cybersecurity ist es ein Breach, der darauf wartet zu passieren.<\/p>\n
Ein Survey-Paper von 2025 \u00fcber\u00a0Halluzinationen in KI-gest\u00fctzten Cybersecurity-Systemen<\/a>\u00a0identifiziert das Kernrisiko: KI-Modelle, die auf Sprachfluss optimiert sind, k\u00f6nnen sichere Aktivit\u00e4ten f\u00e4lschlich als Bedrohung einstufen oder tats\u00e4chliche Gefahren \u00fcbersehen \u2014 und tun beides im selben selbstbewussten Ton, unabh\u00e4ngig davon, ob ihre Bewertung evidenzbasiert ist. Das Design-Ziel Sprachfluss vor Genauigkeit verst\u00e4rkt das Problem: Modelle produzieren hochkonfidente Aussagen auch ohne faktische Fundierung.<\/p>\n Die OWASP Foundation listet KI-Halluzination in ihrer Ausgabe 2025 unter den\u00a0Top-Risiken f\u00fcr LLM-gest\u00fctzte Sicherheitstools<\/a>. Das Problem sind nicht isolierte False Positives oder False Negatives \u2014 es ist die Vermischung von realen Befunden und fabrizierten Bewertungen in einem einzigen Output, den Menschen dann als gleichm\u00e4\u00dfig zuverl\u00e4ssig behandeln.<\/p>\n Zwei L\u00fccken-Labels gelten team\u00fcbergreifend:<\/p>\n Die Unterscheidung ist entscheidend. Eine Sichtbarkeitsl\u00fccke bedeutet: Sie haben die Daten nicht. Eine Validierungsl\u00fccke bedeutet: Sie haben die Daten (oder glauben es), aber haben nicht bewiesen, dass die Erkennung tats\u00e4chlich funktioniert. Beides ist gef\u00e4hrlich; es erfordert unterschiedliche Ma\u00dfnahmen.<\/p>\n Die Wahrheitsquelle des Blue Teams ist:\u00a0was \u00fcber die Verteidigungslage durch direkte Evidenz best\u00e4tigt wurde<\/strong>\u00a0\u2014 nicht was die Policy sagt, nicht was der Hersteller verspricht, nicht was wahr sein sollte.<\/p>\n Forschung von\u00a0Mitiga<\/a>\u00a0legt nahe, dass traditionelle SIEMs im Durchschnitt nur etwa 21 % der MITRE ATT&CK-Techniken erkennen \u2014 das hei\u00dft, bei rund vier von f\u00fcnf Technikkategorien gibt es keine validierte Erkennungsabdeckung. Dennoch berichten viele Organisationen deutlich h\u00f6here Coverage-Zahlen, weil sie konfigurierte Regeln z\u00e4hlen statt validierte Erkennungen. Die Kluft zwischen \u201eWir haben eine Regel daf\u00fcr” und \u201eDiese Regel hat bei einem realen Angriff korrekt ausgel\u00f6st” ist genau die Kluft, die das Framework offenlegt.<\/p>\n AttackIQs Analyse vom M\u00e4rz 2026<\/a>\u00a0hat es treffend formuliert: Coverage ist nicht statisch, Umgebungen \u00e4ndern sich, und eine Erkennung, die letzten Monat funktionierte, kann diesen Monat still kaputtgegangen sein. Ein Teilnehmer eines Webinars brachte es auf den Punkt: Erkennungen zu haben bedeutet nichts, wenn sie kein Signal produzieren, auf das das Team reagieren kann.<\/p>\n Du bist ein defensiver Sicherheitsanalyst, der unsere Umgebung \u00fcberpr\u00fcft. Tagge jede Sicherheitsaussage mit ihrer Evidenzbasis:<\/em><\/p>\n \u2022 (VERIFIZIERT) \u2014 best\u00e4tigt durch direktes Testen, Log-Evidenz oder Scan-Ergebnisse. Nenne die konkrete Evidenz.<\/em><\/p>\n \u2022 (POLICY-DOKUMENTIERT) \u2014 in Policy oder Konfigurationsleitf\u00e4den dokumentiert, aber nicht unabh\u00e4ngig validiert. Beschreibe, wie eine Validierung aussehen w\u00fcrde.<\/em><\/p>\n \u2022 (INFERIERT) \u2014 aus indirekten Indikatoren abgeleitet. Nenne die Inferenzkette und was sie ung\u00fcltig machen k\u00f6nnte.<\/em><\/p>\n \u2022 Wenn du eine Kontrolle oder einen Abdeckungsbereich identifizierst, der nicht getestet oder instrumentiert wurde, markiere ihn als [SICHTBARKEITSL\u00dcCKE] oder [VALIDIERUNGSL\u00dcCKE] mit kurzer Erkl\u00e4rung.<\/em><\/p>\n \u2022 Ein falsches Sicherheitsgef\u00fchl ist gef\u00e4hrlicher als eine bekannte L\u00fccke. Eine bekannte L\u00fccke wird budgetiert. Falsches Vertrauen wird gehackt. Im Zweifel markiere die L\u00fccke.<\/em><\/p><\/blockquote>\n
\nDie L\u00fccken-Labels f\u00fcr Cybersecurity<\/h2>\n
\n
[SICHTBARKEITSL\u00dcCKE]<\/code>\u00a0\u2014 etwas, das das Team nicht sehen kann oder nicht instrumentiert hat: un\u00fcberwachte Netzwerksegmente, fehlende Log-Quellen, Schatten-IT, Cloud-Services ohne Telemetrie<\/li>\n[VALIDIERUNGSL\u00dcCKE]<\/code>\u00a0\u2014 eine Kontrolle oder Erkennungsregel, die auf dem Papier oder in der Konfiguration existiert, aber nie gegen tats\u00e4chliches Angriffsverhalten getestet wurde<\/li>\n<\/ul>\n
\nBlue Team: Verteidigung<\/h2>\n
Blue Team Quellen-Tags<\/h3>\n
\n
(VERIFIZIERT)<\/code>\u00a0\u2014 best\u00e4tigt durch direkte Evidenz: getestete Kontrolle, beobachteter Log-Eintrag, validierte Konfiguration, Scan-Ergebnis mit Zeitstempel<\/li>\n(POLICY-DOKUMENTIERT)<\/code>\u00a0\u2014 in Policy, Konfigurationsleitf\u00e4den oder Herstellerdokumentation beschrieben, aber nicht unabh\u00e4ngig validiert<\/li>\n(INFERIERT)<\/code>\u00a0\u2014 aus indirekten Indikatoren abgeleitet. \u201eKeine Alerts in 90 Tagen” hei\u00dft nicht \u201ekeine Einbr\u00fcche in 90 Tagen” \u2014 es k\u00f6nnte hei\u00dfen, die Erkennung funktioniert nicht<\/li>\n<\/ul>\nBlue Team Prompt<\/h3>\n
Blue Team Beispiel-Output<\/h3>\n