Ich bin Sergey Rublev, Leiter des SOC (Security Operations Center) bei Infosecurity.
In diesem Artikel werde ich das ehrgeizige Projekt
Sigma Rules im Detail untersuchen, dessen Motto lautet: "Sigma für Protokolle ist wie Snort für Datenverkehr und Yara für Dateien."
Es wird um drei Aspekte gehen:
- Anwendbarkeit der Sigma-Regel-Syntax zur Pflege einer Wissensbasis von Bedrohungserkennungsskripten
- Funktionen von Tools zur Regelgenerierung für SIEM-Boxsysteme
- Wert für den SOC des aktuellen Inhalts der öffentlichen Repositories der Sigma-Regeln
Es war einmal in einer fernen Galaxie
Alles begann vor einigen Jahren, als die Bäume groß waren und unser Überwachungsteam noch klein war. Wir hatten viele Fragen, fast jedes Team, das zu einer Drei-Personen-Linie heranwächst, macht dies durch.
Die Gründe für das Auftreten von Fragen sind unterschiedlich:
- Teamwachstum
- Fluktuation
- Eine große Anzahl heterogener Systeme zur Überwachung
Wenn Sie Support übernehmen müssen, der bereits von einem SIEM konfiguriert wurde, wächst die Anzahl der Fragen wie eine Lawine.
Anwendungsfallbibliothek
Die weltweite Erfahrung beim Bau von Überwachungszentren hat bereits eine Lösung für die Organisation des Chaos gefunden. Der Name lautet Bibliothek mit Fallstudien. In jedem Fall soll die Lösung eines Problems im Rahmen der Überwachung der Informationssicherheit umfassend beschrieben werden.
Die jeweils festgelegte Zusammensetzung des Wissens kann variieren, wir gehen von folgendem Satz aus:
- Ziel - die vom Fall gelöste Aufgabe
- Bedrohung - die Bedrohung, die von der Erkennungsregel erkannt werden soll.
- Stakeholder - Personen, die an dieser Regel interessiert sind: IB / IT / Business
- Datenanforderungen - Der Datensatz, der zur Identifizierung einer Bedrohung erforderlich ist
- Logik - Logik der Bedrohungserkennungsregel
- Testen - Ein Algorithmus zum Testen der Richtigkeit der Erkennungsregel
- Priorität - Priorität der Ereignisverarbeitung von Fall zu Fall (normalerweise berechnet aus dem potenziellen Schaden einer erfolgreich implementierten Bedrohung)
- Ausgabe - Eine Liste von Aktionen zum Parsen der Warnung, eine Beschreibung der korrekten Exits aus dem Parsing-Verfahren und die Zusammensetzung der in den Parsing-Ergebnissen aufgezeichneten Daten
Anwendungsbeispiel für die Aufgabe, die Kommunikation mit dem Botnet-Verwaltungsserver zu erkennen (allgemein bekannt als C & C oder nur C2):
Das Beispiel ist stark vereinfacht: In der Realität wächst ein Fall mit einer korrekten Beschreibung zu einem mehrseitigen Dokument.
In diesem Moment, als die Anzahl der Fälle mehrere zehn überschritt, suchten wir nach vorgefertigten Werkzeugen für die Aufrechterhaltung einer solchen Wissensbasis, die vorzugsweise neben menschenfreundlichen auch eine maschinenfreundliche Schnittstelle für die Arbeit hatten.
Sigma-Projekt
Das Sigma-Projekt verdient sicherlich eine Berücksichtigung im Kontext der Wissensbasis über Regeln zur Erkennung von Vorfällen. Es begann im Jahr 2016 und ich habe es fast von Anfang an verfolgt.
In der Tat besteht das Projekt aus
- Sigma regiert sich selbst
- Dienstprogramme zum Konvertieren von Regeln in Abfragen für verschiedene SIEM-Systeme
Die SIEM-Liste ist beeindruckend: Fast alle gängigen Event-Analyse-Lösungen sind vorhanden. Weiter über alles im Detail und in Ordnung.
Regelsyntax
Sigma-Regeln sind YAML-Dokumente, die ein Szenario zum Erkennen eines bestimmten Angriffs beschreiben. Syntaktisch bestehen die Regeln aus den folgenden Blöcken:
Meta-Informationen
Beschreibender Teil zur Strukturierung und Vereinfachung der Suche nach den erforderlichen Regeln.
title: Access to ADMIN$ Share description: Detects access to $ADMIN share author: Florian Roth falsepositives: - Legitimate administrative activity level: low tags: - attack.lateral_movement - attack.t1077 status: experimental
Ich möchte auch darauf hinweisen, dass viele Regeln bereits mit Links zur Angriffstechnik gemäß der MITRE ATT & CK-Methodik versehen sind.
Datenquellenerklärung
Beschreibung der Quelle basierend auf den Ereignissen, deren Erkennungslogik implementiert ist.
logsource: product: windows service: security
Es ist syntaktisch möglich, sowohl den Endservice eines bestimmten Produkts als auch eine ganze Kategorie von Systemen zu beschreiben.
Logikerklärung verarbeiten
Auf der Ebene der Erkennungslogik wird Folgendes beschrieben:
- Gesuchte Muster
- Werte bestimmter Felder im Protokoll
- Zeitrahmen
- Aggregierte Funktionen
Logik kann trivial sein, z. B. Bedingungen, die einer Reihe von Feldern auferlegt werden:
detection: selection: EventID: 5140 ShareName: Admin$ filter: SubjectUserName: '*$' condition: selection and not filter
und ziemlich kompliziert:
detection: selection1: EventID: - 529 - 4625 UserName: '*' WorkstationName: '*' selection2: EventID: 4776 UserName: '*' Workstation: '*' timeframe: 24h condition: - selection1 | count(UserName) by WorkstationName > 3 - selection2 | count(UserName) by Workstation > 3
Die Ausdrucksmittel der Sprache sind zwar nicht universell, aber dennoch recht breit und ermöglichen es Ihnen, eine große Anzahl von Fällen zur Identifizierung von Angriffen zu beschreiben.
Tools zur Regelentwicklung
Zusätzlich zu Ihrem bevorzugten Texteditor für YAML ist auch die WEB-Benutzeroberfläche von SOC Prime verfügbar, mit der Sie sowohl die Syntax einer bereits geschriebenen Regel überprüfen als auch Regeln manuell aus Grafikblöcken erstellen können.
Sigma als Knowledge Base Tool
Um eine kurze Zusammenfassung zusammenzufassen.
Derzeit konzentriert sich die Syntax der Regeln hauptsächlich auf die Beschreibung der Bedrohungserkennungslogik und ist nicht für eine umfassende Beschreibung des Anwendungsfalls vorgesehen. Dementsprechend funktioniert es nicht, eine vollwertige Bibliothek nur mit Sigma-Regeln zu verwalten.
Für die von uns gewählte Anwendungsfallstruktur schließt Sigma nur die Hälfte (Ziel, Datenanforderungen, Logik und Priorität).
In verschiedene SIEM konvertieren
Da wir ein Dienstleister für SOC-Dienste sind, erschien uns die Idee, alle unsere Entwicklungen gemäß den Korrelationsregeln in einem universellen Format zu halten und in der Implementierungsphase auf das gewünschte SIEM-Format umzustellen, sehr attraktiv.
Das Projekt enthält Konsolendienstprogramme zum Generieren von Ereignisanforderungen im Format verschiedener SIEMs. Überlegen Sie, was Bekehrung ist und was sich unter ihrer Haube befindet.
Die Konvertierung erfolgt in 3 Schritten:
- Analyseregeln - Ich denke, das ist klar: Das YAML-Dokument ist in Komponentenblöcke sortiert
- Reduktion auf SIEM-Taxonomie
Die Notwendigkeit dieser Phase hängt mit der Tatsache zusammen, dass die Normalisierung in SIEM-Systemen auf etwas andere Weise implementiert wird. Daher müssen Erklärungen aus Sigma-Regeln auf die Taxonomie der Ereignisse des ausgewählten SIEM reduziert werden - Anforderungsgenerierung für SIEM
Damit diese Phase funktioniert, ist eine weitere Komponente erforderlich - ein Backend für dieses SIEM.
Tatsächlich ist das Backend ein Plug-In für das Konvertierungsdienstprogramm, das die Logik für die Konvertierung in das endgültige Anforderungsformat in SIEM enthält. Die Erkennungs- und Protokollquellenblöcke werden unter Berücksichtigung der zuvor überlagerten Zuordnung von Feldern konvertiert, zusätzliche SIEM-spezifische Informationen werden hinzugefügt.
Das Starten des Konvertierungsdienstprogramms sieht daher folgendermaßen aus:
Folgende Parameter werden übergeben:
- Ziel SIEM
- Die Regel
- Zuordnungsdatei für dieses SIEM
SOC Prime hat auch eine vorgefertigte Benutzeroberfläche für die Konvertierungsfunktion (
uncoder.io )
Fallstricke der Bekehrung
- Nachdem wir die Mechanismen der Konvertierung studiert hatten, stießen wir auf erhebliche Einschränkungen, die uns davon abhielten, alle Entwicklungen in das Sigma-Format zu konvertieren:
- Der Konverter arbeitet nur mit einer Anfrage. Die Korrelationsregel in SIEM wirkt sich auf weitere Aspekte aus: Zeitfenster, Aggregation, Aktionen basierend auf den Ergebnissen identifizierter Warnungen
- Wichtige Merkmale einzelner SIEMs wie ActiveLists werden nicht berücksichtigt.
- Unzureichende Detaillierung der Feldzuordnung - Im Rahmen der Zuordnungskonfiguration werden die Felder nur weniger Quellen beschrieben. Dementsprechend müssen Sie mit Regeln für mehrere zehn verschiedene Arten von Ereignisquellen in der Datenbank viel in das Schreiben der Zuordnung investieren.
Regelbasis
Mal sehen, was die öffentlich verfügbare Sigma-Regelbasis enthält. Derzeit werden Inhalte aktiv zu zwei Repositorys hinzugefügt:
- Das Hauptprojekt-Repository
- SOC Prime Threat Detection Marktplatz
Regeln in den Repositorys haben einen Schnittpunkt ungleich Null.
SOC Prime hat eine Reihe von Regeln, die für bezahlte Abonnements gelten. Ich betrachte deren Inhalt in diesem Artikel nicht.
Für die
Analyse benötigen wir die
Sigmatools- Bibliothek für Python und einige Programmierkenntnisse.
Zum Parsen und Laden von Regeln aus einem Verzeichnis in ein Wörterbuch können Sie den folgenden Code verwenden:
from sigma.parser.collection import SigmaCollectionParser import pathlib import itertools def alliter(path): for sub in path.iterdir(): if sub.name.startswith("."): continue if sub.is_dir(): yield from alliter(sub) else: yield sub def get_inputs(paths, recursive): if recursive: return list(itertools.chain.from_iterable([list(alliter(pathlib.Path(p))) for p in paths])) else: return [pathlib.Path(p) for p in paths] BASE_PATH = [r'sigma\rules'] path_list = get_inputs(BASE_PATH, True) rules_map = {} for sigmafile in get_inputs(BASE_PATH, True): f = sigmafile.open(encoding='utf-8') parser = SigmaCollectionParser(f) rule = next(iter(parser)) rules_map[rule['title']] = rule
Wenn Sie dieselben Regeln duplizieren, entsteht das folgende Bild:
Als Teil einer eindeutigen Liste von Regeln erhalten wir die folgenden Verteilungen:
Nach Art der Ereignisquelle:Ein bisschen größere Statistiken
- Windows ~ 80%
- Sysmon ~ 53%
- Proxy ~ 8%
- Linux ~ 4%
Grundsätzlich konzentriert sich der aktuelle Inhalt auf das Windows- und Sysmon-System, insbesondere die Regeln für den Rest der Systeme sind einige.
Nach Verfügbarkeit der Inhalte:Es stellt sich heraus, dass die Entwickler von Sigma-Regeln weniger als 20% aller vorhandenen Regeln als stabil markiert haben.
Zusammenfassend
In öffentlich zugänglichen Quellen gibt es eine Vielzahl von Regeln. Sie werden regelmäßig aktualisiert, und die Regeln für die Erkennung von Indikatoren und manchmal sogar die Techniken der bekanntesten APT-Unternehmen werden schnell angezeigt.
Es gibt viele Einschränkungen für die Anwendung der Regeln im wirklichen Leben:
- Es gibt viele Regeln für Microsoft Sysmon, die in Unternehmen selten verwendet werden.
- Es gibt viele Regeln, die tatsächlich IoC-Prüfungen durchführen (Hashes, IP-Adressen, URLs, Benutzeragenten). Solche Regeln werden schnell veraltet und es gibt effektivere Mechanismen zum Auffinden von IoC als Regeln.
- Viele experimentelle Inhalte bzw. zusätzliche Anforderungen stellen hohe Anforderungen an hochwertige Tests vor der Inbetriebnahme.
Bei Infosecurity verwenden wir den Inhalt der Sigma-Regeln als zusätzliche Wissensquelle für eine effektivere Erkennung von Vorfällen. Wenn wir etwas Interessantes finden, werden wir es bereits im Rahmen unserer Korrelationsregeln implementieren, die sowohl den Kernel, auf dem die Regeln funktionieren (Apache Spark), als auch die Besonderheiten der Infrastrukturen und die von uns verwendeten Schutzmittel berücksichtigen.