Gewinne:
- Verstehen Sie, wie die Bedrohungssuche mit einer überprüfbaren Hypothese und nicht mit einem Alarm beginnt und wie künstliche Intelligenz bei der Hypothesengenerierung und dem Abfrageentwurf hilft.
- Fähigkeit, anzuwenden, dass das durch künstliche Intelligenz hervorgehobene gegenteilige/seltene Signal nicht automatisch eine böswillige Absicht bedeutet und dass die Hypothese durch Rohbeweise bestätigt werden muss.
- Möglichkeit, die von künstlicher Intelligenz bereitgestellten technischen MITRE ATT&CK-Nummern und Ereignis-IDs anhand der offiziellen Quelle zu überprüfen und erfundene technische Details zu eliminieren
Die klassische Sicherheitsüberwachung funktioniert nach der Logik „Warten Sie auf den Alarm, schauen Sie, wann er kommt“. Aber die gefährlichsten Angreifer versuchen, keinen Alarm auszulösen: Sie verwenden legitime Tools (das nennt man „Exploiting“ – das heißt, sie missbrauchen Tools, die bereits auf dem System vorhanden sind, wie PowerShell, WMI), bewegen sich langsam und stören den normalen Datenverkehr. Aus diesem Grund wurde die Bedrohungssuche geboren: Ohne auf einen Alarm zu warten: „Wenn es einen derzeit unentdeckten Angreifer in meiner Organisation gäbe, wo wäre er dann?“ Proaktive Spurensuche mit der Frage: Bedrohungsjagd beginnt mit einer Hypothese, nicht mit einem Alarm.
Künstliche Intelligenz ist bei der Bedrohungsjagd an zwei Stellen sehr nützlich. Die erste besteht darin, eine Hypothese zu erstellen: Geben Sie eine Angriffstechnik an und fragen Sie: „Wenn diese Technik in meiner Einrichtung verwendet würde, auf welchen Protokollen und in welchem Muster würde sie Spuren hinterlassen?“ du kannst fragen. Die zweite Möglichkeit ist die Signalextraktion: Sie kann das Seltene, Ausreißer, „andere als das Normale“ in Big Data hervorheben. Aber die KI weiß nicht, was für Ihr Unternehmen normal ist, und tappt möglicherweise in die Falle, eine Hypothese für „bewiesen“ zu halten. Bei der Bedrohungssuche fungiert die KI als Gedankenpartner und Scanner; Der Jäger (Analyst) entscheidet, ob die Beute eine echte Bedrohung vorfindet und ob diese gemeldet wird.
Schritte der Bedrohungssuche
- Hypothese. Ein konkreter, überprüfbarer Satz: „Ein Angreifer scannt möglicherweise das interne Netzwerk außerhalb der Geschäftszeiten mit einem kompromittierten Konto.“ Hier können Sie KI zum Brainstorming nutzen.
- Identifizieren Sie die Datenquelle. Welches Protokoll beweist/widerlegt die Hypothese? (Zum Beispiel Firewall- und DNS-Protokolle für Netzwerkscans, Identitätsprotokolle für die Rechteausweitung.)
- Entwerfen Sie die Abfrage. Die Abfrage, die nach dem Zielmuster sucht (SIEM-Abfragesprache, KQL, SQL-ähnlich). KI hilft beim Verfassen von Anfragen; Aber Sie überprüfen die Abfrage und führen sie aus.
- Extrahieren Sie das Ergebnis. Filtern Sie das echte Signal aus Hunderten von ausgegebenen Leitungen. Hier führt KI Clustering und Zusammenfassung durch.
- Bestätigen oder widerlegen. Bestätigen Sie anhand von Rohbeweisen und Kontext, ob die gefundene Spur wirklich böswillig oder harmlos ist.
- Dokumentieren Sie das Ergebnis und wandeln Sie es in eine Bestimmung um. Konvertieren Sie das tatsächlich gefundene Muster in eine permanente Erkennungsregel. Wenn die Hypothese fehlschlägt, notieren Sie dies ebenfalls (ein negatives Ergebnis ist ebenfalls eine Information).
Begriffe: TTP (Taktiken, Techniken, Verfahren – Verhaltensmuster des Angreifers). MITRE ATT&CK ist eine aufgezählte und dokumentierte Bibliothek von Angreifertechniken (z. B. T1078 „Valid Accounts“); Es bietet eine gemeinsame Sprache bei der Bedrohungssuche. IOC (Indicator of Infringement – schlechte IP, Hash, Domain). Weißes Rauschen (Whitelist/bekanntermaßen gut) ist ein normales Verhalten, das bekanntermaßen dazu führt, dass Beute geopfert wird.
Tabelle der Ansätze zur Bedrohungssuche
Ansatz
Ausgangspunkt
Beitrag der KI
Achtung
Hypothesenbasierte Jagd
„Wenn es so einen Angreifer gäbe…“
Hypothesengenerierung, Musterbeschreibung
Eine Hypothese ist kein Beweis
IOC-basierte Jagd
Bekanntermaßen schlechter Indikator
Zuordnung von IOCs zu Protokollen
Altes/falsches IOC führt in die Irre
TTP/ATT&CK-basierte Jagd
Eine Technik (T-Nummer)
Konvertieren der Technik in ein Protokollmuster
Technik ≠ Einzelmuster
Anomaliebasierte Jagd
Statistische Abweichung
Markieren Sie den Ausreißer
Widersprüchlich ≠ Bösgläubigkeit
Analyse der Stapelhäufigkeit
„Was ist am seltensten?“
Das seltene Ereignis finden
Selten ≠ gefährlich
drei Mini-Koffer
Fall 1 – Das Seltene finden. Ein Jäger könnte fragen: „Welcher Prozess im internen Netzwerk läuft auf den wenigsten Computern, stellt aber die meisten Netzwerkverbindungen her?“ stellt seine Hypothese auf. Die KI hebt ein Muster aus den anonymisierten Prozessverbindungsdaten hervor: Ein Prozess namens svchost32.exe, der nur auf zwei Maschinen zu sehen ist, stellt eine Verbindung zu 340 verschiedenen externen Adressen her. Der Jäger untersucht dies; Es findet eine Malware, die die legitime Datei svchost.exe nachahmt. KI hat das Seltene gefiltert; Der Jäger stellte die Diagnose und intervenierte.
Fall 2 – Die gescheiterte (aber wertvolle) Jagd. Ein Jäger fragte: „Könnte es außerhalb der Geschäftszeiten zu Massendownloads von Daten kommen?“ stellt seine Hypothese auf; AI schreibt den entsprechenden Abfrageentwurf. Ergebnis: 3 Benutzer haben nachts heruntergeladen, aber alle drei sind Büroangestellte im Ausland und arbeiten aufgrund von Zeitzonenunterschieden während der Geschäftszeiten. Die Hypothese ist widerlegt. Der Jäger dokumentiert dies als „negatives Ergebnis“ und vermerkt diese 3 Benutzer als Ausnahmen für zukünftige Jagden. Auch die erfolglose Jagd ermöglichte es uns, die Institution besser kennenzulernen.
Fall 3 – Künstliche technische Falle. Ein Jäger fragt AI: „Wie suche ich in meiner Organisation nach der T1055-Technik?“ sagt. Die KI schreibt eine überzeugende Abfrage und Behauptung, dass „T1055 die folgende Ereignis-ID generiert“; aber die von ihm angegebene Ereignis-ID ist falsch und das Modell stellte eine ATT&CK-Subtechnik dar. Avcı öffnet den MITRE ATT&CK-Datensatz, bestätigt die technische Beschreibung und die tatsächlichen Protokollquellen und korrigiert die falsche Ereignis-ID. Lektion: Überprüfen Sie jedes technische Detail, das die KI angibt (Ereignis-ID, T-Nummer, Protokollfeld), mit der offiziellen Quelle.
Schwache Eingabeaufforderung / Starke Eingabeaufforderung
Schwache Eingabeaufforderung:
Finden Sie heraus, ob sich ein Angreifer in meinem Netzwerk befindet.
Diese Behauptung ist hypothesenfrei, datenfrei, unbegrenzt und nicht überprüfbar. KI erstellt eine allgemeine oder erfundene Liste; es nützt nichts.
Kraftvolle Aufforderung:
Ihre Rolle: Assistent, der dem Bedrohungsjäger Ideen und Skizzen gibt. Entscheiden Sie sich nicht, sagen Sie nicht „Es besteht eine Bedrohung“. Meine Hypothese: „Ein kompromittiertes Konto scannt möglicherweise interne Ports außerhalb der Geschäftszeiten.“ Generieren Sie Folgendes: (1) Listen Sie die Protokollquellen auf, die diese Hypothese beweisen und widerlegen, (2) beschreiben Sie das konkrete Muster, das durchsucht werden soll (welche Felder, welche Schwellenwerte), (3) schreiben Sie einen Entwurf einer Beispielabfrage und kommentieren Sie jede Zeile aus, (4) notieren Sie, welche unschuldigen Erklärungen im resultierenden Ergebnis eliminiert werden. Schlagen Sie die entsprechende MITRE ATT&CK-Technik vor, markieren Sie die T-Nummer und die Ereignis-ID jedoch als „[muss von MITRE überprüft werden]“ und erfinden Sie sie nicht.
Die starke Behauptung beginnt mit einer konkreten Hypothese, stellt das Gleichgewicht zwischen Beweisen und Widerlegungen her, erklärt die Frage und überlässt die technischen Details der Überprüfung.
Kopierbare Eingabeaufforderungsvorlagen
VORLAGE ZUR HYPOTHESENERSTELLUNGFür meine Institution [Entität: z.B. Generieren Sie überprüfbare Hypothesen zur Bedrohungssuche im Kontext von [Active Directory/Cloud/Endpunkt]5. Für jede Hypothese: (1) auf welches Angreiferverhalten sie abzielt, (2) welche Protokollquelle Beweise/Widerlegungen liefern wird, (3) das erwartete Muster. Bilden Sie überprüfbare Sätze, keine allgemeinen.
TECHNIKMUSTER MUSTER Ich werde in meiner [Technikname]-Institution nach der folgenden Angriffstechnik suchen. Generieren Sie: (1) Protokollbereiche, in denen die Technik normalerweise ihre Spuren hinterlässt, (2) konkrete Muster und Schwellenwerte, nach denen gesucht werden muss, (3) harmlose (falsch positive) Situationen, die dieses Muster auslösen könnten. Bieten Sie die relevante MITRE ATT&CK T-Nummer an, jedoch mit der Markierung „[Muss von MITRE überprüft werden]“; Geben Sie keine erfundene Ereignis-ID/-Nummer an.
ABFRAGEENTWURFSVORLAGENSchreiben Sie einen [SIEM/KQL/SQL]-Abfrageentwurf, der nach dem folgenden Muster sucht: [Musterbeschreibung]. Kommentieren Sie jede Zeile, erklären Sie, welches Feld Sie filtern und warum, und markieren Sie Leistungsrisiken. Ich werde die Abfrage überprüfen und ausführen. Gehen Sie nicht davon aus, dass Sie es ausführen werden. Lassen Sie die Feldnamen gemäß dem mir bekannten Schema mit „[korrekt zum Schema]“ markiert.
ERGEBNIS ELIMINIERENDE VORLAGE Das Ergebnis meiner Suche ergab die folgenden Zeilen (anonym): [Einfügen]. Gruppieren Sie sie und schreiben Sie für jede Gruppe (1) ein bösartiges Szenario, (2) mindestens zwei harmlose Erklärungen und (3) zusätzliche Beweise, nach denen Sie zur Unterscheidung suchen müssen. Entscheidungsfindung; Lass nicht zu, dass ich dich trenne. Markieren Sie „[keine Grundlage]“ für eine Behauptung, für die es keine Beweise gibt.
Häufige Fehler
- Jagd ohne Hypothesen. Wenn man sagt: „etwas finden“, drängt die KI dazu, zu raten und etwas zu erfinden; Die Jagd beginnt mit einem konkreten, überprüfbaren Satz.
- Eine Hypothese mit Beweis verwechseln. Die Jagd testet eine Möglichkeit; Die gefundene Spur stellt keine „Bedrohung“ dar, bis sie durch konkrete Beweise bestätigt wird.
- Das Gegenteil wird automatisch als schlecht angesehen. Der seltene/Ausreißer ist oft unschuldig (Wartung, neue Software, einmaliger Auftrag); Mit Kontext durchsieben.
- Technische Details werden nicht überprüft. AI kann Ereignis-ID, T-Nummer und Protokollfeld abgleichen; Bestätigen Sie mit MITRE ATT&CK und der Produktdokumentation.
- Den verschwendeten Fang wegwerfen. Das negative Ergebnis ist auch Wissen: Man lernt die Organisation besser kennen und reduziert zukünftige Fehlalarme; dokumentieren.
Tipp: Eine gute Threat-Hunting-Hypothese sollte „überprüfbar“ sein: eine konkrete Behauptung, die sich als wahr oder falsch herausstellen kann. „Gibt es etwas Schlimmes in meinem Netzwerk?“ kann nicht getestet werden; „Hat Konto X außerhalb der Geschäftszeiten eine Verbindung zu mehr als 50 internen IPs hergestellt?“ kann getestet werden.
Achtung: Threat Hunting wird nur auf Systemen durchgeführt, für die Sie berechtigt sind. Die Aufforderung an die KI, eine andere Organisation, eine Person oder ein Netzwerk zu „untersuchen“, für das Sie keine Berechtigung haben, ist ein Versuch, sich unbefugten Zugriff zu verschaffen und liegt außerhalb dieses Moduls.
Zusammenfassend
Beim Threat Hunting wird proaktiv nach Spuren eines versteckten Angreifers gesucht, ohne auf einen Alarm zu warten. Dabei beginnt man mit einer Hypothese, nicht mit einem Alarm. KI bietet in diesem Prozess zwei leistungsstarke Beiträge: die Generierung überprüfbarer Hypothesen und Abfrageentwürfe sowie das Filtern seltener/Ausreißersignale aus Big Data. Aber die KI weiß nicht, was für Ihr Unternehmen normal ist, sie kann technische Details erfinden und in die Falle tappen, eine Hypothese mit Beweisen zu verwechseln. Die Jagd besteht also aus sechs Schritten (Hypothese, Daten, Abfrage, Extrahieren, Überprüfen, Dokumentieren) und bei jedem Schritt liegt die Entscheidung beim Jäger. Widersprüchlich ≠ schlecht, Hypothese ≠ Beweis, technisches Detail durch KI gegeben ≠ richtig; alles durch Rohbeweise und MITRE ATT&CK bestätigt.
Anwendungsaufgabe
Erhalten Sie 5 Hypothesen zur Bedrohungssuche durch KI mit der Vorlage „Hypothesegenerierung“ für Ihre eigene Organisation (oder eine Beispielumgebung). Wählen Sie die testbarste Option aus, entwerfen Sie eine Abfrage mit den Vorlagen „Mustertechnik“ und „Abfrageentwurf“, validieren Sie jede Zeile in der Abfrage und jede vorgeschlagene T-Nummer in MITRE ATT&CK. Notieren Sie das Ergebnis (wurde die Hypothese bestätigt, widerlegt, was haben Sie gelernt) in einer kurzen Jagdnotiz.
Checkliste
- [ ] Ich begann meine Suche mit einer konkreten, überprüfbaren Hypothese.
- [ ] Ich habe Protokollquellen identifiziert, die die Hypothese sowohl beweisen als auch widerlegen.
- [ ] Ich habe jede Zeile des Abfrageentwurfs überprüft und an mein eigenes Schema angepasst.
- [ ] Ich habe die vorgeschlagene MITRE ATT&CK-Technik und die Ereignis-IDs mit der offiziellen Quelle überprüft.
- [ ] Ich habe jedes Signal mit Rohbeweisen und Kontext bestätigt; Das Gegenteil empfand ich nicht automatisch als schlecht.
- [ ] Ich habe auch die Hypothese dokumentiert, die fehlgeschlagen ist (das negative Ergebnis ist Information).
- [ ] Ich habe nur auf Systemen gejagt, zu deren Jagd ich berechtigt war.