Cyber Threat Intelligence ist eine Disziplin der Intelligence, die auf den Cyberbereich angewandt wird. Nach Kents Analytischer Doktrin[1] besteht die Aufgabe von (Cyber) Intelligence-Analysten darin, „Informationen und Erkenntnisse für politische Entscheidungs- und Handlungsträger zu liefern„. Im Kontext einer komplexen Einheit, sei es eine Institution oder ein großes Unternehmen, können viele verschiedene Funktionen als politische Entscheidungs- und Handlungsträger fungieren:
All diese Schnittstellen und Erkenntnisse machen Cyber Threat Intelligence zu einer transversalen, aber zentralen Funktion. In diesem Blogpost werden wir uns näher damit befassen, wie CTI ihre Prozesse und Tools anpassen kann, um einem bestimmten Akteur, dem Security Operations Centre (SOC), operative Unterstützung zu bieten. Der zweite Blogbeitrag dieser Reihe wird sich damit befassen, wie CTI eine spezifischere Fähigkeit des SOC unterstützen kann: das Threat Hunting.
Wir könnten die vergangenen Jahre Revue passieren lassen, in denen das SOC neue Technologien (SIEM / UEBA, IDS/IPS, NextGen Firewalls, DLP, EDR, NDR, xDR, SOAR, Cloud-Migration, was auch immer…)[2] und neue Fähigkeiten (Incident Response, CTI, Threat Hunting, Vulnerability / Extended Threat Management… ) integrierte, seine Prozesse verbesserte (Automatisierung, Orchestrierung, maschinelles Lernen, Analyse…) und sich an disruptive Ereignisse wie die COVID-19-Pandemie anpasste (neue Bedrohungen, Remote-Arbeit, virtuelle Zusammenarbeit…). Von alten Strukturen, die hauptsächlich im passiven Erkennungsmodus tätig waren, sind moderne SOCs nun hoch integrierte Cybersecurity Operations Centres, die proaktive Überwachung und reaktive Abhilfe mit vielen automatisierten Prozessen in Kombination mit menschlichem Fachwissen bieten.
In diesem Zusammenhang muss auch die CTI ihre Arbeitsweise an die neuen Intelligence-Anforderungen anpassen und die Architektur ihrer Plattform, der Cyber Threat Intelligence Platform (CTIP), so gestalten, dass das richtige Intelligence-Produkt an den richtigen Handlungsträger oder Entscheidungsträger weitergeleitet wird. In diesem Blogbeitrag werden wir die verschiedenen Schritte des Intelligence Production Cycle durchgehen und versuchen herauszufinden, was antizipiert und berücksichtigt werden muss, um SOC-Intelligence-Lücken zu schließen.
„Traditionelle“ Informationsdienste beschreiben den Prozess der Informationsgewinnung häufig in einem Zyklus, der als „Intelligence Cycle“ oder „Intelligence Production Cycle“ bezeichnet wird. Es gibt zwar Varianten, doch wird er in der Regel als zyklischer Prozess in 5 Schritten mit kontinuierlicher Bewertung und Rückmeldung dargestellt:
Abb. 1: Der Intelligence Production Cycle
Es handelt sich möglicherweise nicht um den aktuellsten und optimiertesten Prozess zur Informationsgewinnung, er kann jedoch als Grundlage verwendet werden und wird zur Veranschaulichung dieses Artikels hilfreich sein.
Diese Prozessphase beschreibt das Management des gesamten Intelligence-Aufwands, von der Ermittlung des Datenbedarfs bis zur Bereitstellung eines relevanten Intelligence-Produkts für einen Nutzer, um eine Wissenslücke zu schließen. Es ist an der Zeit, die handelnden Personen (z. B. SOC-Analysten, Threat Hunter, Incident Responder…), die Entscheidungsträger (CIOs, CISOs, Incident Manager…) und die damit verbundenen Anwendungsfälle zu identifizieren, die Sie mit der Bereitstellung von Intelligence unterstützen werden. Zu den Best Practices gehören:
Beispiele für Intelligence-Anforderungen könnten sein:
Viele verschiedene Intelligence-Anforderungen könnten mit den SOC-Verantwortlichen oder sogar mit den Entscheidungsträgern (z.B. CIO, CISO…) definiert werden. Erste Synergieeffekte könnten sich ergeben. Zum Beispiel könnten verschiedene Entscheidungsträger die gleichen Informationsanforderungen haben, ähnliche Auswirkungen befürchten oder sogar Überschneidungen in ihren Bedrohungsmodellen aufweisen.
Der Schritt der Sammlung ist der Prozess der Beschaffung von Rohdaten aus allen Quellen, die während des Schritts der Planung und Ausrichtung als notwendig zur Erfüllung einer Intelligence-Anforderung identifiziert wurden. Es gibt unendlich viele Quellen, die gesammelt werden können:
Interne Datenquellen sind in einer SOC-Umgebung besonders wertvoll. Jeder gesammelte Informationsblock oder jedes böswillige Verhalten, das an einem Perimeter beobachtet wird, kann wertvolle Informationen liefern und eine globale Erhöhung des Sicherheitsniveaus ermöglichen, indem die Sicherheitslage entsprechend angepasst wird. Der Zugriff auf die relevanten internen Datenquellen sollte für ein CTI-Team Priorität haben, da dies eine genaue Kontextualisierung jeder vom SOC gemeldeten Erkennung ermöglichen würde.
Aus Sicht der CTI-Integration ist es wichtig, alle Quellen auf CTIP-Ebene sammeln zu können, um die Kapitalisierung des gesamten Wissens in einer einzigen Datenbank mit einem kohärenten und einheitlich strukturierten Datenmodell zu ermöglichen. Dies wird durch den nächsten Prozessschritt erreicht.
Der Verarbeitungs- und Verwertungsschritt besteht darin, die Rohdaten in einen nutzbaren Zustand zu synthetisieren. In unserem Fall geht es darum, aus den gesammelten Quellen die Informationen zu extrahieren, die Sie für Ihre Analysen benötigen, und diese in einem konsistenten und strukturierten Datenmodell zu speichern. Da dieser Schritt keinen wirklichen Mehrwert für externe Datenquellen bringt, könnten Automatisierungsbemühungen relevant sein (z. B. Feed-Konnektoren).
Kommerzielles und Open-Source-CTIP verfügt über unterschiedliche strukturierte Datenmodelle. Allerdings könnte es interessant sein, sich für einen Standard in einer Informationssystemumgebung zu entscheiden, die hinsichtlich der Technologielösungen heterogen sein kann. Ausdruck strukturierter Bedrohungsinformationen[3] (STIX™) ist ein Sprach- und Serialisierungsformat, das zum Austausch von CTI verwendet wird. Es handelt sich um einen offenen Standard, der vom OASIS Cyber Threat Intelligence Technical Committee erstellt wurde[4].
Er ist nicht nur für alle CTI-Prozesse relevant, sondern enthält auch einige sehr nützliche Funktionen, die für die operative Unterstützung des SOC genutzt werden können, z. B. das Sighting STIX Relationship Object[5], das angibt, dass etwas gesehen wurde (Indikator, Malware, Kampagne…), oder das Course of Action STIX Domain Object[6], das eine Aktion beschreibt, die entweder zur Verhinderung eines Angriffs oder zur Reaktion auf einen laufenden Angriff ergriffen werden soll. Ein zentrales STIX-Objekt im Kontext eines SOC ist das Indicator STIX Domain Object. Es enthält ein Muster, das zur Erkennung verdächtiger oder bösartiger Cyber-Aktivitäten verwendet werden kann. STIX™ unterstützt verschiedene Muster, um Indikatoren auszudrücken (STIX-Muster, Perl-kompatible reguläre Ausdrücke, Sigma, SNORT, Suricata, YARA) im Rahmen seines offenen Vokabulars für Mustertypen[7], und beschränkt den Benutzer nicht auf diese definierte Liste. Dieses Vokabular kann vom Benutzer durch andere Indicator-Muster ergänzt werden. Die vom STIX™-Standard nativ unterstützten Formate ermöglichen einen reibungslosen Informationsaustausch, während ihre Flexibilität die Integration spezifischerer Anwendungsfälle erlaubt.
Sobald die Informationen erfasst sind, können sie angereichert werden. Bei der Anreicherung geht es darum, Informationen zu Ihren Informationen hinzuzufügen, d. h. Kontext hinzuzufügen, der die Analyse und Entscheidungsfindung unterstützt. Verschiedene Webdienste, ob kommerziell oder nicht, können verwendet werden, um Kontext hinzuzufügen (WHOIS-Abfrage, Geolokalisierung, Reputation…). Es können auch Untersuchungen und Pivots durchgeführt werden, um neue verwandte Informationen zu entdecken. Auch hier können Webdienste zur Unterstützung herangezogen werden (DNS / pDNS-Datensätze, Hash-Algorithmen für Portable Executables, Code-Signatur-Zertifikate, SSL-Zertifikate, Malware-Datenbanken, usw.). Da Enrichments und Pivots als Dienste für andere Funktionen als CTI bereitgestellt werden können, könnte es interessant sein, diese Fähigkeiten auf SOAR-Ebene verfügbar zu halten und sie über entsprechende Playbooks aufzurufen.
Die Analyse und Produktion von Informationen ist die Umwandlung der von Ihnen gesammelten und verarbeiteten Informationen in Intelligence. Dazu gehören die Analyse und Bewertung aller verfügbaren Daten sowie die Vorbereitung der endgültigen Intelligence-Produkte, von getrennt verbreiteten Informationen (z. B. IoCs) bis hin zu endgültigen Berichten, in denen einzelne Informationen zusammengeführt werden, um Muster zu erkennen und Schlussfolgerungen zu ziehen. Es ist an der Zeit, Ihre strukturierten Analysetechniken einzusetzen, um kognitive Verzerrungen und logische Irrtümer abzuschwächen und die Zuverlässigkeit, Gültigkeit, Aktualität und Relevanz der erstellten Informationen zu bewerten, was auch eine Bewertung und Beurteilung der Auswirkungen auf die Handlungsträger und Entscheidungsträger beinhalten muss.
Was die technischen Hilfsmittel betrifft, so könnten einige Fähigkeiten nützlich sein, um angemessene taktische und operative Intelligence bereitzustellen. Ein Beispiel dafür ist eine Malware-Sandbox, mit der das Verhalten von Malware in einer kontrollierten Umgebung sicher beobachtet werden kann. Einige Malware-Sandboxen verfügen über zusätzliche Analysefunktionen, die auf Antiviren-Erkennung oder statischer Analyse basieren. Eine solche Technologie könnte es uns ermöglichen, Malware-IoCs schnell zu extrahieren und einige Hinweise auf die von der Malware in der Opferumgebung durchgeführten Aktionen zu geben, so dass wir einige relevante Threat-Hunting-Anfragen zur Überprüfung der überwachten Informationssysteme auf Infektionen stellen können.
Da diese Fähigkeiten auch als Dienste für andere Funktionen als CTI zur Verfügung gestellt werden könnten, ist es denkbar, sie auf SOAR-Ebene verfügbar zu halten und sie über entsprechende Playbooks aufzurufen.
Nun, da die Cyber-Bedrohungsdaten im richtigen Format vorliegen, müssen sie an die richtigen Entscheidungsträger weitergeleitet werden, um deren Wissenslücken zu schließen. Auch hier ist es in einer heterogenen Informationssystemumgebung oft die richtige Wahl, auf einen Standard zu setzen. Parallel zu STIX spezifiziert das OASIS Cyber Threat Intelligence Technical Committee das Trusted Automated Exchange of Intelligence Information (TAXII™)[8], ein Anwendungsprotokoll für den Austausch von CTI über HTTPS. TAXII™ definiert eine RESTful API und eine Reihe von Anforderungen für TAXII-Clients und -Server.
Andererseits definiert TAXII keine Vertrauensvereinbarung, keine Governance und keine anderen nicht-technischen Aspekte der kollaborativen Arbeit. Die Definition dieser Elemente ist wichtig, um die Grenzen der gemeinsamen Nutzung von potenziell sensiblen Informationen zu verwalten. Das Ampelprotokoll (TLP)[9] wird in diesem Zusammenhang des Informationsaustauschs üblicherweise verwendet.
Die eigentliche Verbreitung kann entsprechend den Vorgaben erfolgen, die in der Planungs- und Anforderungsphase mit den Verantwortlichen und Entscheidungsträgern festgelegt wurden, und zwar durch ein spezielles und angemessenes Playbook auf SOAR-Ebene. Dadurch wird sichergestellt, dass die Sicherheitslösungen automatisch die Informationen erhalten, die sie verarbeiten können, und dass die beteiligten Personen die erwarteten Informationen im geeigneten Format erhalten. CTIPs integrieren in der Regel ein Tagging-System, das von den Playbooks genutzt werden kann, um eine angemessene Weitergabe sicherzustellen.
Um den Inhalt dieses Blogposts zusammenzufassen, folgt hier ein Vorschlag für eine CTIP-Architektur im Kontext eines modernen SOC, einschließlich der CTI-Prozessschritte des Intelligence Production Cycle:
Abb. 2: Vorschlag für eine CTIP-Architektur
In der nächsten Folge dieser Blogserie werden wir erörtern, wie CTI das Threat Hunting unterstützen kann, einschließlich der Anforderungen, Prozesse und Tools.
Literaturverzeichnis
https://oasis-open.github.io/cti-documentation/stix/intro
https://www.oasis-open.org/committees/
https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html
https://docs.oasis-open.org/cti/taxii/v2.1/os/taxii-v2.1-os.html
———-
[2] Cybersecurity jargon busting: MDR, SOC, EDR, XDR, SOAR and SIEM
[3] https://oasis-open.github.io/cti-documentation/stix/intro
[4] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cti#overview
[5] https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html#_a795guqsap3r
[6] https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html#_a925mpw39txn
[7] https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html#_9lfdvxnyofxw
[8] https://docs.oasis-open.org/cti/taxii/v2.1/os/taxii-v2.1-os.html
Cybersecurity Im Jahr 2023 ist es Airbus Protect gelungen, beispiellose Erfolge im Bereich Cyberabwehr zu erzielen und damit einen wichtigen Meilenstein für das Unternehmen zu setzen.
Mehr erfahren
Cybersecurity Im ersten Teil dieser Blogserie mit Schwerpunkt CTI haben wir den Intelligence Production Cycle vorgestellt und eine funktionale und technische Architektur für eine Cyber-Threat-Intelligence-Plattform vorgeschlagen, die sowohl in die SOC- als auch in die Incident-Response-Aktivitäten integriert ist und diese unterstützt.
Mehr erfahren
Cybersecurity Heute haben wir Felix, Penetrationstester, und Philipp, Cyber Security Incident Responder, gebeten, über ihren Job und ihr tägliches Miteinander zu sprechen.
Mehr erfahren