SIEM Auswirkung, Schmerz, Handlungsfähigkeit und Schwere
Inhaltsverzeichnis:
Zweck
Ziel dieses Blogbeitrags ist es, die Metriken (Pain, Actionability, SIEM Impact und Severity) vorzustellen, die in den Threat Detection Marketplace von SOC Prime eingeführt wurden.
Einleitung
SOC Primes Threat Detection Marketplace steigert Ihre Sicherheitsoperationen mit qualitativ hochwertigem Erkennungsinhalt.Wie bei allen defensiven Technologien wird nicht empfohlen, alle möglichen Inhalte „out of the box“ zu implementieren, und die Wahl der Inhalte, die den größten Wert bieten, kann manchmal schwierig sein. Mit den neuen Metriken SIEM Impact, Pain, Actionability und Severity hofft SOC Prime, dass es einfacher wird, zu entscheiden, welche Regeln für Sie geeignet sind.
Diese Metriken spiegeln jedoch nicht direkt die Qualität eines Inhaltsitems wider. Eine Regel kann in den meisten Metriken eine niedrige Punktzahl haben, aber dennoch eine qualitativ hochwertige Erkennung sein.
- SIEM Impact: Ist der erwartete Performance-Einfluss auf ein SIEM
- Pain: Der Score zeigt, wo die Regel auf der Pyramide des Schmerzes liegt. Höhere Schmerz-Regeln sind ideal für Threat Hunter und L3-Operatoren.
- Benutzerfreundlichkeit: Wie offensichtlich ist die Triagierung. Ein hoher Benutzerfreundlichkeit-Score zeigt, dass ein L1-Analyst die nächsten Schritte schnell verstehen wird. Eine Regel mit niedrigerer Benutzerfreundlichkeit erfordert möglicherweise erweiterte Schritte wie Speicherforensik, Kontaktaufnahme mit dem Kontoinhaber oder viele zusätzliche Suchen.
- Schweregrad: Wie kritisch ist die Überprüfung von durch diese Logik verursachten Alarmen. Dies wird aus dem SIGMA-Level-Feld abgeleitet.
Pain, Benutzerfreundlichkeit und Schweregrad werden von dem Analysten angegeben, der die Regel in gutem Glauben erstellt hat, um die Eigenschaften der Regel widerzuspiegeln. SOC Prime überprüft alle Inhalte und kann die Werte auf Grundlage unseres Expertenwissens und Kundenfeedbacks anpassen. SIEM impact wird derzeit auf halbautomatisierte Weise zugewiesen und wird in Zukunft vollständig implementiert.
In den folgenden Abschnitten beschreibe ich, wie diese Metriken im Threat Detection Marketplace bewertet und behandelt werden.
Erhalt der Metriken
Wenn Sie im Suchfeld eine Regel auswählen, werden Metriken zu dieser Regel auf der rechten Seite des Bildschirms angezeigt. Diese Metriken stehen für Community- und exklusive Inhalte zur Verfügung.
SIEM Impact (1 – 3, höher bedeutet weniger Auswirkungen)
SIEM impact ist der erwartete Einfluss auf das System, gegen das Sie die Regel ausführen werden.
SIEMs sind Analysesysteme, die eine große Menge an Rechenleistung erfordern, um ein positives Ergebnis zu erzielen. Dies macht es zu einer täglichen Routine, jeden Aspekt der SIEM-Konfiguration feinabzustimmen. Personen, die jahrelang in der SIEM- und Detection-Engineering tätig waren oder mit den besten Praktiken von Regex vertraut sind, wissen, dass eine Regel mit einem Ausdruck wie event=/.*threat.*/ eine ‚hungrige‘ Regel ist. Fügen Sie eine davon in eine große Produktionsinstallation ein und Sie könnten ein langsameres Suchen erleben. Fügen Sie hundert hinzu, und selbst ein verteiltes System wird an Leistung verlieren. Wir haben beobachtet, dass verschiedene SIEM-Anbieter hungrige Anweisungen im Training als beste Praxis angeben, um zu betonen, wie einfach es ist, Bedrohungen zu finden. In der Produktion ist es jedoch wichtig, kosteneffiziente Regeln zu erstellen, und genau deshalb haben wir diese Metrik eingeführt.
Je komplexer die Regel und je mehr Rauschen in der Datenquelle(n) vorhanden ist, desto niedriger wird der SIEM Impact Score sein.
Bewertung | Logik | Begründung |
– | message enthält „a“ ODER „b“ ODER „c“ ODER „d“ ODER „e“ ODER „f“ ODER „g“ ODER „h“ ODER „i“ ODER „j“ ODER „k“ ODER „l“ ODER „m“ ODER „n“ ODER „o“ ODER „p“ ODER „q“ ODER „r“ ODER „s“ ODER „t“ ODER „u“ ODER „v“ ODER „w“ ODER „x“ ODER „y“ ODER „z“ ODER „1“ ODER „2“ ODER „3“ | Diese Regel würde nicht akzeptiert werden, da sie zu viele Auswirkungen hat. |
1 | user = „*$“ UND (commandline enthält „TVqAA“) (commandline enthält „http://“ ODER commandline enthält „https://“ ODER commandline enthält „ftp“ ODER commandline enthält „file:\\“) | Vieler Gebrauch von Wildcards/Enthalten |
2 | eventid=4688 UND commandline enthält „scrobj.dl“ | Die Nutzung von enthält erhöht die Last auf dem SIEM. |
3 | eventid:5140 UND sharename:Admin$ | Exakte Übereinstimmung auf Feldern ist optimal aus Leistungsperspektive |
_
Pain (1 – 3, höher ist verhaltensbasiert/schwerer zu umgehen)
Der Pain Score ist eine Abstraktion davon, wo die Regel auf David Biancos Pyramide des Schmerzes liegt und wie leicht die Logik umgangen werden kann. Je verhaltensbasierter und weniger wahrscheinlich die Regel umgangen werden kann, desto höher wird der Pain Score sein. Verhaltensregeln sind im Allgemeinen besser für die Bedrohungssuche und können oft lauter sein oder Dinge wie Stapelzählung erfordern, um effektiv zu sein. IOC-basierte Regeln sollten weniger Lärm verursachen, können aber sehr selten ausgelöst werden oder nur für historische Analysen nützlich sein. Das Deaktivieren oder vollständige Umgehen des Protokollierungsmechanismus wird bei dieser Punktzahl nicht berücksichtigt (d.h. Tools wie Geister in den Protokollen)
Bewertung | Logik | Begründung |
1 | destination.ip=“1.1.1.1″ UND destination.port=53 | Dies ist eine IP-basierte Erkennung, IPs können leicht geändert werden. |
2 | eventid=4688 UND commandline enthält „scrobj.dl“ | Dies ist eine Verhaltenserkennung, aber scrobj.dll kann umbenannt werden, um diese Erkennung zu umgehen. |
3 | eventid:5140 UND sharename:Admin$ | Wenn sich jemand mit einem Admin-Share von Microsoft verbindet, ist dieses Protokoll nicht leicht zu umgehen |
_
Benutzerfreundlichkeit (1 – 3, höher ist offensichtlicher)
Der Benutzerfreundlichkeits-Score spiegelt wider, wie „verdaulich“ die Regel ist. Oft ist dies ein direkter Reflex auf die Logquelle selbst. Je mehr Kontext in der ursprünglichen Logquelle verfügbar ist, desto höher wird der Benutzerfreundlichkeits-Score vermutlich sein. Nochmals, dies basiert ausschließlich auf den Alarmdaten. Die Benutzerfreundlichkeit aller Regeln in Ihrer Umgebung kann durch Automatisierung und Orchestrierung erheblich gesteigert werden. Dies wird nicht berücksichtigt.
Bewertung | Logik | Begründung |
1 | destination.ip=“1.1.1.1″ UND destination.port=53 | Je nach Datenquelle könnte dieser Alarm sehr schwer zu triagieren sein. Oft lösen Regeln wie diese auf Hosts aus, die nicht verwaltet werden (Gastnetzwerk, etc.). Außerdem kann DHCP Komplexitäten bei der Identifizierung des betreffenden Hosts einführen. |
2 | eventid:5140 UND sharename:Admin$ | Die Windows-Event-ID 5140 liefert den Benutzernamen und Hostnamen/IP, der auf einen Share zugegriffen hat. Es wird jedoch zusätzliche Suche erforderlich sein, um festzustellen, ob dies das Ergebnis eines Kompromisses ist. |
3 | eventid=4688 UND commandline enthält „scrobj.dl“ | Die Windows-Event-ID 4688 liefert dem Analysten eine Menge unmittelbar nützlicher Kontexte. Es ist wahrscheinlich, dass eine mögliche Bedrohung allein durch das Ansehen dieses Alarms identifiziert werden kann. |
Schweregrad (1 – 3, höher ist ein kritischerer Alarm)
Der Schweregrad ist eine Abstraktion der SIGMA-Level (niedrig, mittel, hoch und kritisch).
Bewertung | SIGMA-Level | Begründung |
1 | Low | Bitte sehen Sie: https://github.com/Neo23x0/sigma/wiki/Rule-Creation-Guide |
2 | Mittel | |
3 | Hoch & Kritisch |
Fazit
Ein passendes Treffer für Inhalte, die Ihren Bedürfnissen entspricht, sollte so einfach wie möglich sein. Durch die Einführung der Metriken SIEM Impact, Pain, Benutzerfreundlichkeit und Schweregrad hofft SOC Prime, Inhalte durch unsere Threat Bounty Program-Entwickler mit den Anforderungen Ihrer Verteidigungsoperation abzugleichen.
Wenn Sie ein internes Detection-Engineering-Team haben, empfehlen wir, dass sie diese Konzepte umsetzen und sie während der Erstellung von Verteidigungsinhalten als Metrik erfassen.
Meta
Veröffentlicht – April 2020
Letzte Aktualisierung – 15. April 2020
Autoren – Adam Swan (@acalarch) | Andrii Bezverkhyi (@andriinb)