Erkennen von Cyber-Bedrohungen mit Azure Sentinel – Teil 1

In den letzten 6 Monaten haben meine Kollegen von Arco IT und ich einem unserer Kunden geholfen, ihre Sicherheitsüberwachungsfunktionen mithilfe von Azure Sentinel, einem Cloud-basierten MICROSOFT-System, zu entwickeln. Wenn Sie nicht wissen, was Sentinel ist, lernen Sie in diesem Artikel die Microsoft SIEM-Plattform kennen.

Aufnahme von Protokollen in Sentinel 

Der erste Schritt zur Erkennung von Cyber-Vorfällen besteht darin, Protokolle in Ihre Plattform zu integrieren. Die Protokollaufnahme in Sentinel (oder genauer gesagt im zugrunde liegenden Log Analytics Workspace) kann auf viele Arten durchgeführt werden, je nachdem, woher die Protokolle stammen.

Da der Schwerpunkt des Projekts auf der Anwendungsüberwachung und nicht auf der Endpunktüberwachung liegt, werde ich hier nur kurz auf die Endpunktüberwachung eingehen. Die von Microsoft bereitgestellten Endpunkt-Agenten sammeln automatisch Windows-Ereignisprotokolle oder Linux-Protokolle und senden diese an einen angegebenen Arbeitsbereich. Diese Ereignisse finden Sie dann in den Log Analytics Workspace unter Agents management. Natürlich können Endpunktprotokolle von Drittanbietern ebenfalls aufgenommen werden, entweder über Standardsteckverbinder oder mit den Methoden, die ich nachfolgend beschreibe.

Die einfachste Möglichkeit Protokolle zu Sentinel hinzuzufügen besteht darin, einen der von Microsoft bereitgestellten Standarddatenkonnektoren zu verwenden, der nur wenige Klicks zum Einrichten erfordert. 54 Datenkonnektoren sind derzeit für viele Microsoft-Produkte (Office 365, Microsoft Cloud App Security, Azure Active Directory usw.) oder bekannte Sicherheitsprodukte wie Palo Alto- oder Cisco-Firewalls verfügbar. Microsoft arbeitet ständig an der Entwicklung neuer Konnektoren; die letzte Charge wurde Ende Juli veröffentlicht und enthält Steckverbinder für Carbon Black, Okta oder Qualys VM.

Wenn kein Standardkonnektor verfügbar ist, kann die API der Ressource verwendet werden, um die Protokolle aufzunehmen. Mit einer Logic App, die auf einer wiederkehrenden Basis ausgeführt wird, definiert sich der Aufnahmeprozess wie folgt:

1. Abfragen der Protokolle mithilfe der Ressourcen–API 
2. Filtern von Protokollen und bei Bedarf Ausführung von Transformationen  
3. Senden der Protokolle an Sentinel

Abbildung 1. Logic App zum Einlesen von Protokollen über die Ressourcen-API 

Ein ähnliches Verfahren kann für Azure-Protokolle (egal ob Aktivitätsprotokolle oder Audit-Protokolle) verwendet werden, wenn eine direkte Verbindung mit der Ressource nicht möglich oder erwünscht ist. Anwendungsteams können ihre eigenen Log Analytics Workspace nutzen oder ihre Protokolle in einem Storage Account aufbewahren, z.B. aufgrund von Anforderungen an eine lange Protokollaufbewahrungszeit.

Für Log Analytics Workspace gilt derselbe Prozess; der einzige Unterschied ist der Anfangsschritt, bei dem die Protokollerfassung statt über die API mit dem bereitgestellten Logic App connector erfolgt.

Für Storage-Konten ist die Verwendung einer Azure-Funktion, die beim Hinzufügen einer neuen Datei getriggert wird, in der Regel eine bessere Wahl als der Logic App Trigger, der dasselbe tut, aber nicht mit Unterordnern funktioniert. Die mitgelieferte Logikanwendung löst nur aus, wenn Dateien direkt im ausgewählten Ordner hinzugefügt werden, was normalerweise nicht der Fall ist, da Azure die Protokolldateien anhand der Zeitstempel der Ereignisse in verschiedene Ordner aufteilt.

Abbildung 2. Protokollaufnahme mit einem HTTP trigger, wenn eine neue Datei in einem Storage-Konto gespeichert wird 

Schliesslich können Azure-Aktivitäts- und Überwachungsprotokolle über die sogenannten Diagnostics Settings direkt mit einem Log Analytics Workspace verbunden werden.

Hinweis: Diagnostics Settings können auch zum Senden von Protokollen an ein Storage Account verwendet werden, was der zuvor vorgestellten Lösung entspricht, weiter besteht die Möglichkeit eines EventHub, den ich zu einem späteren Zeitpunkt vorstellen werde.

Schlussfolgerung

Das Abrufen von Protokollen in Ihrem SIEM ist der erste Schritt, um böswillige Aktivitäten in Ihrer Organisation zu erkennen. Die Frage, die dann kommt, ist: Was mache ich mit diesen Protokollen?

Aus diesem Grund erläutere ich in der nächsten Ausgabe:

• Entwicklung von Warnregeln zur Erkennung böswilligen Verhaltens  
• Automatisierte Reaktionsschritte auf Vorfälle, um bei der Untersuchung und Reaktion von Vorfällen zu helfen
• Definition von Gesundheitskontrollen, um sicherzustellen, dass alles wie erwartet funktioniert