Kontinuierliche Compliance als Code P1: Sigma

Compliance war schon immer eine Art reaktiver Prozess, da Standards lang sind, enormen Aufwand erfordern und eine Weile brauchen, um aktualisiert zu werden, noch mehr Zeit zur Umsetzung benötigen und der Prüfprozess einmal im Jahr stattfindet. Aus der SIEM-Welt kommend, befasste ich mich mit Compliance durch ein Prisma von vorgefertigten Berichten, die in der Regel leere Ergebnisse liefern oder etwas, das weit davon entfernt ist, einem externen Prüfer erklärbar zu sein. Auf der anderen Seite ist die zugrunde liegende Logik der Berichte und Abfragen undurchsichtig und erfordert enormen Aufwand für die Wartung, um es gelinde auszudrücken. Um es zum Laufen zu bringen, muss man die Korrelationsregel-Engine oder Abfragesprache spezifischer SIEM-Technologie und die dazugehörige Berichtsmotorik meistern, Unmengen an Listen und Ausnahmen statisch konfigurieren, während die eigentliche Umgebung dynamisch ist und die Zusammenführung aller Daten an einem Ort viele Monate dauern kann. Und bis wir mit diesen Aufgaben fertig sind, wird die SIEM-Technologie geändert oder ich arbeite mit einem anderen Kunden, der ein auf Suchanalyse basierendes Sicherheitssystem anstelle eines „klassischen Echtzeit-Korrelationssystems“ verwendet. Es wird einfacher, wenn wir Sicherheitstools wie VM-Scanner haben, die Compliance-Prüfungsfunktionen besitzen, z. B. Qualys Policy Compliance, Tripwire und ähnliche. Diese Tools bauen jedoch kein ganzheitliches Bild auf, geschweige denn ein Echtzeitbild, es sei denn, sie sind mit einem SIEM- oder Sicherheitsanalyse-Plattform einiger Art verbunden. Dann kommt der GRC-Zug mit massiven Produkten und Mann-Jahren an Beratungsaufwand daher. Langweilig. Kostenineffizient. Garantierte Lücken in der Sichtbarkeit. Zu langsam für das digitale Zeitalter, in dem wir leben. Und wie gut ist all das oben Genannte, um den NIST CSF oder die GDPR anzugehen? Meiner bescheidenen Meinung nach ist Compliance ein Spiegelbild der Sicherheit, also wenn Sie Cybersecurity richtig machen, folgt die Compliance. Dies funktioniert jedoch nicht umgekehrt. Zeit für eine Änderung? Ja. Und heute beginnen wir mit einer Serie von Artikeln, um Ihre Compliance zu einem agilen, transparenten und kosteneffizienten Prozess der modernen digitalen Wirtschaft zu machen.

Evolution der Sigma-Regeln und Verbindung zur Compliance

Ich betrachte die beschleunigte Übernahme der Sigma-Regeln für SIEM, SOC und Threat Hunting Aufgaben als eine der positivsten Veränderungen in der Sicherheitsbranche. Und während Sigma bereits ein De-facto-Standard für Threat Hunting-Abfragen ist, hatten wir die verrückte Idee, ihn anzuwenden, um Praktiken der kontinuierlichen Compliance zu etablieren. Falls Sie noch nichts von Sigma gehört haben: Es ist eine leicht verständliche, schnell erlernbare, plattformunabhängige und quelloffene Sprache. Beispiele für die Regeln und Quellcode https://github.com/Neo23x0/sigma und Tutorial, um zu beginnen https://www.nextron-systems.com/2018/02/10/write-sigma-rules/Wenn Sie Elastic Stack, Splunk, ArcSight, QRadar, Qualys, Microsoft Windows Defender ATP, Logpoint, Greylog haben: Sie können bereits jetzt Wert aus Sigma-Regeln für Sicherheit und Jagd ziehen. Diese Plattformen sind wahrscheinlich Teil Ihrer Infosec / SOC und haben Unmengen an Daten, die für die Compliance verwendet werden können. Und es ist noch wahrscheinlicher, dass Sie einen Elastic Stack, eine Premium- oder Community-Version haben, die in verschiedenen Geschäftseinheiten Ihrer Organisation verwendet wird und Daten für automatisierte Compliance-Kontrollen haben kann. Einer der wichtigen Gründe für die Evolution und globale Akzeptanz von Sigma ist seine nativen Unterstützung von MITRE ATT&CK https://attack.mitre.org. Falls Sie diesen Artikel lesen und nicht aus dem Infosec-Bereich kommen: MITRE ATT&CK ist die Blockchain der Cybersicherheit oder das Periodensystem der Elemente der Chemie. Wir haben also einen weit verbreiteten Open-Source-Standard, der leichter zu lernen ist als jede Abfragesprache eines SIEM und der das Tagging mit der ATT&CK-Methodik unterstützt, um TTP-Attributionen im Handumdrehen durchzuführen. Was wäre, wenn wir Tags hinzufügen würden, die für Compliance-Standards relevant sind? Eine Abfrage für automatische Kontrolle gemäß CSC 8.2 oder Systeme zu finden, die personenbezogene Daten für die GDPR verarbeiten? Für Sigma ist dies nur ein weiteres Tag, technisch also der logische nächste Schritt in der Entwicklung.

Wie man Sigma-Regeln für die Compliance schreibt

Es ist kein Geheimnis, dass ich persönlich ein großer Unterstützer von Sigma bin, aber zu diesem Zeitpunkt selbst nicht viele Regeln schreibe. Für detaillierte HOWTO-Anleitungen habe ich Alex Yamposlkyi zu einem kurzen Gespräch erwischt. Alex, einer der sehr aktiven Entwickler von Sigma-Regeln, hat in Bezug auf die Anzahl entwickelter Regeln nur Florian Roth voraus, und er hat einige sehr praktische Einblicke gegeben.

AB: „Alex, hast du bereits Sigma-Regeln für die Compliance entwickelt?“
AY: „Ja, es waren ein paar geschäftige Monate. Einige Beispiele finden Sie im offiziellen Sigma-GitHub-Repo: https://github.com/Neo23x0/sigma/tree/master/rules/compliance und im SOC Prime Threat Detection Marketplace: https://tdm.socprime.com/?sigmaTypes[]=Compliance “

AB: „Großartig. Gibt es irgendeinen bestimmten Algorithmus, dem du folgst, wenn du Compliance-Sigma-Regeln erstellst?“
AY: „Ich glaube, ich kann dies als einen 5-Schritte-Prozess beschreiben:

1. Lernen Sie den initialen CIS-Kontrollpunkt unter https://www.cisecurity.org/controls/cis-controls-list/
2. Verstehen Sie, welche der Logquellen in Ihrer Organisation verwendet werden können, um die Anforderungen der spezifischen Kontrolle zu erfüllen.
3. Durchsuchen Sie Ihre SIEM-Plattform nach den benötigten Ereignissen.
4. Sobald ordnungsgemäße Ereignisse entdeckt wurden, entscheiden Sie über die Logik der Regeln: Ein Logeintrag entspricht einem Ereignis, das gut oder schlecht für die Compliance ist. Stellen Sie sich die Frage: Besteht oder scheitert dieser Logeintrag an der Kontrolle?
5. Kodieren Sie das resultierende Ereignis in eine Sigma-Regel und entfernen Sie alle plattform-spezifischen Suchparameter, um es SIEM-neutral zu halten. Fügen Sie Tags aus Punkt #1 hinzu und planen Sie die automatisierte Suche.”

AB: „Das klingt nach einem schnellen Erfolg. Können wir dies auf eine Schritt-für-Schritt-Anleitung ausdehnen?“
AY: „Ja. Hier eine kurze Notiz.

1. Wählen Sie die spezifische Domäne für die Kontrolle aus, die Sie erstellen, zum Beispiel „Malware-Abwehr“, die der CSC-Domäne #8 entspricht.
2. Verstehen Sie die Beschreibung dieser Kontrolle tiefergehend, in unserem Fall liest sich 8.2 wie „Stellen Sie sicher, dass die Anti-Malware-Software der Organisation ihre Scan-Engine und Signatur-Datenbank regelmäßig aktualisiert.“
3. Überlegen Sie, was im System passieren muss, um diese Kontrolle zu bestehen oder nicht. Für 8.2 bedeutet dies, dass wenn der AV-Dienst gestoppt wird oder ein Fehler bei seinem Update auftritt, wir die Kontrolle nicht bestehen. Daher müssen wir das AV-Ereignisprotokoll verfolgen, speziell für Dienststopp- und Update-Fehlerereignisse.
4. Es ist ziemlich einfach, diese spezielle Kontrolle zu verfolgen, wir müssen ein AV-Produkt installieren. In meinem Fall war dies ein Symantec-Produkt, das mit dem Elastic Stack unter Verwendung von Logstash integriert wurde. Nachdem ich eine Weile die Logs sortiert hatte, fand ich das Ereignis, das für das Herunterladen und Deployment der Updates verantwortlich ist und die folgenden Zeichenfolgen enthält: „Neue Inhalte heruntergeladen“, „Ein Update für“.
5. Durch Überprüfen, welche Felder diese Schlüsselwörter enthalten, kann ich eine einfache Elastic-Abfrage erstellen: (event.name:(„Downloaded new content“)) ODER (event.name:(„An update for“))
6. Jetzt entscheiden wir über die Logik der Regel: Ist das Ereignis gut oder schlecht. In unserem Fall ist das Vorhandensein des Logeintrags positiv und bedeutet, dass die Kontrolle bestanden wurde. Um den Prozess zu automatisieren, kodieren wir die Sigma-Regel und wenden sie auf den plattform-spezifischen gespeicherten Suchmechanismus an. In meinem Fall plane ich einen Watcher auf dem Elastic Stack, der in einem bestimmten Zeitintervall meiner Umgebung ausgeführt wird.
7. Schreiben wir eine Sigma-Regel
8. In diesem Beispiel kann ich entscheiden, einen Alarm einzuplanen, wenn Ereignisse für einen bestimmten Zeitraum fehlen. Bei anderen Beispielen kann die Situation das Gegenteil sein und wir benötigen einen Alarm, wenn wir ein Ereignis entdecken.
9. Jetzt benötigt unsere Regel alle relevanten Tags, also werde ich sie in diesem Format hinzufügenTags:
   – CSC8.2
   – attack.impact
   – attack.t1489

Wir können tatsächlich Tags für ATT&CK und Compliance mischen. In einem obigen Beispiel ist „CSC8.2“ die entsprechende Kontrollnummer pro CSC-Domäne; „attack.persistence“ ist eine MITRE ATT&CK-Taktik und „attack.t1053“ ist eine spezifische Technik, auf die die Kontrolle abzielt.

Ein aktualisierter Sigma-Code wird so aussehenSobald ich die Regeln auf dem Threat Detection Marketplace veröffentliche, werden auch Meta-Daten für die Regeln generiert, indem ich auf die Schaltfläche „Parse Sigma Content Tags“ drücke.In der „Tags“-Liste kann ich die Regeln mit beliebigen Compliance-Standards wie ISO, PCI, NIST CSF usw. verknüpfen.

Unser Gespräch ging noch eine Stunde weiter mit ausreichend Material für ein Interview über das SOC Prime Threat Bounty Programm. Bis dahin ist jedes Feedback zu Sigma für Compliance sehr willkommen.
Und wenn Sie einen Einblick erhalten möchten, wie das Endergebnis auf dem Elastic Stack aussieht, schauen Sie sich das Video an bei https://my.socprime.com/en/continuous-compliance

/Bleiben Sie sicher