Ist OCSF der Schlüssel zur Demokratisierung von Sicherheits-Data-Lakes?

Die Aufnahme und Analyse von Sicherheitsdaten kostet viel Zeit und Ressourcen. Das soll sich durch das Open Cybersecurity Schema Framework (OCSF) ändern. Das Salesforce DnR-Team hat das OCSF getestet. In diesem Artikel erfahren Sie die Ergebnisse.
Ist OCSF der Schlüssel zur Demokratisierung von Sicherheits-Data-Lakes?

Die Erkennung und Abwehr von Cyberangriffen beruhen auf der Zusammenarbeit vieler verschiedener Sicherheitstools. Bevor allerdings die Daten der Sicherheitsprotokolle analysiert werden können, um mögliche Angriffe aufzuspüren, müssen sie zusammengeführt werden. Dies ist mit einem hohen Zeit- und Ressourcenaufwand verbunden, der oft einfach akzeptiert wird. Das Projekt "Open Cybersecurity Schema Framework" (OSCF) soll dies ändern, damit Teams weniger Zeit mit der Analyse und mehr Zeit mit dem Schutz ihrer Umgebungen verbringen können. Im Folgenden erfahren Sie, warum dieser neue Ansatz so wichtig und zeitgemäß ist.

Damit die Event-Daten eines Sicherheitsprotokolls nützlich sind, muss jedes Protokoll über ein Schema verfügen, das oben im Protokoll die Felder definiert, die für die Suche, Aggregation oder Erkennung verfügbar sind. Ein Netzwerkverbindungsprotokoll kann beispielsweise die Quell-IP enthalten, die die Verbindung angefordert hat, und die Ziel-IP, die die Anforderung erhalten und darauf geantwortet hat. Ein solches Schema würde Felder wie src und dest enthalten, damit Sicherheitsanalysten wissen, dass sie Abfragen zu diesen Feldern ausführen können.

Allerdings gibt es wenig Übereinstimmung zwischen den Protokolltypen oder Tools für diese Schemas. In CrowdStrike-Netzwerkprotokollen wird für die Quell-IP beispielsweise ip und für die Ziel-IP RemoteAddressIP4 extrahiert. In PAN Firewall-Protokollen wird die Quell-IP dagegen als src und die Ziel-IP als dst bezeichnet. Einige Protokolle sind völlig unstrukturiert. Sie müssen das Protokollformat verstehen und wissen, wo innerhalb eines Protokoll-Events sich die IP befindet, um die Quell- und Ziel-IPs zu ermitteln. 

Oft möchten Analysten Abfragen über große Untergruppen von Protokollen ausführen. Das ist nötig, wenn sie beispielsweise wissen möchten, ob ein Host jemals mit einer bestimmten IP-Adresse verbunden war. Dazu muss nicht nur jeder Protokolltyp ein Schema aufweisen, die Schemas müssen auch übereinstimmen. Gäbe es nur eine Möglichkeit, Daten mit weniger manuellem Aufwand aufzunehmen und zu analysieren!

Die Herausforderungen der Protokollnormalisierung

Bisher ist Salesforce dies mit einer komplexen internen Lösung namens "Events Data Dictionary" (DDI) angegangen. Dieses Wörterbuch enthält jedes einzelne Feld in jedem einzelnen Protokoll. Es wurden Regeln für die Extraktion von Datenfeldern (DFEs) definiert, um die Protokolle zu analysieren und das Wörterbuch als Schema durchzusetzen. In der Erkennungs- und Reaktionsarchitektur erfolgt dieser Vorgang in einem System namens "Normalizer". 

Nach der Normalisierung weisen alle Protokolle, auch die zuvor unstrukturierten, übereinstimmende Schemas und eine Reihe von Feldern auf, die abgefragt werden können. "RemoteAddressIP4" in CrowdStrike-Protokollen wird extrahiert und in "IPDestination" umbenannt. Ähnlich wird "dst" in PAN-Protokollen in "IPDestination" umgewandelt. Dann müssen Analysten, die feststellen möchten, ob eine Verbindung mit einer bestimmten IP hergestellt wurde, einfach nur noch eine Abfrage wie "IPDestination == [...]" über alle Protokolle hinweg ausführen.

Im Idealfall funktioniert das hervorragend. Analysten können so problemlos suchen. Aber die Protokollnormalisierung ist mit eigenen Herausforderungen verbunden:

  1. Es gibt Hunderte von Feldern im Datenwörterbuch, von denen viele NULL entsprechen, wodurch viel Platz vergeudet wird.
  2. Bei einem neuen Protokolltyp stimmen die Felder möglicherweise nicht mit dem überein, was zuvor definiert wurde. Dies kann zu seltsamen Ergebnissen führen. (Beispielsweise können "user", "username", "useremail" je nach Protokolltyp unterschiedliche Bedeutungen aufweisen.)
  3. Beim Onboarding einer neuen Protokollquelle muss jeder Protokolltyp und jeder Protokolluntertyp manuell analysiert werden. Dann müssen Regex- oder Analyseregeln geschrieben werden.
  4. Alle Änderungen an der Protokollstruktur, das Hinzufügen oder das Ersetzen von Feldern können dazu führen, dass die Felder bei der Analyse mit den vorhandenen Regeln übersehen werden. Dies stellt ein schwerwiegendes Problem der Datenqualität dar.
  5. Außerdem gibt es keine gute Methode zur Validierung oder zur Verfolgung der Regeln in großem Maßstab. Wahrscheinlich sind einige Regeln doppelt vorhanden. Es ist schwierig, den Regelsatz zu pflegen oder zu aktualisieren, da die Veraltung von Regeln mit einem erheblichen Risiko verbunden ist. Wenn neue Regeln alte Regelfunktionen überschreiben, kann es zu Regressionen kommen.

All diese Arbeit verursacht immer höhere Kosten. Teams verbringen viel Zeit damit, Daten manuell zu normalisieren, um die Voraussetzungen für die Analyse zu schaffen, statt sich darauf zu konzentrieren, Events zu erkennen und darauf zu reagieren.

Übernahme des OCSF

Das Open Cybersecurity Schema Framework (OCSF), das als offener Schema-Standard auf der Informationssicherheitskonferenz BlackHat im August '22 öffentlich angekündigt wurde, ist ein einzigartiges Projekt und ein wichtiger Versuch, Daten aus verschiedenen Cybersicherheitsquellen zu standardisieren. Mit diesem Framework soll eine vereinfachte und anbieterunabhängige Taxonomie bereitgestellt werden, die allen Sicherheitsteams eine bessere und schnellere Datenaufnahme und -analyse ermöglicht, ohne vorher viel Zeit für die Normalisierung aufwenden zu müssen. 

Das Ziel besteht darin, einen offenen Standard zu schaffen, der in jeder Umgebung, jeder Anwendung und für jeden Lösungsanbieter eingesetzt werden kann und zu den bestehenden Sicherheitsstandards und -prozessen passt. OCSF ist ein Open-Source-Framework, das dem bei Salesforce eingesetzten Datenwörterbuch in gewisser Weise ähnlich ist, denn es zielt darauf ab, die oben beschriebenen anfänglichen Herausforderungen zu bewältigen. Es versucht jedoch auch, die Probleme zu beheben, die sich aus dem Salesforce-Ansatz ergeben, indem es eine Untergruppe von Feldern festlegt, die auf der Grundlage der Verwendung durch Analysten schematisiert werden.

Vikram Rao, Chief Trust Officer bei Salesforce, meint dazu: "Die schnelle Digitalisierung ist heute ein Muss für jedes Unternehmen. Die Entwicklung eines Sicherheitsverhaltens für digitales Vertrauen im Internet kann jedoch eine große Herausforderung darstellen. Neue Standards wie OCSF reduzieren die Komplexität für Sicherheitsteams und ermöglichen es ihnen, sich auf wichtigere Aufgaben wie die Analyse von Bedrohungen und die Abwehr von Angriffen zu konzentrieren."

Der Testlauf

Das Salesforce Detection and Response Engineering Team untersuchte das OCSF gründlich. Sowohl die Durchsetzung dieses Schemas für die von Salesforce generierten Protokolle als auch die Anpassung unseres derzeitigen Normalisierungsansatzes, um Protokolle mit den von OCSF definierten Schemas auszugeben statt mit den benutzerdefinierten Schemas aus dem Events Data Dictionary, spielten dabei eine Rolle.

Zum besseren Verständnis von OCSF wurde zunächst ein Test ausgeführt, um die Erkennung eines hypothetischen Sicherheitsevents bei Salesforce in das OCSF-Format umzuwandeln und auszuwerten. Die folgenden Screenshots zeigen das Event in unserem aktuellen DDI-Format gegenüber dem OCSF-Format. 

image
Salesforce-Sicherheitsevent – DDI-Schematisierung
image
Salesforce-Sicherheitsevent – OCSF-Schematisierung

Bei diesem Test und der Erkundung des OCSF-Schemas hat das Salesforce-Team einige interessante Felder entdeckt, die sich als nützlich erweisen können. Ein Beispiel ist das Remediation-Objekt. Mit diesem Feld können Knowledge Base-Artikel und Beschreibungen verknüpft werden, die Analysten anschließend bei der Vorauswahl von Vorfällen helfen, damit weitere Maßnahmen ergriffen werden können.

Interne Salesforce-Teams machten sich an die Arbeit, erstellten erste Prototypen und untersuchten die Umwandlung der internen Salesforce-Anwendungsprotokolle (sfdc_applog) als Grundlage für OCSF-konforme Protokolle. Die Zusammenarbeit soll auch in Zukunft fortgesetzt werden. Wenn Sie mitarbeiten und dieses Schema verwenden möchten, um Ihre Protokolle zu standardisieren, finden Sie weitere Informationen auf dem OCSF GitHub [hier].

Eine Runde Applaus!

Dem Projekt Open Cybersecurity Schema Framework, das die Klassifizierung von Daten in einem anbieterneutralen Framework vereinfachen soll, damit Sicherheitsteams weniger Zeit mit der Normalisierung von Daten und mehr Zeit mit der Erkennung und Abwehr von Angriffen verbringen können, gebührt ein kräftiger Applaus. Das OCSF basiert auf Beiträgen von Cloudflare, CrowdStrike, DTEX, IBM Security, IronNet, JupiterOne, Okta, Palo Alto Networks, Rapid7, Salesforce, Securonix, Sumo Logic, Tanium, Trend Micro und Zscaler.

Wir bei Salesforce sind begeistert und haben OCSF schon früh übernommen. Die anfänglichen Tests zur Umwandlung unserer wichtigsten Protokolltyp-Events in OCSF waren ein wichtiger erster Schritt und haben dazu beigetragen, dass verschiedene interne Teams das Framework kennengelernt haben und wissen, wo es sich befindet. Da es sich bei OCSF um einen offenen Standard handelt, der auf der Zusammenarbeit der gesamten Sicherheitsbranche beruht und von zahlreichen Interessengruppen übernommen und weiterentwickelt wird, hat dieser Standard das Potenzial, Sicherheits-Data-Lakes in allen Organisationen zu demokratisieren.

Damit OCSF die größte Wirkung erzielt, müssen Cloud-und Sicherheitsanbieter Anpassungen vornehmen und Protokolle im OCSF-Schema bereitstellen. Wenn Sie in diesem Bereich tätig sind, helfen Sie mit, Grenzen zu überwinden, damit OCSF zu einem Standard in der gesamten Sicherheitsbranche wird!



Empfohlene Artikel