SIEM-Erkennungsregeln und Alerts schreiben

Erkennungsregeln sind in einem SIEM codierte Logikdefinitionen, die festlegen, welche Bedingungen einen Sicherheitsalarm auslösen. Ohne gute Erkennungsregeln ist ein SIEM lediglich ein teures System zur Protokollspeicherung. Sorgfältig erstellte Regeln erkennen spezifische Verhaltensweisen von Angreifern – Credential-Stuffing, laterale Bewegungen und Datenexfiltration – und lösen gleichzeitig bei normalen Abläufen keinen Alarm aus. Detection Engineering ist die Disziplin, solche Regeln kontinuierlich zu schreiben, zu testen und zu pflegen.

Jede Erkennungsregel besteht aus wichtigen Komponenten. Eine Datenquelle legt fest, welche Protokolle abgefragt werden. Eine Filterbedingung bestimmt, auf welche Ereignisse die Regel zutrifft. Ein Schwellenwert oder Muster definiert, wie viele Ereignisse oder welche Abfolge einen Alarm auslöst. Metadaten umfassen den Schweregrad, die MITRE-ATT&CK-Zuordnung, eine Beschreibung und eine empfohlene Reaktion. Gut dokumentierte Regeln helfen Analysten, schnell zu verstehen, was ein Alarm bedeutet und wie sie reagieren müssen, wenn er ausgelöst wird.

Jede Erkennungsregel stellt einen Ausgleich zwischen Sensitivität (alle echten Treffer zu erkennen) und Spezifität (Fehlalarme zu vermeiden) her. Eine hochsensitive Regel erkennt jede Variante eines Angriffs, erzeugt aber eine enorme Menge an Alarmen. Eine hochspezifische Regel wird nur selten ausgelöst, kann jedoch neuartige Angriffsvarianten übersehen. Gutes Detection Engineering beginnt mit hoher Spezifität, um das Vertrauen der Analysten aufzubauen, und erweitert den Erfassungsbereich anschließend schrittweise, sobald die Abstimmung die Zahl der Fehlalarme senkt und das Vertrauen in die Regel wächst.

Schwellenwertbasierte Regeln werden ausgelöst, wenn die Anzahl der Ereignisse innerhalb eines Zeitfensters einen Grenzwert überschreitet. Sie eignen sich besonders zur Erkennung von volumenbasierten Angriffen wie Brute-Force-Angriffen, Port-Scans und DDoS-Angriffen. Wichtige Parameter sind: Anzahlenschwellenwert (wie viele Ereignisse), Zeitfenster (innerhalb wie vieler Minuten) und Gruppierungsfeld (pro Quell-IP-Adresse, pro Benutzer oder pro Host). Falsch gesetzte Schwellenwerte führen zu einer Flut von Alarmen oder zu übersehenen Erkennungen – stimmen Sie sie anhand historischer Baseline-Daten sorgfältig ab.

Sequenzbasierte Regeln suchen nach einer bestimmten, geordneten Ereigniskette und eignen sich daher besonders zur Erkennung mehrstufiger Angriffsmuster. Ein Beispiel: Phishing-E-Mail empfangen, DANN Schadanhang geöffnet, DANN PowerShell von einer Office-Anwendung gestartet. Jedes Ereignis für sich kann harmlos sein, die Sequenz weist jedoch auf eine Kompromittierung hin. Die meisten modernen SIEMs (Splunk, Sentinel, Elastic) unterstützen den Abgleich von Sequenzen mit zeitlicher Korrelation über Ereignisketten hinweg.

Sigma ist ein offenes, herstellerunabhängiges Format zum Schreiben von Erkennungsregeln. Diese können in SIEM-spezifische Abfragesprachen umgewandelt werden (SPL für Splunk, KQL für Sentinel, Lucene für Elastic). Die Security-Community stellt auf GitHub Tausende von Sigma-Regeln bereit, die gängige ATT&CK-Techniken abdecken. Mit Sigma können Organisationen Community-Erkennungen übernehmen, ohne sie manuell für ihre jeweilige SIEM-Plattform neu schreiben zu müssen. Dadurch lässt sich die Erkennungsabdeckung deutlich schneller erweitern.

Erkennungsregeln müssen vor der Bereitstellung in der Produktionsumgebung getestet werden. Zu den Best Practices gehören: Unit-Tests mit synthetischen Ereignissen, die sowohl echte Treffer als auch Fehlalarmszenarien abbilden, Wiedergabetests mit aufgezeichnetem harmlosen Datenverkehr zur Messung der Fehlalarmrate sowie Red-Team-Übungen, bei denen erwartet wird, dass die Regel auf kontrollierte Angriffssimulationen reagiert. Tools wie Atomic Red Team stellen kleine Testskripte bereit, die bestimmte ATT&CK-Techniken sicher simulieren.

Nach der Bereitstellung einer Regel ist eine kontinuierliche Abstimmung erforderlich. Zu den gängigen Verfahren gehören: Ausschlusslisten für bekanntermaßen legitime Prozesse oder Konten, die die Regel berechtigterweise auslösen, Allowlisting bestimmter Quell-IP-Adressen (Scanner, Überwachungstools), das Anpassen von Schwellenwerten anhand der beobachteten Basisraten und das Hinzufügen kontextbezogener Bedingungen (Alarm nur auslösen, wenn der Host auch extern erreichbar ist). Dokumentieren Sie jeden Ausschluss mit einer Begründung, damit zukünftige Analysten verstehen, warum er existiert.

Erkennungsregeln sollten Schweregradbewertungen enthalten, die Analysten bei der Priorisierung unterstützen. Gängige Stufen sind: Kritisch – aktive Ausnutzung, Ransomware, Kompromittierung eines Domänencontrollers. Hoch – laterale Bewegungen, Auslesen von Anmeldeinformationen, C2-Kommunikation. Mittel – verdächtige Aufklärung, Richtlinienverstöße. Niedrig/Informativ – ungewöhnliche, aber nicht unmittelbar gefährliche Ereignisse, die nachverfolgt werden sollten. Der Schweregrad sollte sich am geschäftlichen Schaden und nicht nur am technischen Schweregrad orientieren.

Erkennungsregeln haben einen Lebenszyklus, der aktiv verwaltet werden muss. Regeln veralten, wenn sich die Umgebung ändert (beispielsweise durch neue bereitgestellte Software oder geänderte IP-Adressbereiche), und erzeugen dann Fehlalarme. Außerdem übersehen Regeln neue Angriffstechniken, während sich Angreifer weiterentwickeln. Best Practice: Verwalten Sie Regeln in einer Versionsverwaltung (git), überprüfen und aktualisieren Sie sie vierteljährlich, ordnen Sie jede Regel mindestens einer ATT&CK-Technik zu und messen Sie die Wirksamkeit der Regeln (Auslösungen pro Woche, Rate echter Treffer), um leistungsschwache Regeln zu verbessern oder außer Betrieb zu nehmen.

Eine Abdeckungskarte für Erkennungen legt vorhandene Erkennungsregeln über die MITRE-ATT&CK-Matrix, um Lücken in der Abdeckung sichtbar zu machen. Jede Technik, die von mindestens einer Regel abgedeckt wird, ist grün markiert; nicht abgedeckte Techniken sind rot. Diese Darstellung zeigt, in welchen Angriffsphasen (z. B. Persistenz oder Exfiltration) die Erkennungsabdeckung fehlt, und hilft Teams dabei, die Entwicklung neuer Regeln zu priorisieren. Regelmäßige Überprüfungen der Abdeckung stellen sicher, dass das Erkennungsprogramm mit der Weiterentwicklung der Angriffstechniken Schritt hält.

Testen Sie Ihr Verständnis der CompTIA Security+-Konzepte (SY0-701) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Erkennungsregeln bilden spezifische Verhaltensweisen von Angreifern als Alarmbedingungen im SIEM ab, schwellenwert- und sequenzbasierte Regeln behandeln unterschiedliche Arten von Angriffsmustern, und Sigma stellt ein portables Format für den Austausch von Erkennungen innerhalb der Security-Community bereit. Als Nächstes untersuchen wir UEBA und Verhaltensanalysen zur Erkennung von Insiderbedrohungen und kompromittierten Konten.