Wie kann Cyber ​​Threat Intelligence im Rahmen eines modernen SOC bereitgestellt werden?

Erfahren Sie, wie Sie CTI zur operativen Unterstützung nutzen können (Teil 1)

Grundlagen der Cyber Threat Intelligence:

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:

• Informationssicherheitsmanagement,
• Risikoanalyse,
• Risikoanalyse,
• Incident Response,
• SOC,
• usw.

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.

Der Intelligence Production Cycle:

„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.

Planung & Ausrichtung

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:

• Gemeinsame Definition der Intelligence-Anforderungen mit dem Intelligence-Nutzer,
• Einfache Gestaltung der Intelligence-Anforderungen (nur eine Frage pro Anforderung),
• Festlegung des Formats des endgültigen Intelligence-Produkts,
• Planung aller Schritte des Intelligence Production Cycle, einschließlich der Validierungs- und Feedbackphasen.

Beispiele für Intelligence-Anforderungen könnten sein:

• Für proaktive Sicherheitsmaßnahmen:
  • „Welche Angreifer kommen als Bedrohung für mein Unternehmen in Frage (Bedrohungsmodelle)?“
  • „Welche Indikatoren (IoCs, IoAs…) können verwendet werden, um bestimmte Angreifer in dem zu verteidigenden Perimeter zu erkennen?

• Für Threat Hunting:
  • „Welche Abfragen sollten auf meinen Informationssystemen durchgeführt werden, um bestimmte Angreifer zu erkennen, die versuchen, die Sicherheitsmaßnahmen während der Threat-Hunting-Aktivitäten zu umgehen?“

• Für SOC Security Alert Enrichments:
  • „Welche Anreicherungen kann CTI für die in einem SOC Security Alert enthaltenen Artefakte liefern?“

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.

Sammlung

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 Daten: Daten aus meinen Informationssystemen:
  • System- und Netzwerkprotokolle,
  • SOC-Sicherheitswarnungen, Sicherheitsvorfälle,
  • Telemetrie oder direkte Anfragen (EDR, NDR, SIEM…),
  •  Anwendungsprotokolle,
  • Berichte zu Incident Response,
  • Berichte zur Bedrohungssuche,
  • usw.

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.

• Externe Daten: Daten aus Quellen außerhalb meiner Informationssysteme:
  • Bedrohungsberichte (OSINT, Community, Commercial),
  • Feeds (OSINT, Community, Commercial),
  • Malware Datenbanken (OSINT, Community, Commercial),
  • usw.

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.

Verarbeitung & Verwertung

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.

Analyse & Produktion

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.

Verbreitung

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.

Vorschlag für eine funktionale und technische CTI-Architektur

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

•     Kent Center Occasional Papers: Volume 1, Number 5

https://web.archive.org/web/20201102212401/https://www.cia.gov/library/kent-center-occasional-papers/pdf/OPNo5.pdf

•     Introduction to STIX

https://oasis-open.github.io/cti-documentation/stix/intro

•     OASIS Technical Committees by Name

https://www.oasis-open.org/committees/ 

•     STIX Version 2.1

https://docs.oasis-open.org/cti/stix/v2.1/os/stix-v2.1-os.html

•     TAXII Version 2.1

https://docs.oasis-open.org/cti/taxii/v2.1/os/taxii-v2.1-os.html

•     Traffic Light Protocol (TLP)

https://www.first.org/tlp/

 ———-

[1] https://web.archive.org/web/20201102212401/https://www.cia.gov/library/kent-center-occasional-papers/pdf/OPNo5.pdf

[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

[9] https://www.first.org/tlp/

• Teilen