Elastic Security als offene Lösung: Vorteile für Sicherheitsteams mit vordefinierten Schutzmaßnahmen

Erkennungsinhalte für Detection Engineers

Elastic Security enthält jetzt mehr als 1.100 vordefinierte Regeln zur Bedrohungserkennung, mit denen die Nutzer ihre Erkennung und Sicherheitsüberwachung schnellstmöglich einrichten können. Unter diesen mehr als 1.100 Regeln befinden sich mehr als 760 SIEM-Erkennungsregeln, die mehrere Log-Quellen berücksichtigen. Der Rest wird auf Endpoints ausgeführt und verwendet Elastic Security für Endpoints.

Elastic hat sich der Sicherheits-Community gegenüber zu Transparenz und Offenheit verpflichtet. Darum erstellen und pflegen wir unsere Erkennungslogik öffentlich in Zusammenarbeit mit allen, die sich dafür interessieren. Wir teilen unsere Forschung, unsere Regeln und andere Erkenntnisse mit der Sicherheits-Community, damit die Mitglieder daraus lernen und weitere Verbesserungen vornehmen können.

Sämtliche Inhalte sind nicht nur in Elastic Security integriert und sofort verfügbar, sondern werden auch als öffentliche GitHub-Repositorys (SIEM-Erkennungsregeln, Endpoint-Regeln) bereitgestellt.

Wir schrecken nicht vor dem Vergleich mit anderen Erkennungsprodukten zurück, darum finden Sie Elastic Security auch auf der Tidal Cyber-Plattform.

Warum teilen wir unsere Sicherheitsinhalte?

Uns ist völlig klar, dass nicht jedes Unternehmen über die nötigen Ressourcen verfügt, um neue Bedrohungen erforschen und mit den neuesten verfügbaren Technologien und Features erkennen zu können. An dieser Stelle kommt Elastic Security als zusätzliche Ressource für Ihr Sicherheitsteam ins Spiel.

Das Elastic TRADE-Team (Threat Research and Detection Engineering) erforscht aufkommende und weithin eingesetzte Bedrohungen, um Erkennungs- und Vermeidungsregeln für unsere Nutzer zu entwickeln und zu pflegen. Das Team liefert außerdem Feedback zur Verbesserung der verschiedenen Abfragesprachen, die für Sicherheitsanwendungsfälle eingesetzt werden. Das TRADE-Team arbeitet eng mit unserem internen InfoSec-Team sowie mit anderen Engineering-Teams zusammen, um sicherzustellen, dass das Feedback für fortlaufende Verbesserungen eingesetzt wird.

Im weiteren Verlauf dieses Blogeintrags zeigen wir Ihnen, wie Sie die SIEM-Erkennungsregeln und verwandten Sicherheitsinhalte nutzen können und wie diese Inhalte erstellt werden. Lassen Sie uns anfangen!

Elastic-Regelerstellungsprozess

1. Thema identifizieren

Die Regelerstellung beginnt damit, dass wir zunächst anhand von Forschungsinitiativen, der aktuellen Bedrohungslandschaft und von Abdeckungsanalysen ein Thema auswählen, mit dem wir uns befassen werden. Dabei berücksichtigen wir außerdem verfügbare und beliebte Integrationen, Nutzeranfragen und Trends.

2. Thema studieren

Nachdem wir eine Technologie, eine Bedrohung oder eine Taktik identifiziert haben, studieren wir sie ausführlich. Sehen Sie sich ein Beispiel für eine solche Analyse für Google Workplace an. Wir befassen uns eingehend mit der Architektur und den bereitgestellten Diensten und identifizieren potenzielle Angriffstechniken, die normalerweise dem MITRE ATT&CK Framework® zugeordnet werden.

3. Laborumgebung erstellen

Für die Arbeit an den Regeln benötigen wir eine Laborumgebung, in der wir die Bedrohung simulieren und notwendige Daten generieren können, um die Erkennungslogik zu erstellen und zu testen. Im obigen Beispiel können Sie einen Blick hinter die Kulissen einer solchen Laborerstellung für Google Workplace werfen. Diesen Ansatz verfolgen wir auch für die Erstellung und Pflege der Laborumgebungen für sämtliche Datenquellen, für die wir Regeln erstellen.

4. Regeln erarbeiten

Normalerweise legen die Regelautoren fest, welcher Regeltyp verwendet wird. Anschließend befolgen sie Best Practices, um eine leistungsstarke Erkennungslogik mit einem Minimum an Falschmeldungen zu entwickeln und die Regeldatei mit allen erforderlichen Metadatenfeldern zu erstellen. Die Philosophie des TRADE-Teams steht beim Entwickeln und Testen der Regeln stets im Mittelpunkt.

5. Peer Review durchführen

Im nächsten Schritt wird die Regel einem Peer Review unterzogen. Selbstverständlich müssen sich die Reviewer mit der Technologie und den Bedrohungen auskennen, mit denen sich die neue Erkennungsregel befasst. Diese Kollegen prüfen die vorhandene Erkennungslogik, um Grenzfälle zu identifizieren, in denen die Regel potenzielle Fehler aufweist. Regeln dürfen weder leicht zu umgehen sein noch ein zu hohes Grundrauschen in Kundenumgebungen verursachen, darum ist es wichtig, die richtige Balance zu finden.

6. Betrachtungen zur Abdeckung

Im Hinblick auf die Optimierung unserer Abdeckung prüfen wir auch, ob die neue Erkennung nicht in eine vorhandene Regel integriert werden könnte, und ob dies aus der Perspektive von Sicherheitsanalysten beim Untersuchen der generierten Warnungen sinnvoll wäre. Auf diese Weise können sich Regelautoren auf Qualität anstelle von Quantität konzentrieren. 

Bei diesem Verfahren stellen wir manchmal fest, dass eine Regel zu viele Fehlerkennungen generiert, und legen sie für die Veröffentlichung als Bausteinregel beiseite. Möglicherweise bemerken wir auch Lücken in der Datenabdeckung, die die Erstellung einer effektiven Erkennungslogik verhindern, und arbeiten mit anderen Elastic-Teams zusammen, um diese Lücken zu schließen, wodurch sich die Regelerstellung verzögert.

Uns ist klar, dass die Abdeckung durch vordefinierte Erkennungsregeln nicht für jede Umgebung perfekt ist. Darum können Sie die Regeln in Kibana forken, falls Sie Anpassungen vornehmen möchten. Alternativ können Sie auch Ausnahmen zu einer Regel hinzufügen, um sie an Ihr Bedrohungsmodell und an Ihre einzigartige Umgebung anzupassen. Lesen Sie mehr über unsere Herangehensweise für die Regelentwicklung, um genau zu verstehen, was Sie von unseren Regeln erwarten können.

Sie können unserer Regelentwicklung im Repository für Erkennungsregeln folgen. Falls Sie eine Regel haben, die Sie gerne mit anderen Elastic-Nutzern teilen möchten, können Sie sie dem Beispiel anderer Nutzer folgen und sie über unser Repository mit der Community teilen.

Ein Moment! Neue Regeln sind nicht alles!

Neben der Arbeit an neuen Regeln verbringt das Team auch viel Zeit damit, vorhandene Regeln zu überwachen und zu optimieren. Gelegentlich werden auch Regeln als veraltet markiert, die nicht mehr unseren Standards entsprechen.

Wir lieben Daten, darum haben wir uns die letzten 600 Pull Requests im Repository für Erkennungsregeln angesehen und analysiert, welche Verbesserungen wir an den Erkennungsregeln vorgenommen haben. In diesem Diagramm sehen Sie, dass wir mehr Optimierungs- und Wartungsarbeiten vorgenommen als neue Regeln erstellt haben, um dafür zu sorgen, dass die Erkennungsregeln stets hochwertig und aktuell bleiben.

Die Forscher der Elastic Security Labs analysieren regelmäßig Telemetriedaten, um anhand von Warnungshäufigkeiten und regelspezifischen Parametern zu ermitteln, welche Regeln verbessert werden sollten.

Die Elastic Security-Telemetrie wird freiwillig von unseren Nutzern geteilt und eingesetzt, um die Produkt-Performance und die Effizienz der Features zu verbessern. Apropos, der neueste Elastic Global Threat Report basiert auf den Daten, die unsere Nutzer geteilt haben. In unserem Threat Report haben wir globale Beobachtungen und Kontextdaten für die Bedrohungslandschaft geteilt, um Sie bei der Erstellung benutzerdefinierte Regeln zu unterstützen.

Beim Überprüfen der Telemetrie auf Regeleffizienz achten die Experten insbesondere auch auf die Bedrohungserkennung und überprüfen tatsächliche Positivmeldungen (True Positives, TP). Die TP-Telemetrie erfordert einen eigenen Triage-Workflow, kann jedoch unter Umständen zur Entwicklung neuer Regeln oder zu eingehenderen Untersuchungen führen. Das TRADE-Team führt auch Forschungs- und Analysearbeiten für die Elastic Security Labs durch, insbesondere im Hinblick auf technische Themen wie Reverse Engineering von Malware, Angreiferprofilerstellung, Infrastruktur-Discovery und Erfassung atomischer Indikatoren. Bei dieser Forschung arbeiten wir oft mit anderen internen Teams zusammen. 

Erkennungsinhalte für Sicherheitsanalysten

Erkennungsregeln werden nicht nur von Detection Engineers eingesetzt, sondern auch von Sicherheitsanalysten, die an Warnungs-Triage und Untersuchungen beteiligt sind.

Wir liefern zusätzlichen Bedrohungskontext für Sicherheitsanalysten, indem wir die Regeln mit zusätzlichen Informationen wie Untersuchungsanleitungen anreichern. Die Regelautoren fügen Informationen zu Angriff und Verhaltensweisen sowie Hinweise für Untersuchungen, Falschmeldungen, Analysen und Schritte zur Behebung hinzu. Diese Informationen sind sehr hilfreich für Analysten, die eine Warnung entdecken und schnell verstehen müssen, warum die Warnung ausgelöst wurde und was als Nächstes zu tun ist. Die Untersuchungsanleitung kann direkt in der Warnmeldung in der Elastic Security-Lösung angezeigt werden.

Erstellen Sie nach Möglichkeit auch Untersuchungsanleitungen für Ihre benutzerdefinierten Regeln. Diese Anleitungen sind für Sicherheitsteams von unschätzbarem Wert.

Unser Ziel ist eine vollständige Abdeckung der Bedrohungserkennungsregeln mit Untersuchungsanleitungen. Zum Zeitpunkt dieser Veröffentlichung sind Untersuchungsanleitungen für etwa 30 % aller vordefinierten Regeln verfügbar. Mit dem Tag „Investigation Guide“ können Sie mühelos Regeln herausfiltern, für die Anleitungen verfügbar sind.

Die Produkttelemetrie wird auch verwendet, um die Erstellung der Anleitung zu priorisieren. Wir suchen nach den meistverwendeten Regeln und versuchen, möglichst hilfreiche Informationen für unsere Nutzer bereitzustellen.

Unsere Roadmap besteht aus fortlaufenden Verbesserungen an den Untersuchungsanleitungen mit Empfehlungen zu Triage und Behebung, sowie aus Feature-Verbesserungen. Ab Elastic Stack Version 8.5 enthalten manche Untersuchungsanleitungen beispielsweise benutzerdefinierte nutzbare Osquery-Abfragen, um zusätzliche Telemetrie von Endpoints für Analyse- oder Triagezwecke anzufordern.

Falls Sie Feedback oder Vorschläge zu den Untersuchungsanleitungen haben, können Sie jederzeit ein GitHub-Ticket erstellen. Wir freuen uns über alle Community-Beiträge!

Ohne eine hochwertige Erkennungslogik ist es praktisch unmöglich, potenzielle Bedrohungen zu identifizieren, aber uns ist auch klar, wie wichtig zusätzlicher Kontext zu bestimmten Bedrohungen für Analysten ist. Elastic bemüht sich, die vordefinierten Regeln zur Bedrohungserkennung mit möglichst viel Kontext anzureichern.

Neben den Untersuchungsanleitungen ordnen wir sämtliche Regeln zur entsprechenden MITRE ATT&CK-Matrix zu und identifizieren Schweregrad und Risiko des Angriffs für Sie. Und obwohl es manchmal schwierig ist, beim Ingestieren verschiedener Datenquellen die passenden Regeln auszuwählen, unterstützen wir Sie dabei, zu identifizieren, welche Integrationen für einzelne Regeln erforderlich sind. Mit dem Feld „Related Integrations“ (Verwandte Integrationen) können Sie zu einer relevanten Integration navigieren, diese einrichten und bei Bedarf die entsprechende Regel aktivieren, um sicherzustellen, dass Sie die richtigen Datensätze ingestieren.

Regelaktualisierungen, etwa mit zusätzlichem Kontext, werden regelmäßig außerhalb des normalen Updatezyklus veröffentlicht und direkt in der Elastic Security-Lösung für unsere Nutzer bereitgestellt. Verwenden Sie nach Möglichkeit immer die neuste Version des Stack, um die Regeln, die auf den neuen Sicherheits-Features basieren, vollständig nutzen zu können.

War das alles?

Das TRADE-Team ist außerdem dafür zuständig, ein Feature der Erkennungsregeln zu erarbeiten und zu veröffentlichen, das wir Red Team Automation (RTA) nennen. Dieses in Python geschriebene Feature ist hilfreich zum Testen der Regeln. Mit den RTA-Skripts generiert das Team gutartige TPs und automatisiert Regressionstests der Erkennungsregeln mit verschiedenen Versionen der Elastic Security-Lösung. Sie können die veröffentlichten RTA-Skripts auch verwenden, um eigene Tests durchzuführen oder um neue Tests für Ihre benutzerdefinierten Regeln zu erstellen.

Weitere Informationen zu RTA und den weiteren vom TRADE-Team bereitgestellten Tools finden Sie in diesem Blogeintrag.

Bleiben Sie dran.

Wie Sie sehen, stellen wir ständig neue vordefinierte Inhalte für den gesamten Erkennungs-Workflow und den Lebenszyklus der Regeln bereit, von der Erstellung über die Nutzung und Wartung bis hin zu Tests. Und wie bereits erwähnt werden all diese Inhalte direkt im Produkt bereitgestellt und auf GitHub offen mit unserer Community geteilt.

Wir sind ständig bemüht, die Sicherheit der Systeme unserer Kunden zu verbessern und das Leben von Sicherheitsteams zu erleichtern. Falls Sie Ideen oder Problemen haben, können Sie sich jederzeit an uns wenden. Sie erreichen uns über unsere Slack-Community oder in unserem Diskussionsforum.