Wer unsere Reihe zum PEAK-Framework für Threat Hunting verfolgt hat, weiß es womöglich bereits: Threat Hunting dient nicht nur dazu, Security Incidents aufzuspüren, die automatischen Erkennungssystemen entgangen sind. Dies ist eher ein nützlicher Nebeneffekt. Vielmehr geht es beim Threat Hunting jedoch darum, den Sicherheitsstatus sukzessive zu stärken.
Die Stärkung kann auf vielerlei Weise geschehen, worauf wir in künftigen Artikeln zum PEAK-Framework noch näher eingehen werden. Am offensichtlichsten ist jedoch, dass sich mittels Threat Hunting neue Methoden zur Erkennung böswilliger Aktivitäten identifizieren lassen. Das allerdings nützt nur dann wirklich etwas, wenn darauf der nächste logische Schritt folgt. Nämlich, dass ihr die identifizierten Erkennungsmethoden in die Produktion umsetzt, um nicht immer wieder aufs Neue Zeit und Energie zum Aufspüren ein und derselben Bedrohung aufwenden zu müssen. Hierzu gilt es, die jeweilige Methode in eure automatischen Erkennungssysteme zu implementieren, damit ihr eure begrenzte Zeit produktiver einsetzen könnt als fortwährend denselben Dingen hinterherzujagen. Hierzu kann es bereits genügen, einfach eine neue SIEM-Regel zu schreiben. Was aber, wenn eure neue Erkennungsmethode nicht ganz so einfach gestrickt ist?
In diesem Artikel beleuchten wir das PEAK-Framework im Kontext der sogenannten „Hierarchie der Erkennungsausgaben“, einem Modell zur Klassifizierung der verschiedenen Erkennungstypen, in die ihr eure Threat-Hunting-Methoden einordnen könnt. Außerdem klärt das Modell, wann die einzelnen Typen am besten geeignet sind. Sicher, ihr müsst euch nicht strikt daran halten – ähnlich wie der Piratenkodex ist sie eher eine Richtlinie. Dafür aber eine äußerst nützliche, daher sehen wir sie uns nun genauer an.
Die Hierarchie der Erkennungsausgaben
Die Hierarchie umfasst vier breit angelegte Erkennungskategorien, die nach dem Grad der Automatisierung geordnet sind, den sie bieten. Oder anders ausgedrückt: Danach, in welchem Umfang sie menschliche Eingriffe zum Aufspüren böswilliger Aktivitäten erfordern.
Die PEAK-Hierarchie der Erkennungsergebnisse
Die Hierarchie ist in folgende Ebenen unterteilt (von unten nach oben):
- Berichte: In einigen Fällen weiß man zwar, was man finden möchte. Doch dürfte die Suche auch viele irrelevante Ergebnisse wie etwa Fälle von autorisierter, harmloser Nutzung oder andere False Positives liefern. Um die eher seltenen Fälle für tatsächlich böswillige Absichten auszumachen, braucht es womöglich die Erfahrung und Fachkenntnis versierter Analystenteams. So könnte sich hier ein automatisierter Bericht als die beste Möglichkeit zur Erkennung erweisen. Lasst den Bericht nach einem geeigneten Zeitplan (täglich, wöchentlich, monatlich usw.) ausführen und stellt dann über die Ticket-Warteschlange der Analystenteams oder auf anderem Wege sicher, dass der Bericht tatsächlich von jemandem durchgegangen wird. Berichte bilden die unterste Ebene der Hierarchie und sind damit die am wenigsten wünschenswerte, da sie die meisten menschlichen Eingriffe erfordern. Sie sind nicht ideal, aber in bestimmten Szenarien noch immer die beste Strategie, auf die man setzen kann. Threat Hunting mit berichtsbasierter Erkennung lässt sich ggf. gut für zusätzliches Detection Engineering oder erneute Hunting-Aktivitäten in der Zukunft einsetzen. Sobald ihr etwas Erfahrung mit Berichten gesammelt habt, dürftet ihr aber bessere Wege finden, die relevanten Ergebnisse herauszufiltern und so in der Hierarchie aufzusteigen.
- Dashboards und Visualisierungen: Dashboards und Visualisierungen: Diese befinden sich eine Ebene über den Berichten und präsentieren in Übersichten aufbereitete Informationen anstelle von Rohdaten. Im Unterschied zu Berichten, in denen einzelne Events aufgelistet werden, sind Dashboards für Menschen leichter zu verstehen und zu erfassen. So machen sie etwa die Systeme ersichtlich, bei denen die Producer-Consumer Ratio, also das Verhältnis von generierten zu genutzten Daten am stärksten von der ermittelten Baseline abweicht, oder zeigen eine Heatmap der auf DMZ-Servern fehlgeschlagenen Anmeldungen. Dashboards und Visualisierungen erfordern zwar noch immer regelmäßig menschliche Eingriffe und beinhalten sehr wahrscheinlich auch eine ganze Reihe harmloser Einträge. Sie sind jedoch so aufgebaut, dass Analystenteams die wichtigen Punkte schnell erkennen können. Genau wie bei Berichten lässt sich auch die dashboard-basierte Erkennung weiter verfeinern, um in der Hierarchie weiter aufzusteigen.
- Analytics in Code: Ist bekannt, wie sich eine bestimmte Aktivität aufspüren lässt, für die Suche danach jedoch externe Berechnungen erforderlich sind, spricht man von „Analytics in Code“. So etwa, wenn ihr ein Skript oder Programm zur Datenanalyse erstellt, anhand derer sich die jeweilige Aktivität identifizieren lässt. Besonders häufig ist dies bei modelgestütztem Threat Hunting der Fall, die Methode kann aber grundsätzlich auch in allen anderen Szenarien zum Einsatz kommen. Im Idealfall erhaltet Ihr damit eine äußerst präzise Code-Ausgabe, die sich in Form einer Warnmeldung in euer SIEM implementieren lässt. In puncto Automatisierung und Alerting ist diese Hierarchieebene durchaus respektabel, allerdings müsst ihr eventuell einen Mechanismus einrichten, der eine regelmäßige Ausführung des Codes verlässlich gewährleistet.
- Signaturen und Regeln: Ganz oben in der Hierarchie sind IDS-Signaturen und SIEM-Regeln verortet. Hier braucht es keine menschlichen Eingaben zur Generierung von Warnmeldungen, außerdem gestaltet sich die Handhabung einfacher als bei in Code geschriebenen Analysen. Soweit möglich sind Signaturen und Regeln daher die bevorzugte Option für die automatische Erkennung.
Praktische Anwendung der Hierarchie
Im Prinzip ist es ganz einfach, die Hierarchie auf eure Threat-Hunting-Aktivitäten anzuwenden. Stellt euch im Anschluss an diese nur folgende Fragen:
- Habe ich herausgefunden, wie sich die jeweilige Aktivität aufspüren lässt? Und sollte ihr keine böswilligen Aktivitäten entdeckt haben, ist das kein Grund zur Sorge, sondern vollkommen normal. Threat Hunting kann auch dann erfolgreich sein, wenn ihr das Gesuchte nicht gefunden habt – vorausgesetzt, ihr seid sicher, dass ihr es gefunden hättet, wenn es vorhanden gewesen wäre.
- Vertraue ich meinem Ergebnis so weit, dass ich es dem Analystenteam vom SOC als Warnmeldung präsentieren würde? Wenn ja, solltet ihr entweder auf Analytics in Code oder Signaturen und Regeln setzen. Andernfalls sind womöglich Berichte oder Dashboards und Visualisierungen die beste Wahl. In jedem Fall sollte ihr die höchste Ebene wählen, deren Implementierung umsetzbar ist. So sind Dashboards besser als Berichte, während Regeln besser sind als Code.
Dennoch braucht ihr euch die Wahl nicht allzu schwer machen. Entscheidet euch einfach für das, was euch als das Beste erscheint. Wenn es nicht funktioniert, könnt ihr es jederzeit ändern. Prüft daher immer wieder einmal eure Berichte und Dashboards dahingehend, ob ihr die jeweiligen Erkennungen auch auf höherer Ebene umsetzen könnt.
Bedenkt zudem, dass sich für eine bestimmte Threat-Hunting-Aktivität potenziell auch mehr als ein Erkennungsmechanismus ausmachen lässt. Ihr könnt Erkennungen also auch auf verschiedenen Ebenen der Hierarchie einrichten.
Fazit
Nachdem die Stärkung eures Sicherheitsstatus das wichtigste Ziel von Threat Hunting darstellt, solltet ihr anhand der dabei gewonnen Erkenntnisse neue Erkennungsmechanismen einrichten. So erzielt ihr die größtmögliche Wirkung. Wichtig ist nur, dass die verschiedenen Erkennungstypen ein unterschiedliches Maß an menschlicher Aufmerksamkeit bei der Verarbeitung erfordern und unterschiedliche Automatisierungsgrade bieten. Die Hierarchie der Ausgaben zu Erkennungen des PEAK-Frameworks erleichtert es euch, die Abdeckung eurer Erkennungsmechanismen zu vergrößern, und trägt zugleich zur Minimierung des Kostenaufwands aufseiten eurer Analystenteams bei.
Wie üblich ist das Thema Sicherheit bei Splunk Teamwork. Dank an Autoren und Mitwirkende: David Bianco, Ryan Fetterman.
*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier.
