Elastic Security öffnet sein Erkennungsregel-Repo

Wir bei Elastic glauben an das Potenzial von Open Source und wissen, wie wichtig die Community ist. Für uns ist die Community unsere Top-Priorität und wir sorgen dafür, dass wir das bestmögliche Produkt für unsere Nutzer schaffen. Zu den Kernzielen von Elastic Security gehört es, Bedrohungen jeder Art und Größe zu stoppen und Analysten mit den nötigen Tools auszustatten. Mit dem heutigen Tag machen wir ein neues GitHub-Repository, elastic/detection-rules, öffentlich zugänglich, um in Ergänzung der Beiträge der Security-Community Bedrohungen in noch größerem Maße den Kampf anzusagen.

Mit der Veröffentlichung der Erkennungs-Engine in Elastic Security haben wir den Elastic Stack um die automatisierte Bedrohungserkennung erweitert. Seit dem Start der Erkennungs-Engine hat das Elastic Security Intelligence & Analytics Team über 50 weitere Regeln hinzugefügt, was zu einer erhöhten Sichtbarkeit von Angriffsmethoden auf Linux-, macOS- und Windows-Systemen geführt hat. Wir arbeiten daran, die Abdeckung weiter zu verbessern, und im Zuge dieser Verbesserungen werden wir die Breite der Erkennungen ausbauen und auch neue Bereiche, wie Clouddienste und Nutzerverhalten, abdecken.

In den letzten Versionen haben wir für die Verwaltung der Regeln für die Erkennungs-Engine ein internes Repository genutzt. Wir haben unsere Testverfahren Schritt für Schritt verbessert, indem wir automatisierte Tests für neue Beiträge hinzugefügt haben, die die Kibana Query Language(KQL)-Syntax, die Schemanutzung und andere Metadaten validieren. Unsere Regelentwicklung ist jetzt ausgereifter, sodass wir schnell vorankommen, ohne anderes dafür kaputt zu machen.

Durch die Öffnung unseres GitHub-Repository elastic/detection-rules lädt Elastic Security die Community ein, eigene Regeln beizusteuern, die parallel zu den von uns entwickelten Regeln zur Verfügung gestellt werden. Für uns alle bietet sich damit die Gelegenheit, unser kollektives Wissen auszutauschen, voneinander zu lernen und zusammenzuarbeiten, um unsere Ziele zu erreichen.

Was gibt es in diesem neuen Repository?

Im GitHub-Repository elastic/detection-rules finden Sie für Elastic Security geschriebene Regeln, die viele MITRE ATT&CK®-Methoden abdecken. Unsere aktuelle Regellogik ist primär in KQL geschrieben und durch Nutzung des Elastic Common Schema (ECS) müssen wir Regeln nur noch ein einziges Mal schreiben. Dank der definierten Felder und Kategorien in ECS funktionieren Regeln automatisch mit Beats-Logs und anderen Datenquellen, die vom ECS unterstützt werden.

Innerhalb des Ordners rules/ sind die Regeln in TOML-Dateien gespeichert und nach Plattform zusammengefasst. Wir haben versucht, durch eine flache Hierarchie dafür zu sorgen, dass Regeln einfach gefunden und neue Regeln unkompliziert hinzugefügt werden können. Wenn Sie z. B. nach rein Windows-spezifischen Regeln suchen, gehen Sie einfach zu rules/windows. Wenn Sie trotzdem Probleme haben, eine Regel zu finden, oder wenn Sie in allen Regeln suchen möchten, können Sie unsere CLI verwenden, indem Sie den Befehl python -m detection_rules rule-search ausführen. Daraufhin werden die Dateien mit übereinstimmenden Metadaten angezeigt.

Jede Regel enthält zusätzlich zur eigentlichen Abfrage mehrere Felder mit Metadaten, wie Titel, Beschreibung, Rauschpegel, ATT&CK-Mappings, Tags und Ausführungsintervall. Außerdem gibt es noch ein paar zusätzliche Felder, um Analysten bei der Sichtung zu unterstützen. Sie beschreiben falsch positive Ergebnisse oder zeigen hilfreiche Schritte für die Untersuchung auf. Weitere Informationen zu den Metadaten in Bezug auf Regeln finden Sie im Leitfaden zum Erstellen von Kibana-Regeln und in unserer Zusammenfassung der Regel-Metadaten im Leitfaden zum Beisteuern von Erkennungsregeln.

Wie kommen diese Regeln in meine Erkennungs-Engine?

Ob Sie unseren verwalteten Elastic Cloud-Dienst oder die Standarddistribution der Elastic Stack-Software mit dem vollständigen Satz kostenloser Features nutzen, Sie erhalten in jedem Fall die allerneuesten Regeln, sobald Sie zum ersten Mal zur Erkennungs-Engine navigieren. Bei einem Upgrade erkennt die Erkennungs-Engine, dass Regeln hinzugefügt oder geändert wurden, und fordert Sie auf anzugeben, ob diese Regeln entsprechend aktualisiert werden sollen. Um die neueste Version der Regeln zu erhalten, müssen Sie nach dem Upgrade nur die angezeigten Schritte ausführen.

Wer wird das Repository nutzen?

In diesem Repository wird das Security Intelligence & Analytics-Team von Elastic Regeln entwickeln, Issues erstellen, Pull-Anfragen verwalten und festlegen, ab welchen Versionen die Regeln gelten sollen. Wir haben das Repo offen zugänglich gemacht, weil wir alle externen Nutzer einladen möchten, an diesem Workflow mitzuwirken. Damit machen wir unseren Entwicklungsprozess transparent und zeigen, welche Regeln zukünftig in der Erkennungs-Engine veröffentlicht werden sollen.

Wenn Sie sich einbringen möchten, unterschreiben Sie bitte das Contributor License Agreement (CLA) von Elastic. Dies ist die Standardvereinbarung für alle Elastic-GitHub-Repositorys, mit der Sie zustimmen, dass wir Ihren Code kostenlos an Elastic-Nutzer verteilen dürfen.

Wie gehen wir an die Bedrohungserkennung heran?

Im Allgemeinen bevorzugen wir Regeln, die auf die Erkennung schädlicher Verhaltensweisen abzielen. Das bedeutet in der Regel, dass wir uns auf ATT&CK-Methoden konzentrieren. Wir nehmen damit in Kauf, dass zusätzlicher Aufwand, zum Beispiel für die Recherche, erforderlich ist, um vor dem Erstellen einer Regel mehr darüber zu erfahren, wie die entsprechende Methode funktioniert. Aber so gelingt es uns besser, nicht nur die Angriffe von gestern, sondern auch die Angriffe von heute und morgen zu erkennen und zu stoppen.

Dieser verhaltensbasierte Ansatz bedeutet auch, dass wir verschiedene Arten von Regeln brauchen. Einige erkennen möglicherweise winzig kleine Ereignisse, andere erfordern unter Umständen die Aggregation mehrerer Ereignisse oder die Suche nach Abweichungen über einem Schwellenwert. Mit Event Query Language (EQL) sind wir in der Lage, Regeln zu schreiben, die nach Verhaltensabfolgen suchen, die für mehrere Ereignisse gelten.

Natürlich ist uns bewusst, dass es manchmal Angriffsmethoden gibt, die nicht alle Nutzer aufgrund ihres Verhaltens erkennen können. Zögern Sie in diesem Fall bitte nicht, eine Regel hinzuzufügen, die eher signaturartig funktioniert und auf ein bestimmtes Verhalten oder Tool ausgerichtet ist.

Wenn Sie mehr dazu erfahren möchten, welche Eigenschaften einen ausgereiften Erkennungsmechanismus auszeichnen, lesen Sie unseren Artikel zur Philosophie des Repository für Erkennungsregeln.

Warum brauchen wir ein neues Repository?

Wenn Sie schon einmal Regeln öffentlich geteilt haben, kennen Sie wahrscheinlich bereits andere etablierte GitHub-Repositorys, wie das Cyber Analytics Repository (CAR) von MITRE, Sigma oder sogar die auf EQL von Elastic basierende EQL Analytics Library. Vielleicht fragen Sie sich nun Folgendes: Warum brauchen wir noch ein Repository? Warum nutzen wir nicht, was bereits vorhanden ist?

Die beste Antwort auf diese Frage beginnt mit einer weiteren Frage: Warum gibt es die anderen Repositorys? Sowohl CAR als auch Sigma sind absichtlich sprachen- oder plattform- und manchmal datenquellenunabhängig. Die EQL Analytics Library hingegen basiert auf einer bestimmten Sprache.

Mit unserem neuen Repository für Erkennungsregeln wollen wir einen etwas anderen Zweck erfüllen: Nutzer von Elastic Security sollen damit die bestmöglichen Erkennungen erhalten, die für viele Datenquellen funktionieren. Wir fassen die verschiedensten Schemas im ECS zusammen, wodurch es möglich ist, Regeln zu schreiben, die für mehrere Datenquellen gelten.

Der Elastic Stack unterstützt mehrere Sprachen und das soll sich auch in unseren Regeln widerspiegeln. Abfragesprachen werden typischerweise für unterschiedliche Arten von Problemen geschrieben, und wir sollten Regelentwickler nicht auf eine einzelne Sprache beschränken, wenn eine andere besser für den Zweck geeignet ist. Wir haben derzeit im Repository neben Regeln, die Machine-Learning-Anomalieerkennungsjobs nutzen, KQL- und Lucene-Regeln. Gegenwärtig arbeiten wir eifrig daran, EQL in den Elastic Stack und in unser Repository zu bringen.

Außerdem können wir im Sinne einer optimalen Elasticsearch-Performance sicherstellen, dass Best Practices befolgt werden. So muss bei der Suche nach process.path:*\\cmd.exe eine Prüfung auf Platzhalter durchgeführt werden, die teurer ist als eine einfache Prüfung auf Suchbegriffe. Anstelle einer Suche mit führenden Platzhalterzeichen können wir die Verwendung von process.name:cmd.exe empfehlen. Das bringt nicht nur schnellere, sondern auch genauere Ergebnisse. Zudem enthält ECS auch das Feld process.args, was eine geparste Version von process.command_line ist. Wir empfehlen, das geparste Feld zu verwenden, da sich dadurch nicht nur die Performance verbessert, sondern auch die Gefahr allzu einfacher Umgehungen durch Einfügung von Leer- oder Anführungszeichen reduziert – das sind zwei Fliegen mit einer Klappe!

Kann ich Regeln aus einem anderen Repository hinzufügen?

Wenn Sie durch Ihre Kibana-Rolle die richtigen Berechtigungen haben, können Sie der Erkennungs-Engine in Ihrer eigenen Umgebung gern Regeln hinzufügen. Möchten Sie allerdings das Repository elastic/detection-rules mit neuen Regeln erweitern, lautet die Antwort wenig überraschend: Kommt drauf an .... Sofern eine Regel unter der Elastic-Lizenz unterlizenziert werden kann, ist die Sache klar. Meist sind die Anforderungen ziemlich gerade heraus: Im Array rule.author müssen die ursprünglichen Autoren beibehalten werden und die Datei NOTICE.txt muss aktualisiert werden, damit auf die ursprünglichen Autoren verwiesen wird. Wir möchten nicht den Ruhm für die Arbeit anderer einheimsen und bitten Sie daher, bei diesen Angaben Sorgfalt walten zu lassen!

Wenn Sie mehr darüber wissen möchten, wie wir das Thema Lizenzierung im Repository handhaben, lesen Sie den Abschnitt Licensing in der README.

Wie kann ich mich einbringen?

Sie möchten Ihre Regellogik gern mit anderen teilen? Dann gehen Sie zu elastic/detection-rules auf GitHub. Dort finden Sie ausführliche Anweisungen zum Navigieren im Repository, zum Forken und Klonen sowie zum Erstellen einer Regel. Wir stellen ein Befehlszeilentool bereit, mit dem sich die Dateien gebündelt bearbeiten lassen und das das Erstellen neuer Regeln einfacher macht. Wenn Sie soweit sind und dem Repository eine neue Regel hinzufügen möchten, führen Sie python -m detection_rules create-rule aus; Sie werden dann nach den erforderlichen Metadaten gefragt. Wir empfehlen, nach Möglichkeit die CLI zu verwenden, da sie die Gefahr von Copy-and-Paste-Fehlern bei Wiederverwendung von Inhalten aus einer TOML-Datei aus einer anderen Regel oder Vorlage reduziert.

Wenn Sie mit Ihrer Regel erst einmal zufrieden sind, können Sie den Befehl python -m detection_rules test ausführen, um lokale Unittests zur Validierung von Syntax, Schemanutzung usw. durchzuführen. Erstellen Sie anschließend die Pull-Anfrage. Daraufhin wird sich ein Mitarbeiter des Intelligence & Analytics-Team Ihre Regel ansehen. Wenn wir Änderungen verlangen, arbeiten wir mit Ihnen zusammen, um zu einem gemeinsamen Ergebnis zu kommen. 

Sollten Sie eine gute Idee für eine Regel haben und diese Idee gemeinsam mit uns umsetzen oder unsere Meinung dazu hören möchten, können Sie gern ein New Rule-Issue erstellen. Wir freuen uns darauf, Ihnen zu helfen und gemeinsam an der Umsetzung zu arbeiten!

Weitere Informationen dazu finden Sie im Leitfaden zum Einreichen von Beiträgen.

Wie geht es weiter?

Willkommen bei unserem neuen Regel-Repository und dem zugehörigen Workflow! Wir laden Sie ein mitzumachen und würden uns freuen, im Feld rule.author Ihren Namen zu finden. Das Repository für Erkennungsregeln wird sich zusammen mit dem Rest von Elastic Security weiterentwickeln und wir sind gespannt auf das, was vor uns liegt.

Wenn Sie die Entwicklung von EQL im Stack verfolgen möchten, abonnieren Sie diesen GitHub-Issue. Oder werfen Sie einen Blick in die laufende Dokumentation, um zu sehen, woran das Elasticsearch-Team gerade arbeitet.

Wenn Sie Feedback für uns oder Fragen zum Schreiben von Regeln oder zum Navigieren in unserem neuen GitHub-Repository für Erkennungsregeln haben, erstellen Sie ein GitHub-Issue, äußern Sie sich im Diskussionsforum unter dem Tag detection-rules oder besuchen Sie den Kanal #detection-rules der Elastic Slack-Community.