Microsoft 365 Logs
Die strukturierte Erfassung und Aufbereitung von Microsoft 365 Logs ist für die Transparenz und zur Reaktion auf sicherheitsrelevante Vorfälle essentiell. Die M365-Cloud loggt so ziemlich jedes Ereignis, was man sich als Security-Experte oder SOC-Analyst so wünschen kann.
Die Fragen, die sich stellen sind oft:
- Wo fange ich an?
- Was muss ich mir anschauen?
- Was mache ich damit?
Wir versuchen mal, hier ein paar der Fragen zu beantworten.
Log Analytics Workspace
Der Ort, an dem die Magie beginnt ist der Log Analytics Workspace – das Datengrab der Microsoft Cloud. Hier können alle Microsoft 365 Logs reingepumpt und mit Hilfe der **muss-man-lieben** Abfragesprache KQL durchsucht werden. Wer vier Schritte überspringen möchte und direkt mit Hunting loslegen, der findet bei Bert-Jan in seinem Blog oder git-Repo eine gute Auswahl an Queries.
Der Log Analytics Workspace kostet natürlich Geld (Storage). Alle Logs lassen sich auch in on-Premises-Log-Tools exportieren. Hierfür kann beispielsweise ein Event hub konfiguriert werden.
Wo fange ich an?
Für den Start brauchen wir eine Subscription als Abrechnungscontainer und darin einen Log Analytics Workspace.
Da die Log-Einträge sehr schützenswerte Daten enthalten können, gilt etwas Obacht bei der Wahl der Subscription und dem Setzen der Berechtigungen – das soll aber hier nicht unser Fokus sein.
Der zweite Schritt führt uns in die Einstellungen, welche Logs im Log Analytics Workspace gesammelt werden. Diese befinden sich im AAD / Entra ID in den Diagnostic Settings. Für den Start wollen wir alle Arten der SignInLogs, AuditLogs und ActivityLogs sammeln.
Mit Blick auf die Kosten gilt: SignInLogs sind sehr wenige, AuditLogs ein paar, GraphActivityLogs und NonInteractiveUserSignInLogs sind eher viele!
Die tatsächliche Verteilung vom Log-Volumen hängt natürlich auch vom Anwendungsfall ab – die zwei nachfolgenden Beispiele zeigen die Volumenverteilung exemplarisch in zwei Tenants mit ca. 10 und ca. 1500 Nutzern.
Wenn die Microsoft 365 Logs eingesammelt sind, kann es los gehen und der Spaß beginnt.
Was muss ich mir anschauen?
Nach der Freude über die vorhandenen Logs, kommt schnell die Frage: unnu?!
Bei Schulungen und Vorträgen kommt immer wieder die Frage hoch „ja gibt es da nicht was fertiges, was man einfach nehmen kann?“ – so einfach ist das leider nicht. Managed SOC-Anbieter verdienen unter Anderem genau damit ihr Geld: Die richtigen Dinge suchen, finden und bewerten.
Wer selbst nach einem Anfang sucht, der kann mit KQL in Log Analytics schnell zusammenfassende Tabellen und Grafiken erstellen, um einen ersten Eindruck zu bekommen, was so alles in den Logs verborgen liegt.
Nehmen wir als Beispiel die AuditLogs. Hier landen alle administrativen Ereignisse aus dem M365-Tenant drin. KQL kann Ereignisse über die summarize count() by Funktion zusammenfassen und ausgeben. So wird zumindest schnell klar, welche Ereignisse oft vorkommen und welche eher selten.
Die Anzahl verschiedener Kategorien hält sich hier in Grenzen, sodass wir uns die wichtigsten rauspicken können um dort in die Analyse und Erstellung von Alarm-Regeln einzusteigen. Update Device | User | Group oder Change user license wären hier nicht meine erste Wahl.
Über den gleichen Weg lassen sich auch SignInLogs aufdröseln, um beispielsweise der Frage nachzugehen, über welche Apps die Benutzer sich eigentlich typischerweise anmelden. Der summarize-Operator kann mehrere Columns verarbeiten, sodass wir beispielsweise Land und Ergebnis der Anmeldung mit in die Statistik aufnehmen. Ob es ferne Länder mit komischen Apps gibt? Das lässt sich so schnell identifizieren.
Ergänzend zur summarize count() by – Funktion kann über LogAnalytics mit KQL auch eine frei definierbare Timeline erstellt werden. Mit bin(TimeGenerated, 1h) wird die x-Achte zur stundenbasierten Auswertung der SignIn-Events pro Location / Land. Wer keine Zugriffe aus fernen Ländern erwartet, kann hier tiefer einsteigen. Die Abfrage lässt sich übrigens über den Pipe-Operator noch weiter filtern. | where ResultType!=0 zeigt nur noch SignIns, die nicht geklappt haben.
KQL-Queries werden schnell kompliziert. Die frei verfügbaren Repositories sind da eine gute Anlaufstelle:
– https://learnsentinel.blog/2022/10/06/a-picture-is-worth-a-thousand-words-visualizing-your-data/
– https://www.kustoking.com/using-external-ip-lists-in-azure-sentinel/
– …
Übrigens gibt es auch von Microsoft Hilfe, welche Ereignisse relevant sein können. Das Microsoft Incident Response Team hat hierzu ein schönes PDF-Dokument veröffentlicht.
Was mache ich mit den Microsoft 365 Logs?
Mit ein paar schönen Visualisierungen sieht die Welt doch gleich viel bunter aus. Nicht jeder Zugriff aus fernen Ländern ist direkt einen Alarm wert. Nicht jede neue Enterprise Application bedeutet gleich die Kompromittierung des Tenants. „Gibt es da nicht etwas von der Stange?“ ist auch deshalb die falsche Frage. Je nach Größe, Reifegrad und (personeller) Ressourcenausstattung können die Aktivitäten, die aus den gefilterten Logs rauspurzeln anders aussehen. Regulatorische Rahmenwerke wie der Digital Operational Resilience Act (DORA) gehen klar in die Richtung, dass sicherheitsrelevante Ereignisse eingesammelt, automatisiert ausgewertet und behandelt werden müssen – Nur zuschauen ist nicht mehr!
Alarm!
Die schnellste und einfachste Methode auf definierte Auswertungen zu reagieren sind Alarme. Aus LogAnalytics heraus lassen sich Azure Alerts erzeugen, die beispielsweise eine E-Mail an das SOC schicken oder einen automatisierten Reaktions-Workflow anstoßen können – Vorsicht bei letzterem!
Jede Suche in LogAnalytics lässt sich per Klick in einen Alarm umwandeln. Jeder Alarm verbraucht Ressourcen und damit verdient Microsoft an dieser Stelle Geld. Wenn die Alarme alle 15 Minuten ausgewertet werden, dann kostet das geschätzt 50 ct pro Alarm pro Monat, bei Ausführung jede Minute sind es ca. 3 Euro laut der in Azure Alerts angezeigten Schätzung. Wenn wir 50 Alarme mit Auswertung alle 15 Minuten erstellen, dann sind das 25 € im Monat – nicht die Welt, aber ob das nur 50 Alarme bleiben…?
Eine E-Mail verhindert keinen Angriff. Aber sie schafft Transparenz und die Möglichkeit zu reagieren. Bei manchen Events ist eine automatische Reaktion wünschenswert. Mit Microsoft Sentinel gibt es vorgefertige Playbooks, um beispielsweise ein Benutzerkonto bei bestimmten Fehlhandlungen zu sperren – das sollten halt nicht alle Administratoren am Ende sein, aber grundsätzlich kann man damit auf Logins aus fremden Regionen, mit unerwünschten Apps oder auf das massenweise Herunterladen von Daten reagieren (Sentinel mit OfficeActivity-Log vorausgesetzt).
Logauswertung ist ein must-have!
Die M365-Cloud ist 24/7 aus dem Internet erreichbar. Es wäre das erste Unternehmen, wo bei einem Audit der Conditional Access-Regelwerke und der Tenant-Sicherheit nicht irgendeine App in irgendeinem Szenario durchgerutscht wäre, womit ein Angreifer in die Lage versetzt wird das auszunutzen. Und die Angriffe nehmen zu.
Ob die Logs in ein SIEM geschoben werden müssen, ob Sentinel ein gutes SIEM ist – mit diesen Fragen kann man sich beschäftigen, wenn man die Basis der Auswertung gelegt und die relevanten Alarme definiert hat. Dazu zählen sicherlich:
- Neue Benutzer in privilegierten Rollen
- Entfernen von Benutzern aus privilegierten Rollen
- Neue Owner / Member in CA-Ausnahmegruppen
- Änderungen am CA-Regelwerk
- Neue Enterprise Apps
- Änderungen an den Log-Konfigurationen
- Änderungen an den Alarmen
- FullAccess-Zugriffe auf Mailboxen
- …
Nicht jedes Auftreten eines solchen Events ist eine Katastrophe. Es könnte aber der Anfang einer eben solchen sein.
