Inhaltsverzeichnis
Einleitung
Es wird Zeit, die reine Elastic-Logsammlung durch ein SIEM aufzuwerten. SIEM steht für Security Information and Event Management. Dabei werden Regeln zur Suche von bestimmten Logs und Log-Kombinationen verwendet, um Anomalien und Sicherheitsverstöße festzustellen und bei Bedarf Alarm auszulösen. Dieser wesentliche Baustein gehört in meiner IT-Sicherheitsarchitektur unter „Detection & Response“ (WS IT-Solutions · Blog: Hardening, Isolation und Detection & Response).
Der Artikel gehört zu meiner Serie „Bereitstellung eines Elastic SIEM„.
Konfiguration
Auswahl der SIEM-Rules – Die Theorie
Die Konfiguration ist einfach. Im Menü Security gibt es den passenden Einstieg für die Rules:
Hier gibt es zwei wesentliche Punkte: die eigentlichen Detection-Rules und deren MITRE ATT&CK® Abdeckung. Bevor man wild irgendwelche Regeln aktiviert, sollte man sich ein Bild über die Angriffssituation machen. Und da kommt MITRE ins Spiel:
MITRE definiert Taktiken, Techniken und Vorgehensweisen von Angriffen (tactics, techniques and procedures – TTP). Im MITRE-Katalog sind bereits zahlreiche, gängige Angriffstechniken enthalten. Diesen werden Nummern zugeordnet. Zu vielen TTP gibt es auch Beschreibungen für die Erkennung und die Verhinderung (Detection and Mitigation). Ich persönlich nutze z.B. gerne als Angreifer geplante Aufgaben für meine Persistence. Diese Technik ist im MITRE-Katalog hier mit der Nummer T1053 zu finden:
Folgt man dem Link, dann findet man viele Informationen zu dieser Taktik. Diese sind aber aus meiner Sicht nicht immer korrekt. Hier z.B. steht, dass geplante Aufgaben nur von Administratoren erstellt werden. Das stimmt nicht. Aber im Wesentlichen ist es eine sehr sinnvolle Plattform für Informationen. Es gibt eine Reihe von Beispielen für Procedures, die reale Angreifergruppierungen verwenden:
Aber eben auch die versprochenen Mitigations und Detections:
In diesem Fall wäre es z.B. die Protokollierung und Überwachung folgender Eventlog-Einträge auf Windows Systemen:
Möchte man sich vor dieser speziellen Bedrohung schützen, dann sind 3 Punkte im SIEM-Kontext wichtig:
- Log-Generierung: Die Events müssen in den Windows Systemen lokal protokolliert werden. –> Hier müsste im „Advanced Audit“ das „auditing of other object access“ aktiviert sein.
- Log-Weiterleitung: Die Events müssen in das zentrale Log-Management weitergeleitet werden. –> Das übernimmt bei mir mein Elastic-Agent mit der Fleet-Policy für die Windows Logs.
- Log-Erkennung: Im zentralen Log-Management gibt es eine SIEM-Rule zur Überwachung dieser Events. –> Dafür benötige ich eine SIEM-Rule.
Das Prinzip der SIEM-Rule-Auswahl ist also eigentlich recht simpel, wenn man weiß, wovor man sich schützen will. Aber es steckt etwas Arbeit dahinter: Einfach irgendwelche Rules aktivieren, ohne z.B. auch die Log-Generierung und die Log-Weiterleitung zu aktivieren, macht keinen Sinn!
Auswahl einer passenden SIEM-Rule für mein Beispiel
Jetzt geht es also zu den SIEM-Rules. Elastic liefert in meinem Release 1.315 mit!
Alle Rules haben einen RuleName, einen Risk-Score und eine Severity. Dazu gibt es jede Menge Tags, mit denen die Rules einfach vorgefiltert werden können. Die Integrations zeigen an, ob aktuell überhaupt eine Log-Weiterleitung zum Elastic besteht:
Ich möchte mich gegen Persistence durch Scheduled Tasks absichern. Also wähle ich bei den Tags „Tactic: Persistence“ aus. In den Rules wird dann schon der richtige Treffer angezeigt. Und die Integration zeigt an, dass die Log-Weiterleitung bereits konfiguriert ist. Meine Advanced Audit Policy (GPO) sorgt auf den Windows Systemen dafür, dass diese Informationen auch lokal erfasst werden. Die Rule kann ich also einfach aktivieren:
Die Rule-Details zeigen auch wieder den Bezug zum MITRE. Dazu wird aber auch die EQL-Abfrage für die Log-Suche angezeigt. Da ist man direkt froh, dass man das nicht selber schreiben muss… Mit „Install and enable“ wird die Rule bereitgestellt:
Testlauf
Testlauf #1 – „you attacked me wrong“
Jede Regel sollte nach Möglichkeit selber getestet werden. Nur dann kann man sich sicher sein, dass sie auch bei einem Angreifer auslösen wird. Also erstelle ich eine geplante Aufgabe auf meinem Client mit der PowerShell:
Jede Rule hat einen Zeitplan. Diese hier startet alle 5 Minuten eine Suche. Das Starten kann bei Bedarf auch manuell ausgeführt werden:
Aber es kommt kein Alarm…
Wo ist das Problem? Ich gehe die Abfolge noch einmal durch:
- Ereignis auslösen –> meine PowerShell hat eine geplante Aufgabe angelegt
- Ereignis protokollieren –> hier müsste ich im lokalen Eventlog nach dem Event suchen. Das spare ich mir und suche gleich im nächsten Schritt im Elastic.
- Log weiterleiten –> ich suche im Elastic nach dem Event. Hier verwende ich den Filter
agent.name :“WS-CL11a“ AND (rule.name: „T1053“ OR event.code: 4698)
Der agent.name ist mein Computername. Die rule.name-Property wird von sysmon mitgebracht. Sysmon überwacht ebenfalls die Anlage von geplanten Aufgaben. Und der event.code 4698 ist die ID vom Windows Eventlog für neue geplante Aufgaben
Im Elastic finde ich beide Events:
Diese Events schaue ich mir genauer an und stelle fest, dass sie nicht durch den EQL-Suchfilter gefunden werden können… Ich habe „falsch angegriffen“.
Testlauf #2 – erfolgreiche Erkennung mit Alerting
Also probiere ich eine andere Variante, um meine geplante Aufgabe anzulegen. Hier starte ich schtasks.exe in einer powershell.exe:
Jetzt habe ich einen Alert in der Kibana-Konsole gefunden, denn diese Vorgehensweise wird vom EQL-Filter der SIEM-Rule erfasst! Die Informationen sind sehr schön aufbereitet. Man hat in der Übersicht alle relevanten Daten aufgelistet:
Klickt man auf den Namen der Rule in der unteren Tabelle, dann wird rechts die Rule-Definition angezeigt:
Nutzt man dieses Symbol neben dem Alert, dann werden Details zum Fund angezeigt:
Klickt man hier oben rechts auf „expand details“, dann werden weitere Informationen angezeigt. Sehr schön sind auch die gesammelten Infos zu den „related hosts“ – also anderen Computern, mit denen der betroffene Rechner kommuniziert hat:
Und es gibt noch viel mehr Ansichten, welche über die Tabs erreichbar sind:
Jeder Alarm sollte behandelt werden. Dafür sind diese Optionen gedacht:
Damit funktioniert diese SIEM-Rule in der definierten Situation.
MITRE Coverage
Meine erste SIEM-Rule ist eingesetzt. Sie deckt mit der Technik T1053.005 einen Teil der Erkennung für die Angriffsphasen „Persistence“ und „Privilege Escalation“ ab. In der Ansicht „MITRE ATT&CK® coverage“ kann man das sehen:
Mir fehlen hier also noch 4 andere Techniken. Und in anderen Bereichen (Reconnaissance, Initial Access, Execution, Privilege Escalation, …) habe ich noch viel Entwicklungspotential.
Fazit
Es gibt viele vorgefertigte SIEM-Rules. Aber es nützt nichts, diese einfach stumpf zu aktivieren: entweder werden sie nie ausgelöst, weil die Voraussetzungen nicht stimmen oder ihr bekommt viele Fehlalarme und erkennt dann ggf. einen echten Hinweis nicht mehr.
Das ist meine Strategie:
- Ich konzentriere mich auf die MITRE Tactics und arbeite diese entsprechend meiner Schutzanforderungen in der Reihenfolge eines Angriffs ab.
- Initial Access: Hier startet ein Angriff. Ich habe etliche technische Maßnahmen auf meinen Systemen platziert. Also kann ich hier die Erkennung im SIEM hinten anstellen.
- Persistence: Kommt ein Schadcode auf ein System, dann wird er sich dauerhaft einnisten wollen. Hier ist die Erkennung recht einfach. Daher werde ich hier einige SIEM-Rules aktivieren.
- Reconnaissance: Der Schadcode wird Informationen über das System und das Netzwerk sammeln. Dies geschieht sehr oft am Anfang direkt nach der Infektion. Eine Erkennung an dieser Stelle kann also einen Angriff sehr früh anzeigen. Hier lohnen sich SIEM-Rules!
- Credential Access & Privilege Escalation: Für eine Verbreitung des Schadcodes werden Anmeldeinformationen und höhere Rechte benötigt.
- Lateral Movement: In dieser Phase verbreitet sich der Angreifer auf andere Systeme.
- Exfiltration: Datenabfluss kommt meist vor einer Datenverschlüsselung und muss daher unbedingt erkannt werden.
- Ich prüfe bei jeder Rule, ob die dafür erforderlichen Log-Daten auf den Systemen protokolliert und ins Log-Management weitergeleitet werden.
- Im Idealfall teste ich jede Rule wie vorhin gezeigt.
Das ist viel Arbeit. Aber mit der richtigen Strategie können die essentiellen Rules aktiviert werden und ein Angreifer wird schnell im Netzwerk erkannt!
Weitere Artikel findet ihr in meiner Serie „Bereitstellung eines Elastic SIEM„.
Stay tuned!