Kestrel wurde entwickelt, um die Arbeit von SOC-Analysten zu erleichtern, und findet immer mehr Anhänger

  • Die IBM X-Force Command Cyber Range (im Bild) in Cambridge, Massachusetts. Eine neue, von IBM entwickelte Open-Source-Sprache für die Bedrohungsjagd soll dazu beitragen, die Arbeitsbelastung von Security Operations Center zu verringern. (IBM)

    Eine neue Open-Source-Sprache für die Bedrohungsjagd, die durch Automatisierung und einen plattformunabhängigen Ansatz die Analysten in den Security Operations Centern entlasten soll, ist jetzt für die gesamte Cyber-Community verfügbar.

    Die von Programmierern bei IBM Research und IBM Security entwickelte Sprache, Kestrel, wurde soeben offiziell für die Nutzung durch Mitglieder der Open Cybersecurity Alliance freigegeben. Die OCA ist ein “offenes Projekt”, das Ende 2019 von der technischen Standardisierungsorganisation OASIS mit dem Ziel ins Leben gerufen wurde, den Mangel an Integration zwischen Cyber-Lösungen zu beheben und die Interoperabilität in der Sicherheitsindustrie zu fördern.

    Laut einer OCA-Ankündigung des IBM-Beitrags war die Bedrohungsjagd in der Vergangenheit mit einem siloartigen, manuellen Ansatz zur Erkennung verbunden, der technische Fähigkeiten und Kenntnisse erfordert, die bei angehenden SOC-Mitarbeitern nur schwer zu finden sein können.

    “Anstatt vom kollektiven Wissen der Threat Hunting Community zu profitieren und Code zu teilen, arbeiten Threat Hunters oft isoliert und schreiben nach jedem Angriff dieselben Programme neu”, heißt es in der Mitteilung. Kestrel ermöglicht es den Bedrohungsjägern jedoch, “die Suche in einer offenen, zusammensetzbaren Sprache auszudrücken”, was eine bessere Zusammenarbeit in der Zukunft ermöglicht. Die Sprache nutzt auch die Automatisierung, “um langwierige Jagdaufgaben auszuführen, so dass sich die Bedrohungsjäger auf Aufgaben mit höherer Priorität konzentrieren können”, während sie bewährte Verfahren bei Bedarf effizient wiederverwenden.

    Dee Schur, Senior Manager, Development and Advocacy, betonte in einem Interview mit SC Media, dass der Open-Source-Charakter des Projekts ein wesentlicher Vorteil ist. “Manchmal kann die Entwicklung von Standards wie ein paralleles Spiel sein”, sagte Schur und bezog sich dabei auf das Konzept von Kindern, die nebeneinander spielen und beobachten, aber nicht interagieren.

    Aber “wenn man anfängt, über Open Source zu sprechen, spricht man wirklich über eine viel interaktivere und intuitivere Art von Spiel”, was letztendlich zu einer universelleren Lösung führen kann, die das Potenzial hat, von einem de jure Gremium akzeptiert zu werden.

    “Die Zukunft der Cybersecurity-Automatisierung liegt in der Augmentation von Analysten und der Interoperabilität von Plattformen. Kestrel verkörpert diese beiden Eigenschaften und ermöglicht es SOC-Analysten, Bedrohungen in großem Umfang mit einer standardisierten Sprache zu jagen”, sagte Vaughan Shanks, CEO von Cydarm Technologies, das zusammen mit IBM Mitglied des OCA-Vorstands ist. Zu den weiteren Mitgliedern der OCA, die Ende 2019 gegründet wurde, gehören das Center for Internet Security (CIS), Cybereason, CyberNB, Cydarm, Cyware, EclecticIQ, EPRI, F5, IBM Security, McAfee, NewContext, Rapid7, S-Fractal Consulting, SafeBreach, SAIC, Tenable, ThreatQuotient, Tripwire und TruSTAR.

    SC Media sprach diese Woche mit Jason Keirstead, Distinguished Engineer und Chief Technology Officer von IBM Security Threat Management, um tiefer in die Frage einzutauchen, was Kestrel als Bedrohungsjagdsprache auszeichnet und welchen Wert er sich davon für die Sicherheitsgemeinschaft verspricht.

    Lassen Sie uns mit einem kleinen Hintergrund über die OCA und ihre jüngsten Bemühungen als Organisation beginnen.

    [Blocked Image: https://www.scmagazine.com/wp-content/uploads/2021/07/Jason-Keirstead-headshot.jpg]Jason Keirstead, IBM

    Die Mission der Organisation ist es, die Interoperabilität in der Cybersicherheitsbranche durch den Einsatz von Open Source zu erhöhen – und dies zu nutzen, um die Einführung von offenen Standards zu beschleunigen. Was zur Gründung dieser Organisation führte, war die Identifizierung eines Problembereichs über eine Reihe von Jahren hinweg… und das ist, dass die Mehrheit unserer Kunden [and our industry partners’ clients] eine sehr große Anzahl von Cybersicherheits-Tools haben. Diese Tools sind wichtig, arbeiten aber nicht nahtlos zusammen.

    In der Regel müssen unsere Kunden viel Zeit, Geld und Energie aufwenden, damit ihre Tools miteinander kommunizieren können… Erstens ist das eine Investition, die sie für die eigentliche Erkennung von Bedrohungen verwenden könnten, und stattdessen geben sie sie für die Pflege der Integration zwischen ihren Tools aus. Zweitens, weil die Tools schlecht integriert sind, besteht die Möglichkeit, dass sie Bedrohungen übersehen, weil sie keinen vollständigen Einblick in ihr Unternehmen haben, da die Informationen nicht nahtlos von Tool zu Tool fließen, so dass der Kontext verloren geht. Dinge fallen durch die Maschen.

    Was wir mit OCA versuchen, ist, Stakeholder zusammenzubringen, um diese Herausforderung frontal anzugehen. Denn wir haben festgestellt, dass Standards allein keine vollständige Interoperabilität gewährleisten… und dass Open-Source-Tools, -Bibliotheken und -Code, die diese Standards implementieren und die von den Produkten sofort verwendet werden können, die Akzeptanz dieser Standards erheblich beschleunigen können.

    Das ist der Grund, warum wir diese Organisation als offenes OASIS-Projekt gegründet haben. Offene OASIS-Projekte konzentrieren sich auf diesen Nexus von Standards und Quellcode, bei dem man ein Open-Source-Quellprojekt oder Codestücke erstellen kann, und diesen Code dann später zur Erstellung des Standards verwenden kann. Die Idee ist “Code vor Papier”, und das ist genau das, was wir in der OCA versuchen zu tun. Wir konzentrieren uns darauf, funktionierende Lösungen auf den Markt zu bringen. Und wenn sich diese Lösungen dann zu Standards entwickeln, ist das spektakulär.

    Erläutern Sie das Konzept hinter der Kestrel-Sprache zur Bedrohungsjagd und den Wert, den sie einbringt.

    Kestrel wird bei IBM nun schon seit fast zwei Jahren entwickelt. Die Ursprünge des Projekts begannen mit einigen unserer IBM-Forschungskollegen, die sich mit [the Defense Advanced Research Projects Agency]. Es handelt sich um eine speziell entwickelte Sprache, die von Threat Hunters verwendet werden kann, um plattformunabhängig nach Bedrohungen zu suchen. Die Herausforderung für Bedrohungsjäger besteht darin, dass all die verschiedenen Tools, die sie bei ihrer täglichen Arbeit verwenden, unterschiedliche APIs und Sprachen sprechen. Wenn Sie also eine Suche mit Crowdstrike erstellen wollen, müssen Sie eine Sprache lernen, und wenn Sie dieselbe Suche in Carbon Black ausführen wollen, ist das eine andere Sprache. Wenn Sie dieselbe Jagd auf Microsoft Sentinel oder Microsoft ATP ausführen wollen, ist das eine andere Sprache und API.

    Und all diese Sprachen sind extrem esoterisch. Ein Experte für all diese verschiedenen Dinge zu werden und mit ihnen Schritt zu halten, ist also eine riesige Lernkurve. Die meisten Analysten sind nur in der Lage, sich auf eine zu spezialisieren, um ehrlich zu sein. Das hat zur Folge, dass sich Bedrohungsjäger, anstatt sich auf das Bedrohungsmanagement und die Bedrohungsjagd zu konzentrieren, darauf konzentrieren, eine API zu lernen und esoterische Sprachen zu debuggen.

    Kestrel nutzt ein anderes, bereits existierendes OCA-Projekt namens STIX Shifter, das eines der Gründungsprojekte von OCA war. Es ist eine Datenabstraktionsschicht, die eine Übersetzung zwischen nativen APIs und dem Oasis STIX 2 Standard vornimmt… Aber es ist eine Art dumme Übersetzung… wie eine einfache Abfrage-Antwort. Es ist wie: “Geh und gib mir die Daten, und hier ist deine Datentabelle…” Kestrel läuft darauf und fügt eine weitere Ebene von Sprache und Analysen hinzu, so dass Sie echte Bedrohungsjagd betreiben können… Die Kombination der beiden ist also das, was leistungsstark ist.

    Im OCA GitHub Repository werden wir im Laufe der Zeit immer mehr Analysen zum Kestrel-Projekt hinzufügen, um Dinge wie Ausreißererkennung, Verhaltensanalyse und Prozessbefeuerung zu ermöglichen. Und das Tolle an diesem Projekt ist, dass jedes einzelne dieser Dinge, die wir oder jeder in der Community hinzufügt, jetzt gegen jedes Tool laufen kann. Es ist also kein Beaconing, das mit Crowdstrike funktioniert; es ist ein Beaconing, das mit 20 verschiedenen Plattformen funktioniert, weil jedes einzelne Mal, wenn man etwas zu Kestrel hinzufügt, es überall funktioniert. Und das ist es, was wirklich einzigartig daran ist.

    Können Sie auch näher erläutern, wie Kestrel die Automatisierung nutzt, um langwierige Jagdaufgaben auszuführen, während sich die Bedrohungsjäger auf Unternehmungen mit höherer Priorität konzentrieren können?

    Da es eine Orchestrierungssprache ist, können Sie mit Kestrel diese Jagdketten erstellen.

    Die Bedrohungsjagd ist normalerweise ein mehrstufiges Unterfangen. Es ist nicht nur: “Führe diese Abfrage aus und erhalte deine Ergebnisse zurück.” Sie führen etwas aus, erhalten die Ergebnisse zurück, wollen dann um diesen Teil der Daten herum schwenken und dann weitere Daten abrufen, um diese Datensätze zu verwerten, usw. usw.

    Kestrel ermöglicht es Ihnen, all diese Aktivitäten in einer Kette zu orchestrieren. Sie können also Datensatz A abrufen, Datensatz B abrufen, diese miteinander kombinieren, einen Ausreißer-Erkennungsalgorithmus darauf laufen lassen, diesen zurückziehen, eine weitere Ebene der Anreicherung vornehmen, indem Sie Bedrohungsdaten von Drittanbietern einbeziehen, und diese dann durch eine auf maschinellem Lernen basierende Bakenerkennung laufen lassen. Und dann werden die Ergebnisse ausgegeben. Sie können all dies in einem einzigen Notebook mit einer Reihe von Befehlen orchestrieren und dann automatisieren. Denn wenn Sie es einmal orchestriert haben, können Sie es jetzt automatisieren und regelmäßig ausführen, wann immer Sie eines dieser Aktivitätsmuster sehen.

    Kestrel nutzt Jupyter-Notizbücher – und Jupyter ist ein Tool, das bei Bedrohungsjägern immer beliebter wird, weil es die Möglichkeit bietet, die Daten innerhalb des Tools aufzuschneiden und zu würfeln… Mit Kestrel können Sie eine Hunt schreiben und sie innerhalb eines Jupyter-Notizbuchs ausführen, und sie über alle Ihre verbundenen Datenquellen laufen lassen, diese Daten zurückbringen und dann Ketten von Analysen anwenden, alles im selben Notizbuch.

    Und was wirklich cool ist, ist, dass wir uns eine Community vorstellen, die sich um dieses Projekt herum aufbaut. Denn diese Analysen, die entwickelt werden, diese Hunts, können dann mit anderen Benutzern über GitHub geteilt werden.

    War die Sprache in ihren früheren Stadien nur für IBM-Kunden verfügbar?

    Korrekt. Sie wurde intern entwickelt. Wir hatten Feedback von einigen unserer Kunden erhalten, ebenso wie von unseren internen Sicherheitsteams … Sie halfen beim Design der Sprache und bei der Verwendung des Produkts, während wir es ausbauten. Sie waren also die Hauptbeteiligten vor der Spende. [But] Es war nie beabsichtigt, nur intern zu sein.

    Wir haben schon vor einiger Zeit festgestellt, dass wir vorhaben, dies der OCA zu spenden. IBM Security ist sehr in die Mission der offenen Sicherheit investiert und Dinge dieser Art, die helfen können, die Messlatte gegen die Bedrohungsgegner zu erhöhen.

    Aber weil die OCA ein offenes Projekt mit offener Führung ist, kontrolliert IBM die OCA nicht… wir konnten nicht einfach als IBM kommen und sagen: “Wir geben euch das.” Wir mussten den Prozess durchlaufen… Wir mussten durch einen Abstimmungsprozess gehen. Alle anderen OCA-Vorstandsmitglieder stimmten für das Projekt.

    Was glauben Sie, warum das Projekt auf so viel Zustimmung gestoßen ist? Welchen Wert sahen die Mitglieder in der Sprache, und welche aktuellen Herausforderungen der Bedrohungsjagd geht Kestrel an?

    Das Projekt stimmt so gut mit der OCA-Mission überein, weil es sehr gut mit dem übereinstimmt, was wir zu erreichen versuchen, und weil es konsumierbar ist. Es ist ein Werkzeug, das SOC-Praktiker heute nutzen können. Einige der bestehenden OCA-Projekte waren keine Tools, sondern eher Bibliotheken, die sich auf die Verbesserung der Interoperabilität konzentrieren. Aber dies ist das erste OCA-Projekt, das sich speziell an SOC-Praktiker richtet.

    Nehmen wir zum Beispiel ein Unternehmen, das mehrere, unterschiedliche EDR- und SIEM-Lösungen hat – was wirklich die Mehrheit der Fälle ist. Die meisten Unternehmen haben mindestens ein SEIM und ein EDR, und wir kennen viele, die sogar mehrere davon haben. [In such a case,] Wenn Sie ein Hunt-Team oder sogar ein SOC-Team haben, das nach einem bestimmten Aktivitätsmuster sucht, haben Sie wirklich nicht viele Möglichkeiten, außer diese Analyse in jeder dieser Plattformen zu erstellen und sie dann auszuführen … Und jede dieser Plattformen ist ein anderes Datenmodell mit einer anderen Sprache, einer anderen Art und Weise, wie Sie die Daten in diesem Tool analysieren müssen, und Sie geraten in das, was ein Kollege von mir “Swivel-Chair-itis” nennt, bei dem Sie Ihren Stuhl von Tool zu Tool schwenken und versuchen, ein ganzheitliches Bild Ihres Unternehmens zu erhalten.

    Wir versuchen im Grunde, mehr von der Macht der Masse auf die Cybersecurity-Herausforderung zu bringen. Denn… in der gesamten Branche… arbeiten wir bei der Erkennungstechnik nicht genug zusammen. Jedes Mal, wenn es eine neue Zero-Day-Bedrohung oder eine neue Mitre-Angriffskette gibt, die entdeckt werden muss, gehen die Unternehmen hin und entwickeln diese Erkennungen für diese Dinge in einem Vakuum.

    Denn wenn es eine [critical] Microsoft Windows Drucker-Spooler-Schwachstelle gibt, wie es sie gab [this week]ist jedes CISO-Team auf dem Planeten unterwegs und versucht, Erkennungen zu erstellen, um diese in ihrer Umgebung zu finden. Und es gibt keinen wirklichen Mehrwert für die Cybersicherheitsbranche, wenn jeder immer und immer wieder das Gleiche tut. Und der Grund, warum wir das tun, ist… wir sind nicht in der Lage, zusammenzuarbeiten, weil wir keine Möglichkeit haben, plattformübergreifendes Detection Engineering zu betreiben. Das gesamte Detection Engineering ist proprietär und an die Plattform gebunden, die man gerade einsetzt.

    Einige Teile dieses Artikels stammen aus:
    www.scmagazine.com