Umfassende Abdeckung mit dem ION Detection Stack

Der ION Detection Stack deckt alle Bereiche Ihres Unternehmens ab, von Endpunkten wie Clients und Servern über Identitäten und Netzwerkgeräte bis hin zu Ihren Cloud-Anwendungen und Workloads.

Die meisten unserer Kunden setzen in ihren lokalen oder Cloud-Umgebungen vor allem Microsoft-Produkte ein, weshalb sie sich von vornherein für die Sicherheitslösungen von Microsoft entschieden haben. Aber ist die Erkennungsabdeckung, die diese Produkte von Haus aus bieten, gut genug? Und wie sieht es mit Angriffsflächen außerhalb des Anwendungsbereichs von Microsoft aus? In diesem Blog-Beitrag erfahren Sie, was Sie von Ontinues ION Detection Stack erwarten können und warum Sie sich nicht allein auf den Out-of-the-Box-Erkennungsinhalt verlassen können.

Ganzheitliche Abdeckung

Unser Erkennungsstack verwendet für jede Asset-Kategorie einen mehrschichtigen Ansatz, der die Erkennungsfunktionen von Microsoft mit Lösungen von Drittanbietern, die Sie möglicherweise bereits in Ihrem Unternehmen einsetzen, und natürlich mit unseren eigenen benutzerdefinierten Erkennungsinhalten erweitert.

Microsofts Sicherheitsprodukte, kombiniert mit den benutzerdefinierten Inhalten von Ontinue und Ihren Protokollquellen von Drittanbietern

Stellen Sie sich das folgende Szenario vor: Auf Ihren Windows-Laptops und -Servern bietet Defender for Endpoint (MDE) ausreichenden Schutz und Erkennung gegen die heutige Bedrohungslandschaft. Aber selbst wenn Sie stark in Microsoft-Produkte und -Lösungen investiert haben, haben Sie vielleicht noch eine kleine Anzahl von Linux-Servern, die irgendwo laufen und einen Nischenzweck erfüllen. Obwohl MDE auf Linux eine Option für diese Szenarien ist, können oder wollen viele unserer Kunden keinen anderen Agenten auf diesen Endpunkten installieren - sei es aufgrund fehlender offizieller Unterstützung für ihre Linux-Distribution oder aufgrund von Bedenken hinsichtlich einer verminderten Leistung. Um diesen blinden Fleck zu vermeiden, bietet unser Erkennungs-Stack eine alternative Abdeckung mit nativen Betriebssystem-Telemetriedaten, die vom Linux-Audit-Daemon (Auditd) gesammelt und über Syslog an Sentinel weitergeleitet werden. Neben diesen benutzerdefinierten Analyseregeln bieten wir unseren Kunden auch Anleitungen für die Audit-Konfiguration, um sicherzustellen, dass alle relevanten Ereignisse protokolliert werden.

Wir verfolgen denselben mehrschichtigen Ansatz für Ihre Identitäten. Während Defender for Identity und Entra ID Protection Ihre Identitätsverzeichnisse vor Ort und in der Cloud abdecken, gibt es in Ihrer Umgebung möglicherweise noch andere Bereiche, in denen sensible Identitätsdaten gespeichert sind. Um eine umfassende Abdeckung Ihrer Identitäten zu gewährleisten, erstreckt sich unser Erkennungsstack auf verschiedene IAM- und PAM-Lösungen.

Optimierte Out-of-the-Box-Analyseregeln

Microsoft Sentinel bietet eine hervorragende Erkennungsabdeckung für eine breite Palette von Protokollquellen, die Sie im Sentinel Content Hub durchsuchen können. Die entsprechenden Vorlagen für Analyseregeln sind Open Source, und Sie können alle Details, einschließlich der KQL-Abfragen, in Sentinel's GitHub Repository. Wie bei den Standardinhalten eines jeden SIEM-Anbieters ist jedoch eine sorgfältige Bewertung und Anpassung dieser Vorlagen erforderlich, bevor sie in großem Umfang eingesetzt werden. Bei der Erkennungstechnik ist die Unterscheidung von Signal und Rauschen von entscheidender Bedeutung, und viele Standardregeln generieren zu viele Warnungen, die auf gewöhnlichen, nicht bösartigen Aktivitäten in Ihrer Umgebung basieren. Wir identifizieren diese Szenarien und aktualisieren die Erkennungslogik von Microsoft mit unserem eigenen benutzerdefinierten Code, um die Präzision der Erkennung bösartigen Verhaltens zu erhöhen.

Zur Veranschaulichung sehen wir uns die Vorlage an, mit der verdächtige Azure-Rollenzuweisungen erkannt werden sollen. Die Originalvorlage finden Sie unter hier. Es verwendet einen Schwellenwert, um verdächtige Aktivitäten zu erkennen, und erstellt eine 14-tägige Basislinie, um bisher unbekannte IP-Adressen zu ermitteln.

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

Bei unseren Tests haben wir festgestellt, dass der maximal zulässige Rückblick von 14 Tagen für die Sentinel-Analyseregeln nicht geeignet ist, um zuverlässige Baselines für alle Arbeitsbereiche unserer Kunden zu erstellen. Da IP-Adressen flüchtig und daher für diese Art der Anomalieerkennung ungeeignet sind, mussten wir den ursprünglichen Erkennungsansatz aufgeben. Stattdessen haben wir uns dafür entschieden, diese Art von Azure-Aktivität mit verdächtigen Anmeldeaktivitäten zu korrelieren und Warnungen für Benutzer auszulösen, die während der Anmeldung ein erhöhtes Risiko aufweisen, bevor sie Rollenzuweisungen vornehmen. Mit dieser Verbesserung konnten wir nicht nur unsere internen Qualitätsstandards für die Erkennungsgenauigkeit erfüllen, sondern auch die Zeitplanung der Regel optimieren. Anstatt wie in der Vorlage festgelegt nur einmal pro Tag ausgeführt zu werden, wird unsere optimierte Regel nun stündlich ausgeführt, was die mittlere Erkennungszeit (MTTD) verbessert. Darüber hinaus konnten wir die Datenmenge, die die Abfrage verarbeiten muss, von 14 Tagen auf zwei Tage reduzieren.

Abgesehen von den oben erwähnten Abfrageoptimierungen gibt es noch einige andere Verbesserungen, die wir vornehmen, bevor wir eine sofort einsatzbereite Regel in unseren ION-Erkennungsstapel aufnehmen:

• Kein Kunde ist wie der andere, aber unsere Analyseregeln müssen bei allen Kunden gut funktionieren. Wir fügen anpassbare Variablen in unsere Vorlagen ein, die dynamisch ausgewertet werden, wenn wir sie über unsere CI/CD-Pipeline in den Arbeitsbereichen unserer Kunden bereitstellen. Auf diese Weise können wir Schwellenwerte oder gutartiges Verhalten speziell für jeden Kunden abstimmen und maßgeschneiderte Erkennungen erstellen.
• Wir passen den Schweregrad der Warnmeldungen an unsere eigene Schweregrad-Methodik an. Ein Rahmenwerk, das die Auswirkungen, die Genauigkeit und die Kritikalität von Assets berücksichtigt, sorgt für Konsistenz bei allen Erkennungen. Regeln mit höherem Schweregrad werden so häufig wie möglich ausgewertet, um Verstöße frühzeitig zu erkennen.
• Entitäten wie Hosts, Konten, IP-Adressen und andere werden mit starken Identifikatoren abgebildet. Wir versuchen zum Beispiel, eine Identität nicht nur anhand ihrer sAMAccountName sondern auch durch den entsprechenden Domänennamen, so dass Microsofts Alert Correlation Engine die Entität eindeutig identifizieren und damit verbundene Alerts korrekt zu Vorfällen zuordnen kann. Dies wiederum hilft unseren Analysten, sich bei Untersuchungen ein Gesamtbild zu machen.
• Wir korrigieren fehlerhafte Zuordnungen zu Taktiken und Techniken des MITRE ATT&CK-Frameworks, um sicherzustellen, dass wir uns unserer Erkennungsmöglichkeiten und potenzieller blinder Flecken stets bewusst sind.

Lückenanalyse und individuelle Erkennung

Die Erkennungsfunktionen von Microsoft für Erstanbieter durch Defender XDR sind hervorragend. Die Taktiken Ihrer Gegner entwickeln sich jedoch ständig und schnell weiter, da sie neue Wege finden, um Ihre Verteidigungsmaßnahmen zu durchbrechen. Wir analysieren ständig neue Bedrohungen und bewerten, ob und wie sie erkannt werden. Für jeden blinden Fleck, den wir entdecken, entwickeln wir unsere eigenen benutzerdefinierten Analyseregeln.

Im Laufe der Zeit haben wir systematisch eine umfangreiche Bibliothek mit benutzerdefinierten Erkennungsregeln aufgebaut, die ein breites Spektrum des MITRE ATT&CK-Frameworks abdecken und blinde Flecken abdecken, die wir in den Erkennungsfunktionen von Microsoft entdeckt haben. Unsere neuesten Ergänzungen umfassen beispielsweise benutzerdefinierte Erkennungen für Token-Diebstahlszenarien und Gerätecode-Phishing, da Angreifer von der Kompromittierung Ihrer Endpunkte zum direkten Abgreifen Ihrer Daten aus SaaS-Anwendungen übergehen.

Manchmal erkennt Microsoft erfolgreich eine Bedrohung, gibt aber aufgrund der internen Korrelationslogik keine Warnung über die erkannte Aktivität aus. Nach einem erfolgreichen Token-Diebstahl zum Beispiel spielen Angreifer den gestohlenen Token erneut ab, um das Konto des Opfers zu kompromittieren. Während der Standort des Angreifers oder andere Anmeldungseigenschaften in Entra ID Protection Warnungen auslösen können, werden diese Warnungen oft von Entra ID Protection selbst behoben und automatisch geschlossen, da der Benutzer die Multi-Faktor-Authentifizierung (MFA) erfolgreich bestanden hat. Diese Art von blinden Flecken veranlasst uns, Erkennungsmöglichkeiten innerhalb der nativen Telemetrie von Microsoft zu identifizieren und dann benutzerdefinierte Erkennungen zu entwickeln, um diese Telemetrie zu nutzen.

Wir unterstützen und ergänzen nicht nur die Sicherheitsprodukte von Microsoft, sondern bieten auch eine Erkennungsabdeckung außerhalb ihrer Reichweite. Denken Sie zum Beispiel an die Kronjuwelen Ihres Unternehmens. Ganz gleich, ob Sie Ihre Produktion und Logistik mit SAP steuern oder sensibles geistiges Eigentum in einem Code-Repository wie GitHub hosten - wir bieten Schutz für Ihre kritischen Ressourcen. Bei neuen Arten von Protokollquellen arbeiten wir aktiv mit Ihnen zusammen, um neue benutzerdefinierte Erkennungsfunktionen zu entwickeln.

Normalisierung der Daten

Sicherheitsprodukte verfügen in der Regel über ein eigenes, maßgeschneidertes Protokollformat mit unterschiedlichen Feldnamen für denselben Inhalt. Web-Proxy-Produkte protokollieren zum Beispiel eine URL in Feldern mit den Namen url_s, requestUri_s, oder RequestURL. Dies stellt eine Herausforderung dar, wenn Abfragen über mehrere Arten von Protokollen ausgeführt werden müssen. Durch die Umwandlung herstellerspezifischer Protokolle in ein gemeinsames Datenschema wird sichergestellt, dass das SOC problemlos auf alle von Ihnen erfassten und aufgenommenen Daten zugreifen kann. Die Datennormalisierung vereinfacht die Erstellung von Abfragen für Erkennungsregeln, Vorfallsuntersuchungen, Bedrohungsjagden und Automatisierungsworkflows.

Microsofts Ansatz für die Datennormalisierung in Sentinel ist das Advanced Security Information Model (ASIM), das die Umwandlung Ihrer Protokollquellen zur Aufnahme- und Abfragezeit unterstützt. Sentinel wird mit zahlreichen Parsern für gängige Protokollquellen ausgeliefert, und das Team von Ontinue schreibt bei Bedarf eigene Parser.

CommonSecurityLog 
| where DeviceVendor == "Vectra Networks" und 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 = "NetzwerkSitzung"
| extend EventSchemaVersion = "0.2.6"
| extend EventResult = "Erfolg"
| extend EventMessage = tostring(Aktivität)
| extend ThreatName = tostring(Aktivität)
| extend EventResultDetails = "NA"
| Dvc erweitern = DeviceAddress
| extend DvcOsVersion = tostring(DeviceVersion)
| extend DstIpAddr = tostring(DestinationIP)
| extend DstPortNumber = toint(DestinationPort)
| extend DstHostname = tostring(column_ifexists("DestinationHostName", ""))
| extend Dst = DstIpAddr
| SrcIpAddr = tostring(SourceIP) erweitern
| extend SrcHostname = tostring(column_ifexists("SourceHostName", ""))
| Src erweitern = SrcIpAddr
| extend EventSeverity = case(
                            FlexNumber1 >= 90 und FlexNumber2 >= 90, "Hoch",
                            FlexNumber1 >= 70 und FlexNumber2 >= 70, "Mittel",
                            FlexNumber1 >= 50 und FlexNumber1 = 50 und FlexNumber2 < 70, "Niedrig",
                            "Informativ"
                        )
| 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-Alarmnormalisierungsparser für Vectra AI.

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

Bei Ontinue setzen wir ASIM ein, um Warnmeldungen von verschiedenen IDS/IPS-Lösungen mit einer einzigen Analyseregel als Vorfälle anzuzeigen. Da Sentinel nur 512 geplante Analyseregeln pro Arbeitsbereich unterstützt, hilft uns dieser Ansatz, unsere Anwendungsfallbibliothek schlank zu halten, und verhindert die Aufblähung, die herstellerspezifische Regeln verursachen würden.

Das ION-Ticketing-Tool zeigt Vorfälle von Darktrace AI, Vectra AI, Palo Alto und Azure Firewall an, die von einer einzigen Analyseregel generiert wurden.

Schlussfolgerung

Die Sicherheitslösungen von Microsoft bieten zwar eine solide Grundlage, aber wenn man sich nur auf die Standardfunktionen verlässt, entstehen erhebliche Lücken, sowohl bei der Abdeckung als auch bei der Erkennungsqualität. Der ION Detection Stack von Ontinue behebt diese blinden Flecken, indem er die Erkennungsfunktionen von Erstanbietern ergänzt und mit benutzerdefinierten Analysen für eine breite Palette von Protokollquellen erweitert. Wir stellen nicht nur Erkennungsinhalte bereit, sondern entwickeln sie, testen sie und optimieren sie kontinuierlich, um eine zuverlässige, ganzheitliche Abdeckung Ihres Unternehmens zu gewährleisten.