Detect: Erkennungs- und Monitoring-Fähigkeit gezielt aufbauen

Problem in der Praxis

In vielen Organisationen ist Erkennung ein Nebenprodukt vorhandener Technik statt eine bewusst gebaute Fähigkeit. Es werden viele Logs gesammelt, weil Systeme sie ohnehin erzeugen, aber niemand hat definiert, welches Angriffsverhalten damit erkennbar sein soll. Das Ergebnis ist ein teures Datengrab: hohe Speicher- und Lizenzkosten, aber blinde Flecken genau dort, wo es zählt.

Ein zweites Muster ist die Alarmflut ohne Aussage. Eine ungepflegte Regelbasis erzeugt Tausende Meldungen, von denen die meisten Fehlalarme sind. Analysten gewöhnen sich daran, Warnungen wegzuklicken, und der eine relevante Alarm geht im Rauschen unter. Erkennung scheitert dann nicht an fehlenden Daten, sondern an fehlender Triage und Pflege.

Drittens fehlt oft der Bezug zwischen Erkennung und Abdeckung. Niemand kann sagen, welche Angriffstechniken auf welchen kritischen Systemen überhaupt erkennbar wären. Ohne diese Landkarte bleibt Detektion eine Sammlung von Einzelregeln statt einer steuerbaren Fähigkeit mit bekannten Lücken.

CISO-Einordnung

Detect ist im CSF 2.0 mit zwei Categories eine der kompakteren Functions, aber operativ eine der anspruchsvollsten. DE.CM steht für das fortlaufende Beobachten von Netzen, Systemen, Identitäten, physischer Umgebung, Personal und externen Dienstleistern, um potenzielle Schadereignisse sichtbar zu machen. DE.AE steht für die Analyse dieser Beobachtungen: Anomalien charakterisieren, korrelieren, Auswirkung und Umfang abschätzen und entscheiden, ob ein Vorfall vorliegt. Erst diese Analyse macht aus einem Signal eine Entscheidungsgrundlage und übergibt sie an die Function Respond (RS).

Die Tiefe liefert der Kontrollkatalog SP 800-53 Rev. 5 (Public Domain). Die Erkennungsfähigkeit ruht im Wesentlichen auf zwei Familien: Audit and Accountability (AU) und System and Information Integrity (SI). AU-2 entscheidet, welche Ereignisse protokolliert werden, AU-3 regelt den Inhalt, AU-12 die Erzeugung, AU-6 die Auswertung und Berichterstattung der Audit-Daten. SI-4 (System Monitoring) ist die zentrale Detektionsklammer, mit Erweiterungen für Echtzeitanalyse (SI-4(2)) und die Beobachtung ein- und ausgehenden Verkehrs (SI-4(4)). Ergänzend liefern RA-5 (Vulnerability Monitoring and Scanning) Expositionsdaten und IR-5 (Incident Monitoring) den Brückenschlag in die Vorfallsbearbeitung (IR-4).

Wesentlich ist die Abgrenzung zu ISCM. Die CSF-Category DE.CM heißt Continuous Monitoring, und NIST hat mit SP 800-137 eine eigene Disziplin namens Information Security Continuous Monitoring (ISCM), im Katalog verankert durch CA-7. Beide klingen identisch, beantworten aber verschiedene Fragen. ISCM (CA-7, SP 800-137; ausführlich in nist-ops-007) ist ein Governance- und Assurance-Kreislauf: Sind unsere Kontrollen weiterhin wirksam und ist die Risikolage akzeptabel? Es überwacht das Sicherheitsprogramm selbst und speist den RMF-Schritt Monitor (SP 800-37). Detect (DE.CM/DE.AE, gestützt auf SI-4 und AU) ist dagegen eine operative Erkennungsfähigkeit: Findet gerade ein Angriff statt? Beide nutzen oft dieselbe Telemetrie, ziehen daraus aber unterschiedliche Schlüsse: ISCM beurteilt die Gesundheit der Controls, Detect die Anwesenheit eines Angreifers. CSF 2.0 ist dabei outcome-orientiert und nicht im ISO-Sinn zertifizierbar.

Umsetzungsperspektive

Eine belastbare Erkennungsfähigkeit entsteht use-case-getrieben, nicht datengetrieben. Der Einstieg ist nicht die Frage "Welche Logs haben wir?", sondern "Welche Angriffsszenarien müssen wir auf unseren kritischen Systemen erkennen können?". Aus diesen Use Cases leitet sich ab, welche Ereignisse zu protokollieren sind (AU-2/AU-3), welche Sensorik nötig ist (SI-4) und welche Korrelationslogik die Schadereignisse herausfiltert (DE.AE).

Detection Engineering behandelt Detektionsregeln wie Software mit Lebenszyklus: ableiten, testen, in Betrieb nehmen, gegen simulierte Aktivität validieren, pflegen und bei Bedarf stilllegen. Dazu gehören bewusste Baselines für "normal", damit Abweichungen auffallen, sowie eine Abdeckungskarte, die zeigt, welche Techniken auf welchen Assets erkennbar sind und wo Lücken bestehen.

Wenige steuerungsrelevante Kennzahlen tragen mehr als ein überladenes Dashboard:

• Abdeckung: Anteil kritischer Assets und priorisierter Angriffstechniken mit aktiver, getesteter Detektion.
• Reaktionszeit: Mean Time to Detect, getrennt nach Kritikalität und Exponierung.
• Qualität: Fehlalarmquote und Anteil der Alarme, die zu einer Triage-Entscheidung führen.
• Wirksamkeit: Quote bestandener Detektionstests gegen simulierte Angriffe.

Voraussetzung ist ein verlässliches Asset-Inventar aus der Function Identify, denn was nicht inventarisiert ist, kann nicht überwacht werden.

Typische Fehler

1. Datengetrieben statt use-case-getrieben loggen: alles sammeln, ohne zu definieren, was erkannt werden soll. Das erzeugt Kosten und blinde Flecken zugleich.
2. Erkennung als Tool-Kauf missverstehen. SIEM, EDR oder XDR liefern Bausteine, aber die Fähigkeit entsteht erst durch gepflegte Use Cases und Analyse.
3. Regelbasis nicht pflegen: Fehlalarme akkumulieren, Analysten stumpfen ab, der relevante Alarm verschwindet im Rauschen.
4. DE.CM mit ISCM verwechseln und Erkennungsleistung mit Wirksamkeitsmessung der Controls vermengen.
5. Erkennung ohne Reaktion: Anomalien werden detektiert, aber es fehlt der definierte Pfad zur Analyse (DE.AE) und Übergabe an Respond.
6. Abdeckung nie messen: Ohne Landkarte erkennbarer Techniken bleiben Lücken unsichtbar und werden durch gute Einzelregeln kaschiert.

Risiken und Trade-offs

Erkennung erzeugt einen Dauerkonflikt zwischen Sensitivität und Belastbarkeit. Zu empfindliche Regeln produzieren Alert Fatigue und binden knappe Analystenkapazität, zu grobe Regeln übersehen echte Angriffe. Die richtige Schwelle ist kein technisches, sondern ein Risikoabwägungsproblem.

Ein zweiter Trade-off betrifft Datenmenge gegen Aussagekraft: Mehr Logs und längere Aufbewahrung erhöhen forensische Tiefe und Kosten gleichermaßen, verbessern die Erkennung aber nur, wenn die Daten an Use Cases gebunden sind. Drittens kollidiert umfassende Überwachung von Identitäten, Endpunkten und Verkehr mit Datenschutz- und Mitbestimmungsanforderungen; die Beobachtung von Personal und Kommunikation ist rechtlich einzubetten. Schließlich verfällt eine einmal gebaute Detektion, wenn sich Umgebung und Angriffstechniken weiterentwickeln und niemand die Regeln nachzieht.

Entscheidungspunkte

• Welche Angriffsszenarien auf welchen kritischen Assets müssen wir mit hoher Sicherheit erkennen können?
• Welche Ereignisse loggen wir bewusst, in welcher Tiefe und wie lange, gemessen an Erkennungsnutzen statt an technischer Verfügbarkeit?
• Wie messen wir Erkennungsleistung, und wer verantwortet Abdeckung, Reaktionszeit und Fehlalarmquote?
• Wie trennen wir Detektionsbetrieb (SI-4/AU, DE.CM/DE.AE) sauber vom Wirksamkeitsmonitoring der Controls (CA-7, ISCM)?
• Wie ist die Übergabe einer bestätigten Analyse an die Vorfallsbearbeitung (Respond) definiert und geübt?

Praktische Empfehlungen

1. Bauen Sie Erkennung use-case-getrieben: zuerst priorisierte Angriffsszenarien definieren, daraus Logging (AU-2/AU-3) und Monitoring (SI-4) ableiten.
2. Etablieren Sie Detection Engineering als Lebenszyklus mit Test, Validierung und Pflege der Regeln statt einmaliger Konfiguration.
3. Steuern Sie mit wenigen Kennzahlen: Abdeckung kritischer Assets und Techniken, Mean Time to Detect, Fehlalarmquote, bestandene Detektionstests.
4. Halten Sie eine Abdeckungskarte, die erkennbare und nicht erkennbare Techniken sichtbar macht, und behandeln Sie Lücken als Risiken.
5. Trennen Sie Erkennung (DE.CM/DE.AE, SI-4/AU) konzeptionell von ISCM (CA-7, SP 800-137, siehe nist-ops-007), auch wenn beide dieselbe Telemetrie nutzen.
6. Definieren und üben Sie die Übergabe von DE.AE an Respond, abgestimmt mit der Incident-Response-Logik aus SP 800-61 Rev. 3.

Relevante Normreferenzen

• NIST CSF 2.0 (NIST.CSWP.29, 26.02.2024): Function Detect (DE) mit den Categories DE.CM (Continuous Monitoring) und DE.AE (Adverse Event Analysis). Public Domain.
• NIST SP 800-53 Rev. 5: Familien Audit and Accountability (AU, u. a. AU-2, AU-3, AU-6, AU-12) und System and Information Integrity (SI, u. a. SI-4 mit Erweiterungen); ergänzend RA-5 und IR-5/IR-4. Public Domain.
• NIST SP 800-53 Rev. 5: CA-7 (Continuous Monitoring) als Brücke zu ISCM und Abgrenzung zur Detektion. Public Domain.
• NIST SP 800-137: Information Security Continuous Monitoring (ISCM) als abzugrenzende Disziplin; vertieft in nist-ops-007. Public Domain.
• NIST SP 800-37 (RMF): Risk Management Framework mit dem Schritt Monitor, an den ISCM (CA-7) anschließt; zur Abgrenzung von der operativen Detektion. Public Domain.
• NIST SP 800-61 Rev. 3: Incident Response als CSF-2.0-Community-Profile, Bewältigung über Detect/Respond/Recover. Public Domain.