Umfassende Abdeckung mit dem ION Detection Stack

Der ION Detection Stack von Ontinue bietet eine ganzheitliche Sicherheitsabdeckung für Ihre gesamte IT-Landschaft – von Geräten wie Clients und Servern über Identitäten und Netzwerkkomponenten bis hin zu Cloud-Anwendungen und -Workloads.

Die meisten unserer Kunden setzen in ihrer lokalen Infrastruktur oder in der Cloud vorwiegend auf Microsoft-Produkte, was häufig auch der Grund dafür ist, dass sie sich für Microsofts Sicherheitslösungen zu entscheiden. Doch reicht die Abdeckung dieser Produkte wirklich aus, um alle Angriffe zu erkennen? Und wie sieht es mit Angriffsflächen außerhalb des Microsoft-Ökosystems aus? In diesem Beitrag erfahren Sie, warum man sich bei der Erkennung von Angriffen nicht allein auf Out-of-the-Box-Inhalte verlassen sollte und wie der ION Detection Stack diese Lücken schließt.

Ganzheitlicher Schutz durch einen mehrschichtigen Ansatz

Unser Detection Stack kombiniert die Fähigkeiten zur Erkennung von Cyberangriffen von Microsofts Sicherheitslösungen mit denen von Drittanbieterlösungen, welche Sie bereits im Einsatz haben. Dazu kommt unsere Bibliothek von selbst entwickelten Analyseregeln. So entsteht ein mehrschichtiger Schutz, der auf Ihre Umgebung zugeschnitten ist.

Microsoft-Sicherheitsprodukte kombiniert mit Ontinues Inhalten und Drittanbieter-Logs

Ein Beispiel aus der Praxis: Auf Windows-Laptops und -Servern bietet Microsoft Defender for Endpoint (MDE) soliden Schutz gegen aktuelle Bedrohungen. Doch selbst in stark Microsoft-geprägten Umgebungen sind häufig auch einige Linux-Server im Einsatz, oft für spezialisierte Zwecke. Während mit MDE for Linux grundsätzlich ein Produkt von Microsoft zur Verfügung steht, verzichten viele Kunden auf dessen Einsatz, etwa wegen mangelnder Unterstützung bestimmter Distributionen oder aus Performance-Gründen. Um diese Blind Spots abzudecken, bieten wir einen alternativen Schutz mittels nativer Betriebssystem-Telemetrie des Linux Audit-Daemon (Auditd), übertragen via Syslog an Microsoft Sentinel für eine. Dazu bieten wir Empfehlungen zur Konfiguration des Audit-Dienstes, um sicherzustellen, dass alle relevanten Ereignisse protokolliert werden.

Gleiches gilt für Identitäten: Während Defender for Identity und Entra ID Protection zentrale Verzeichnisdienste lokal oder in der Cloud abdecken, existieren oft zusätzliche, sensible Daten zu den Benutzerkonten Ihrer Benutzer in anderen Systemen. Unser Detection Stack erweitert den Schutz daher gezielt auf IAM- und PAM-Lösungen.

Optimierte Out-of-the-Box-Analyseregeln

Microsoft Sentinel bietet mit seinem Content Hub umfassende Analyseregeln für viele verschiedene Datenquellen. Diese Vorlagen, samt KQL-Abfragen, sind im Sentinel GitHub Repository öffentlich zugänglich. Doch wie bei jeder SIEM-Lösung gilt: Standardinhalte müssen angepasst und optimiert werden, bevor sie produktiv zum Einsatz kommen.

Viele Analyseregeln generieren übermäßig viele False Positives, da sie normale Aktivitäten falsch interpretieren. Daher untersuchen wir diese Vorlagen, eliminieren unnötiges Hintergrundrauschen und optimieren die Analyse-Logik gezielt.

Beispiel: Verdächtige Rollenzuweisungen in Azure

Die unten abgebildete Microsoft-Vorlage nutzt ein 14-Tage-Baseline-Modell zur Erkennung verdächtiger Aktivitäten basierend auf neuen IP-Adressen. Das Original können Sie hier abrufen.

Original-KQL-Abfrage auf der linken Seite, Ontinue-optimierte Abfrage auf der rechten Seite.

In unseren Tests haben wir entdeckt, dass die maximal 14 Tage, die Microsoft Sentinel zur Bildung von Baselines unterstützt, zu kurz sind, um verlässliche Daten zu erhalten. So sind IP-Adressen vergänglich und können von Angreifern in kurzer Zeit geändert werden. Wir mussten daher einen neuen Erkennungsmechanismus entwickeln. Wir entschieden uns, Rollenzuweisungen in Azure mit auffälligem Anmeldeverhalten desselben Benutzers zu korrelieren. So erkennen wir riskante Aktionen präziser. Unsere angepasste Analyseregel läuft stündlich statt täglich, um die Mean-Time-to-Detect (MTTD) zu verbessern. Und obendrein kommt sie mit weniger Daten aus (2 anstatt 14 Tage).

Nebst Optimierungen der Abfragen gibt es weitere Verbesserungen, wie wir an den Out-of-the-Box-Regeln vornehmen, bevor wir eine Analyseregel in unseren Detection Stack aufnehmen:

• Dynamische Variablen: Jede Kundenumgebung ist unterschiedlich, aber unsere Analyseregeln müssen in allen Umgebungen funktionieren. Daher fügen wir den Regeln parametrisierbare Variablen hinzu, beispielsweise für Schwellwerte. Diese werden in unserer CI/CD-Pipeline dynamisch mit kundenspezifischen Werten befüllt, womit wir in der Lage sind, unsere Regeln passgenau auf Ihre Umgebung zu optimieren.
• Severity-Modell von Ontinue: Wir passen die Severity unserem eigenen Severity-Modell an. Das Rahmenmodell, welches die Wirkung des Angriffs, Präzision der Erkennung und die Bedeutung des angegriffenen Geräts oder Benutzers in Betracht zieht sorgt für Konsistenz über die ganze Use Case-Bibliothek. Regeln mit höherer Severity werden häufiger ausgeführt als solche mit niedriger Severity, um Angriffe früher zu erkennen.
• Starke Bezeichner für Entitäten: Entitäten wie Geräte, Benutzerkonten, IP-Adressen, etc. Werden mit starken Bezeichnern konfiguriert. Beispielsweise erkennen wir eine Identität nicht nur mit ihrem sAMAccountName, sondern auch mit dem dazugehörenden Domänennamen. Das hilft dem Microsoft-eigenen Korrelationsmechanismus, Entitäten zweifelsfrei zu erkennen und zusammengehörende Alarme unterschiedlicher Produkte in einem gemeinsamen Incident zusammenzufassen.
• MITRE ATT&CK-Zuordnung: Wir verbessern Zuordnungen von Tactics und Techniques, damit wir jederzeit über unsere Erkennungsmöglichkeiten und bestehende Lücken informiert sind.
  

Gap-Analyse und eigene Detection-Inhalte

Microsoft Defender XDR bietet eine hervorragende Erkennung von Cyberangriffen. Doch Angreifer entwickeln ihre Taktiken laufend weiter. Wir beobachten diese Entwicklungen kontinuierlich und erweitern den Umfang von Microsofts Out-of-the-Box-Fähigkeiten mit unseren eigenen Analyseregeln.

So haben wir systematisch eine bedeutende Bibliothek an eigenen Analyseregeln entwickelt, welche ein grosses Spektrum des MITRE ATT&CK Framework abbildet und dadurch Blind Spots, welche wir in Microsofts Produkten gefunden haben, abdeckt. Unsere neuesten Zugänge beinhalten beispielsweise Token-Theft und Device-Code-Phishing. Bedrohungen, bei denen Angreifer nicht ein Gerät kompromittieren, sondern direkt auf SaaS-Daten zugreifen.

Manchmal erkennt Microsoft erfolgreich einen Angriff, aber aufgrund ihrem eigenen, proprietären Korrelationsmechanismus, wird kein Alarm ausgelöst. Dies geschieht beispielsweise nach einem erfolgreichen Token-Theft, wenn die Angreifer den gestohlenen Token nutzen, um das Benutzerkonto des Opfers zu kompromittieren. Die Standortinformationen des Angreifers oder andere, besondere Merkmale des Authentisierungsvorgange können zwar einen Alarm in Entra ID Protection auslösen, diese werden aber oft automatisch wieder geschlossen, wenn der Benutzer den Anmeldeversuch mittels Multifaktor-Authentisierung (MFA) bestätigt hat. Wegen dieser Art von Blind Spots suchen wir gezielt nach Möglichkeiten mit der Telemetrie von Microsofts eignen Sicherheitsprodukten eigene Analyseregeln zu entwickeln.

Darüber hinaus bieten wir Schutz für systemrelevante Anwendungen außerhalb von Microsofts Ökosystem. Beispielsweise für SAP, welches Sie zur Steuerung Ihrer Produktions- und Logistikprozesse nutzen oder Code Repositories wie GitHub, wo Sie geistiges Eigentum verwalten. Zur Erschließung von neuen Datenquellen erarbeiten wir gemeinsam mit Ihnen individuelle Analyseregeln.

Datennormalisierung

Sicherheitsprodukte verfügen oft über ein eigenes, maßgeschneidertes Datenformat mit unterschiedlichen Namen für Felder mit demselben Inhalt. Web-Proxy-Produkte können beispielsweise eine URL in Feldern mit den Namen url_s, requestUri_s oder RequestURL protokollieren. Dies stellt dann eine Herausforderung dar, wenn Abfragen von Analysten oder Analyseregeln über mehrere Datenquellen desselben Typs ausgeführt werden müssen. Entweder müssen mehrere Datenquellen-spezifische Abfragen geschrieben werden oder eine Abfrage muss so geschrieben werden, dass sie die unterschiedlichen Felder aller Datenquellen in einer einzigen, komplexen Abfrage miteinander verknüpft. Durch die Umwandlung herstellerspezifischer Datenformate in ein einheitliches Datenschema, Datennormalisierung genannt, wird sichergestellt, dass alle von Ihnen erfassten Daten für alle SOC-Prozesse leicht zugänglich sind. Die Datennormalisierung vereinfacht die Erstellung von Abfragen für Analyseregeln, manuelle sowie automatisierte Incident-Analysen und Threat Hunts.

Microsofts Ansatz zur Datennormalisierung in Sentinel ist das Advanced Security Information Model (ASIM). Es unterstützt die Transformation Ihrer Datenquellen in ein einheitliches Format, entweder während dem Hochladen in Sentinel (ingestion-time) oder zum Zeitpunkt der Abfrage (query-time). Sentinel wird mit zahlreichen Parsern für gängige Datenquellen ausgeliefert, und das Team von Ontinue schreibt bei Bedarf eigene Parser.

CommonSecurityLog 

| where DeviceVendor == "Vectra Networks" and FlexNumber1Label == "threat"

| extend EventCount = toint(1)

| extend EventStartTime = TimeGenerated

| extend EventEndTime = TimeGenerated

| extend EventType = "IDS"

| extend EventProduct = tostring(DeviceProduct) 

| extend EventVendor = tostring(DeviceVendor)

| extend EventSchema = "NetworkSession"

| extend EventSchemaVersion = "0.2.6"

| extend EventResult = "Success"

| extend EventMessage = tostring(Activity)

| extend ThreatName = tostring(Activity)

| extend EventResultDetails = "NA"

| extend Dvc = DeviceAddress

| extend DvcOsVersion = tostring(DeviceVersion)

| extend DstIpAddr = tostring(DestinationIP)

| extend DstPortNumber = toint(DestinationPort)

| extend DstHostname = tostring(column_ifexists("DestinationHostName", ""))

| extend Dst = DstIpAddr

| extend SrcIpAddr = tostring(SourceIP)

| extend SrcHostname = tostring(column_ifexists("SourceHostName", ""))

| extend Src = SrcIpAddr

| extend EventSeverity = case(

                            FlexNumber1 >= 90 and FlexNumber2 >= 90, "High",

                            FlexNumber1 >= 70 and FlexNumber2 >= 70, "Medium",

                            FlexNumber1 >= 50 and FlexNumber1 < 70 and FlexNumber2 >= 50 and FlexNumber2 < 70, "Low",

                            "Informational"

                        )

| project-keep TimeGenerated,EventCount,EventStartTime,EventEndTime,EventType,EventProduct,EventVendor,EventSchema,EventSchemaVersion,EventResult,EventResultDetails,EventMessage,Dvc,DvcOsVersion,DstIpAddr,DstPortNumber,DstHostname,Dst,SrcIpAddr,SrcHostname,Src,EventSeverity,ThreatName

Unser kundenspezifischer ASIM-Parser für Vectra AI.

Das obige Beispiel zeigt, wie die Datennormalisierung dazu beiträgt, verschiedene Datenquellen in einem gemeinsamen Datenschema zu vereinheitlichen. Die Tabelle CommonSecurityLog enthält Daten, die im Common Event Format (CEF) von verschiedenen Arten von Datenquellen wie Firewalls, Proxies oder IDS/IPS-Appliances gesammelt werden.

Bei Ontinue setzen wir ASIM auch ein, um Alarme von verschiedenen IDS/IPS-Lösungen mit einer einzigen Analyseregel als Incidents anzuzeigen. Da Sentinel nur 512 Analyseregeln pro Log Analytics Workspace unterstützt, hilft uns dieser Ansatz, unsere Use Case-Bibliothek schlank zu halten, und verhindert, dass sie durch herstellerspezifische Regeln aufgebläht wird.

Fazit

Die Sicherheitslösungen von Microsoft bieten zwar eine solide Grundlage, aber wenn man sich nur auf die Out-of-the-Box-Fähigkeiten verlässt, entstehen erhebliche Lücken, sowohl bei der Abdeckung als auch bei der Qualität der Alarme. Der ION Detection Stack von Ontinue behebt diese Blind Spots, indem er die Fähigkeiten von Microsofts Sicherheitsprodukten ergänzt und mit benutzerdefinierten Analyseregeln für eine breite Palette von Datenquellen erweitert. Wir stellen nicht nur Anylaseregeln bereit, sondern entwickeln sie, testen sie und optimieren sie kontinuierlich, um eine zuverlässige, ganzheitliche Abdeckung Ihrer Umgebung zu gewährleisten.