Eigene Threat Intelligence-Feeds einbinden
Dieser Leitfaden richtet sich an Sicherheits- und Erkennungsingenieure, die benutzerdefinierte Indikatoren für eine Kompromittierung (Indicators of Compromise, IoC) und Threat Intelligence-Feeds von Drittanbietern in Google Security Operations einbinden möchten. Darin wird beschrieben, wie Sie Threat-Feeds aufnehmen, Indikatoren im Unified Data Model (UDM) Entity Context Graph (ECG) normalisieren und Indikatoreinheiten mit Streaming-Ereignis-Telemetrie korrelieren. Mit dieser Methode automatisieren Sie die Erkennung von Bedrohungen in Ihrer Umgebung und vermeiden manuelle Indikatorsuchen. Durch eine erfolgreiche Integration werden die Zeiten für die Triage von Benachrichtigungen verkürzt und der Sicherheitsstatus Ihrer Organisation durch die Erkennung von Bedrohungen in Echtzeit und rückwirkend verbessert.
Durch die Einbindung benutzerdefinierter Threat Intelligence-Feeds kann Ihr Sicherheitsteam externe Indikatorstreams (z. B. Malware Information Sharing Platform (MISP), STIX/TAXII oder kommerzielle Feeds) mit Ihrer internen Sicherheitstelemetrie kombinieren. Nach der Normalisierung im ECG unterstützen Threat-Entitäten sowohl den automatischen Indikatorabgleich als auch benutzerdefinierte YARA-L 2.0-Korrelationsregeln für mehrere Ereignisse.
Schlüsselterminologie
- Entity Context Graph (ECG): Die kontextbezogene Speicherebene in Google SecOps, in der zustandsbehaftete Entitätsdatensätze (z. B. Assets, Nutzer und Bedrohungsindikatoren) zur Korrelation mit Protokollen für Sicherheitsereignisse gespeichert werden.
- Einheitliches Datenmodell (Unified Data Model, UDM): Das standardisierte Schema, das von Google SecOps verwendet wird, um Rohereignisprotokolle und kontextbezogene Entitätsdaten zu normalisieren.
- Lebenszyklusintervall für Indikatoren (
metadata.interval): Das zeitlich begrenzte Gültigkeitsfenster (start_timeundend_time), das definiert, wann ein Bedrohungsindikator im ECG aktiv ist. - Automatischer IoC-Abgleich: Ein vom System generiertes Ergebnis, das erstellt wird, wenn ein eingehendes Sicherheitsereignis mit einer aktiven Indikatoreinheit im ECG übereinstimmt. Es wird auf der Seite IoC-Abgleiche angezeigt.
- YARA-L-Retrohunt: Eine On-Demand-Verlaufsanalyse, bei der eine YARA-L 2.0-Erkennungsregel für bis zu 30 Tage alte Sicherheitstelemetriedaten ausgeführt wird.
Gängige Anwendungsfälle
Die folgenden Anwendungsfälle zeigen, wie Sie mit Ihrer eigenen Threat Intelligence allgemeine Ziele für Sicherheitsvorgänge erreichen können.
Automatischer Abgleich von Indikatoren in Echtzeit
- Ziel: Streaming-Sicherheitsereignisse automatisch anhand von aufgenommenen Drittanbieterindikatoren auswerten, ohne benutzerdefinierte Korrelationsregeln zu pflegen.
- Wert: Manuelle Regelwartung für Threat-Feeds mit hohem Volumen wird überflüssig und sofortige Übereinstimmungen werden auf der Seite IoC-Übereinstimmungen angezeigt.
Benutzerdefinierte YARA-L-Korrelationsregeln und Retrohunting
- Ziel: Führen Sie Threat Intelligence-Entitäten im ECG mit Telemetrie für mehrere Ereignisse zusammen und scannen Sie mit Retrohunts bis zu 30 Tage Verlaufsdaten.
- Wert: Erkennt mehrstufige Angriffe und deckt frühere Kompromittierungen auf, die vor dem Hinzufügen eines Indikators zu Ihren Threat-Feeds aufgetreten sind.
Hinweis
Prüfen Sie zuerst, ob die folgenden Voraussetzungen erfüllt sind:
- Berechtigungen: Sie benötigen Identity and Access Management-Berechtigungen, um Datenfeeds zu verwalten und Erkennungsregeln in Google SecOps zu erstellen, z. B.
Chronicle API AdminoderChronicle API Editor. Weitere Informationen zu den erforderlichen Rollen finden Sie unter Funktionszugriff konfigurieren. - Umgebungsprüfung: Prüfen Sie, ob Sie eine aktive Google SecOps-Instanz und gültige API-Anmeldedaten oder Endpunkt-URLs für Ihren externen Anbieter von Threat Intelligence-Daten (z. B. MISP, STIX/TAXII oder Cloud Storage-Buckets) haben.
- Funktionsweise von Suche und Regeln: Mit der UDM-Suche können Sie Rohdatensätze von Entitäten, die im ECG gespeichert sind, unabhängig von ihrem aktiven Zeitraum untersuchen. Bei YARA-L-Erkennungsregeln und dem automatischen Abgleich werden nur Indikatoren ausgewertet, deren
metadata.intervalden Ereignis-Zeitstempel enthält. - Dashboard- und Suchfeldpräfixe: Wenn Sie Threat Intelligence-Entitäten in der UDM-Suche, in Dashboards oder in YARA-L-Regeln abfragen, verwenden Sie das Präfix
graph.entity.für Indikatorwerte (z. B.graph.entity.ip) und das Präfixgraph.metadata.threat.für Felder zur Zuordnung von Bedrohungen.
Threat Intelligence-Indikatoren aufnehmen
Wählen Sie einen Aufnahmemechanismus aus und konfigurieren Sie ihn, um externe Indikatorstreams in Google SecOps zu importieren.
Mechanismus für die Feedaufnahme auswählen
Sie können Threat Intelligence-Feeds mit einem der folgenden unterstützten Mechanismen aufnehmen:
- Vordefinierte Standardparser: Google SecOps enthält Standardparser für viele Threat Intelligence-Plattformen. Eine Liste der unterstützten Parser, die unter IOC kategorisiert sind, finden Sie unter Unterstützte Logtypen und Standardparser. Zu den unterstützten Anbietern gehören MISP, ThreatConnect, Intel471 und Cyjax.
- Feed Management API: Konfigurieren Sie Feeds in der Google SecOps-Konsole oder mit der Feed Management API, um regelmäßig Indikatoren von externen HTTPS-, Cloud Storage- oder Amazon S3-Endpunkten abzurufen.
- Ingestion API: Senden Sie vorab strukturierte Nutzlasten für Entitäten direkt an Google SecOps über die Ingestion API.
- Bindplane-Agent: Mit dem Bindplane-Agent können Sie Indikatorlogs aus lokalen oder Cloud-Umgebungen erfassen und weiterleiten.
- Cloud Run-Funktionen: Stellen Sie serverlose Erfassungsskripts mit Cloud Run-Funktionen bereit, um Indikatoren aus externen APIs (z. B. STIX/TAXII oder MISP) abzurufen und in Google SecOps zu streamen. Weitere Informationen finden Sie unter Aufnahmeskripts verwenden, die als Cloud Run-Funktionen bereitgestellt werden.
- Google SecOps-Reaktionsintegrationen: Nehmen Sie Indikatoren über Content Hub-Connectors auf, um Bedrohungslisten als Teil automatisierter Playbooks zu synchronisieren. Weitere Informationen finden Sie unter Content Hub verwenden.
Threat Intelligence-Feeds einbinden
So nehmen Sie Indikatorlogs von Ihrem Anbieter von Bedrohungsinformationen in Google SecOps auf:
Folgen Sie dem Onboarding-Verfahren für Ihr spezifisches Threat-Feed-Format oder Ihren Anbieter:
- STIX/TAXII: Weitere Informationen finden Sie unter STIX-Logs zur Bedrohungsanalyse erfassen oder unter Auf Cloud Run-Funktionen bereitgestellte Aufnahmeskripts verwenden (STIX/TAXII) (Logtyp
STIX). - MISP: Siehe MISP-IoC-Logs erfassen oder Auf Cloud Run-Funktionen bereitgestellte Aufnahmeskripts verwenden (MISP) (Logtyp
MISP_IOC). - Benutzerdefinierte CSV-Feeds: Weitere Informationen finden Sie unter Benutzerdefinierte IoC-Dateien im CSV-Format erfassen (Protokolltyp
CSV_CUSTOM_IOC). - ThreatConnect: Weitere Informationen finden Sie unter ThreatConnect-IoC-Logs erfassen oder ThreatConnect-IoC-Logs mit der v3-API erfassen (Logtypen
THREATCONNECT_IOCundTHREATCONNECT_IOC_V3). - Recorded Future: Weitere Informationen finden Sie unter Recorded Future-IoC-Logs erfassen (Logtyp
RECORDED_FUTURE_IOC). - Anomali ThreatStream: Weitere Informationen finden Sie unter Anomali ThreatStream-IoC-Logs erfassen (Logtyp
ANOMALI_IOC). - CrowdStrike Falcon Intelligence: Weitere Informationen finden Sie unter CrowdStrike-IoC-Logs erfassen (Logtyp
CROWDSTRIKE_IOC). - Proofpoint Emerging Threats Pro: Weitere Informationen finden Sie unter Proofpoint Emerging Threats Pro-IoC-Logs erfassen (Logtyp
ET_PRO_IOC). - Andere kommerzielle und Open-Source-Feeds: Die Anleitung für das Onboarding und den Logtyp für Ihren Anbieter finden Sie unter Unterstützte Logtypen und Standardparser.
- STIX/TAXII: Weitere Informationen finden Sie unter STIX-Logs zur Bedrohungsanalyse erfassen oder unter Auf Cloud Run-Funktionen bereitgestellte Aufnahmeskripts verwenden (STIX/TAXII) (Logtyp
Weisen Sie den eingehenden Feeddaten den entsprechenden IoC-Logtyp zu, z. B.
STIX,MISP_IOC,CSV_CUSTOM_IOCoderTHREATCONNECT_IOC, damit der Standardparser Indikatorattribute in UDM-Entitätsfelder extrahiert.Öffnen Sie das Dashboard Data ingestion (Datenaufnahme) und prüfen Sie, ob eingehende Logeinträge ohne Fehler bei der Analyse angezeigt werden.
Entitätskontextdiagramm erstellen und validieren
Wenn Threat-Indikatoren in Google SecOps eingehen, werden sie in der Parsing-Pipeline in UDM-Entitätsdatensätze normalisiert und das ECG wird damit gefüllt. Weitere Informationen zur Funktionsweise der Entitätsanreicherung finden Sie unter So reichert Google SecOps Ereignis- und Entitätsdaten an.
Zuordnung von strukturierten und unstrukturierten Daten
Je nachdem, wie Sie Threat Intelligence-Daten an Google SecOps senden, müssen Sie den entsprechenden Workflow für die Feldzuordnung ausführen:
- Datenaufnahme strukturierter Daten: Wenn Sie vorstrukturierte UDM-Entitätsdatensätze direkt über die Ingestion API senden, formatieren Sie jede Nutzlast vor der Aufnahme gemäß dem UDM-Schema
Entity. - Aufnahme unstrukturierter und semistrukturierter Daten: Wenn Sie Rohlogs (z. B. CSV, JSON, STIX oder CEF) über Feeds, den Bindplane-Agent oder Forwarder senden, weisen Sie einen vordefinierten Standardparser zu oder erstellen Sie benutzerdefinierte Feldzuordnungen mit Parser-Erweiterungen, um Indikatorwerte zu extrahieren und den erforderlichen UDM-Entitätsfeldern zuzuordnen.
Was macht eine Entität zu einem IoC?
Damit ein Entitätseintrag im ECG durch automatische Abgleichs- und Erkennungsregeln als umsetzbarer IoC erkannt wird, müssen die folgenden fünf UDM-Feldgruppen vom Parser oder der API-Nutzlast ausgefüllt werden:
- Entitätstyp (
metadata.entity_type): Der unterstützte Entitätstyp für Indikatoren, z. B.DOMAIN_NAME,IP_ADDRESS,FILEoderURL. - Quelltyp (
metadata.source_type): Die Datenquellenklassifizierung, die für vom Kunden aufgenommene Threat Intelligence-Feeds aufENTITY_CONTEXTfestgelegt werden muss. - Artefakt-ID (
entity.*): Der Indikatorwert selbst, z. B.graph.entity.ip,graph.entity.hostname,graph.entity.domain.name,graph.entity.file.sha256(odermd5undsha1) odergraph.entity.url. - Metadaten zu Bedrohungen (
metadata.threat): Kontextbezogene Attribute, die die Bedrohung beschreiben, einschließlichthreat_feed_name,threat_name,category,severityundconfidence. Lebenszyklusintervall (
metadata.interval):metadata.interval.start_time: Der Zeitstempel, der angibt, wann der Indikator aktiv wird.metadata.interval.end_time: Der Zeitstempel, der angibt, wann der Hinweis abläuft.
Schema-Definitionen finden Sie in der UDM-Feldliste für Entity und unter EntityMetadata.
Aufgenommene IoC-Daten mit der UDM-Suche überprüfen
Indikatoren sind in der Regel innerhalb von 2 bis 5 Minuten nach der Aufnahme und Verarbeitung in der UDM-Suche verfügbar. Prüfen Sie, ob Ihre Indikatoren im EKG angezeigt werden, indem Sie eine UDM-Suche ausführen:
- Wählen Sie im Navigationsmenü von Google SecOps Investigation > Search aus.
Geben Sie im Suchfeld eine Anfrage ein, die auf den Entitätsgraphen für einen aufgenommenen Indikatorwert abzielt:
IP-Adresse:
graph.entity.ip = "<var>IP_ADDRESS</var>"Domain:
graph.entity.hostname = "<var>DOMAIN_NAME</var>"Dateihash (SHA-256):
graph.entity.file.sha256 = "<var>SHA256_HASH</var>"Quellprodukt:
graph.metadata.source_product = "<var>SOURCE_PRODUCT_NAME</var>"
Klicken Sie auf Suchen oder drücken Sie die Eingabetaste.
Klicken Sie auf die zurückgegebene Entitätskarte und prüfen Sie, ob die Felder
threatundintervaldie erwarteten Metadaten und aktiven Zeitstempel enthalten.
Telemetriedaten korrelieren und Bedrohungen erkennen
Nachdem die Bedrohungsindikatoren im ECG angezeigt werden, können Sie sie mit eingehenden und historischen Sicherheitsereignissen in Beziehung setzen.
Automatischen IoC-Abgleich aktivieren
Google SecOps umfasst eine automatische Abgleichs-Engine, die unabhängig von benutzerdefinierten Erkennungsregeln funktioniert. Wenn die Ereignis-Telemetrie mit einem aktiven Indikator im EKG übereinstimmt:
- Systemgenerierte Übereinstimmungen: Die Plattform erstellt automatisch einen IoC-Abgleich-Datensatz, ohne dass benutzerdefinierte Regeln verwaltet werden müssen.
- Geschätzter Zeitpunkt nach der Aufnahme (ungefähre Schätzung):
- Streamingereignisse: Sobald ein Indikator das EKG füllt (in der Regel 5 bis 15 Minuten nach der Aufnahme), wertet Google SecOps eingehende Streamingereignisse aus und zeigt Übereinstimmungen auf der Seite IoC-Übereinstimmungen innerhalb von 5 bis 15 Minuten an.
- Verlaufsereignisse: Die automatische Abgleichs-Engine vergleicht neu aufgenommene Indikatoren auch rückwirkend mit Verlaufsdaten in Batchzyklen. Erste Übereinstimmungen werden in der Regel innerhalb von 1 bis 4 Stunden angezeigt. Die vollständige Verlaufsübereinstimmung dauert bis zu 24 Stunden.
- Intervall-Durchsetzung: Die Matching-Engine wertet Ereignisse nur anhand aktiver Indikatoren aus, deren Zeitstempel innerhalb von
metadata.intervalliegt.
YARA-L 2.0-Korrelationsregeln erstellen
Sie können YARA-L 2.0-Erkennungsregeln schreiben, um Ereignis-Telemetriedaten (z. B. Netzwerkverbindungen, DNS-Abfragen oder Prozessstarts) mit Indikatorentitäten im ECG zu verknüpfen. Mit benutzerdefinierten Regeln können Sie Indikatorübereinstimmungen mit Verhaltensschwellenwerten, Asset-Kontext und Ausschlusslisten kombinieren:
- Wählen Sie im Navigationsmenü von Google SecOps Detection > Rules & Detections aus und klicken Sie dann auf New.
- Definieren Sie im Abschnitt
events:Ihrer Regel eine Platzhaltervariable, um ein UDM-Ereignisfeld (z. B.$net.target.ip = $ip) mit dem entsprechenden ECG-Entitätsfeld (z. B.$ioc.graph.entity.ip = $ip) zu verknüpfen. Filtern Sie die Entitätsvariable nach Bedrohungsattributen (z. B.
$ioc.graph.metadata.threat.category) und geben Sie im Abschnittmatch:ein Korrelationszeitfenster an (z. B.$ip over 5m).Klicken Sie auf Neue Regel speichern.
Retrohunt ausführen, um frühere Kompromittierungen zu erkennen
Threat Intelligence-Feeds enthalten oft Indikatoren, die von Angreifern Tage oder Wochen vor der Aufnahme des Feeds durch Ihre Organisation verwendet wurden. Während bei Live-Regeln neue eingehende Telemetriedaten ausgewertet werden, wird bei einer YARA-L-Retrohunt die Regellogik rückwirkend auf bis zu 30 Tage alte Sicherheitsereignisse angewendet:
- Wählen Sie im Navigationsmenü von Google SecOps Detection > Rules & Detections aus.
- Suchen Sie in der Regelliste nach Ihrer benutzerdefinierten Threat Intelligence-Regel.
- Klicken Sie auf , um weitere Regeloptionen aufzurufen, und wählen Sie YARA-L-Retrohunt aus.
- Wählen Sie im Dialogfeld YARA-L Retrohunt (YARA-L-Rückwärtssuche) die Start- und Endzeit für die historische Suche aus. Der ausgewählte Zeitraum muss mindestens so lang sein wie das in der Regel angegebene Abgleichszeitfenster.
- Klicken Sie auf Ausführen.
Öffnen Sie den Tab Erkennungen für die Regel, um den Fortschritt zu beobachten und frühere Übereinstimmungen zu prüfen.
Weitere Informationen finden Sie unter Regel für Verlaufsdaten ausführen.
Übereinstimmungen und Warnungen untersuchen
Prüfen Sie die Ergebnisse, die durch automatisches Abgleichen und benutzerdefinierte Korrelationsregeln in dedizierten Ansichten in Google SecOps generiert wurden.
Automatische Treffer auf der Seite „IOC-Übereinstimmungen“ prüfen
So untersuchen Sie automatische Indikatorübereinstimmungen:
- Wählen Sie im Navigationsmenü von Google SecOps Detection > IoC matches aus.
- Mit den Filtersteuerelementen können Sie die Ergebnisse nach Indikatortyp (Domains, IP-Adressen, Datei-Hashes oder URLs) eingrenzen.
- Klicken Sie auf eine beliebige Zeile mit einem Indikator, um den Bereich mit den Abgleichsdetails zu öffnen. Dort werden folgende Informationen angezeigt:
- Zugehörige interne Assets und Nutzernamen.
- Zeitstempel des ersten und letzten erkannten Ereignisses.
- Quelle des Threat Intelligence-Feeds und Zuweisung des Konfidenzniveaus.
- Klicken Sie auf In UDM Search ansehen, um alle Rohdaten-Telemetrieereignisse zu prüfen, die mit dem Indikator verknüpft sind.
Weitere Informationen finden Sie unter IoCs mit Applied Threat Intelligence ansehen.
Regeltreffer auf den Seiten „Benachrichtigungen“ und „Erkennungen“ priorisieren
Erkennungen, die durch benutzerdefinierte YARA-L-Regeln generiert werden, werden auf den Seiten Benachrichtigungen und Erkennungen angezeigt:
- Wählen Sie im Navigationsmenü von Google SecOps Detection > Alerts & IoCs aus, um priorisierte Regelbenachrichtigungen aufzurufen.
- Klicken Sie auf einen Benachrichtigungsnamen, um die Seite Benachrichtigungsdetails zu öffnen und die Tabelle Erkennungen zu prüfen. Dort werden korrelierte Ereigniszeilen und Attribute von ECG-Entitäten aufgeführt.
- Bei stillen Regeln (bei denen Benachrichtigungen deaktiviert sind) oder abgeschlossenen Retrohunts öffnen Sie Erkennung > Regeln und Erkennungen, klicken Sie auf den Regelnamen und sehen Sie sich den Tab Erkennungen an.
Benutzerdefinierte Indikatoren mit dem Emerging Threats Center in Beziehung setzen
Sie können auch das Emerging Threats Center verwenden, um zu untersuchen, wie Ihre benutzerdefinierten IoC-Übereinstimmungen mit umfassenderen Kampagnen von Angreifern und Malware-Familien zusammenhängen:
- Wählen Sie im Navigationsmenü von Google SecOps Detection > Emerging Threats aus.
- Prüfen Sie aktive Bedrohungskampagnen und ‑hinweise und wechseln Sie zur UDM-Suche, um zu prüfen, ob sich Indikatoren aus Ihren benutzerdefinierten Threat-Feeds mit beobachteten Kampagnenaktivitäten überschneiden.
Weitere Informationen finden Sie unter Emerging Threats Center – Übersicht.
Zugriff auf erweiterte Assets und Referenzen
Verwenden Sie die folgenden YARA-L 2.0-Snippets und Referenzressourcen, wenn Sie benutzerdefinierte Regeln für Threat Intelligence erstellen.
Ausgehende Netzwerkverbindung, die einer schädlichen IP-Adresse entspricht
Bei dieser Regel werden ausgehende NETWORK_CONNECTION-Ereignisse mit aktiven IP-Indikatoren im ECG in Beziehung gesetzt:
rule custom_ioc_network_connection {
meta:
author = "Security Operations"
description = "Detects connections to IPs matching custom threat intel"
severity = "HIGH"
priority = "HIGH"
events:
$net.metadata.event_type = "NETWORK_CONNECTION"
$net.target.ip = $ip
$ioc.graph.entity.ip = $ip
$ioc.graph.metadata.threat.category = "SUSPICIOUS_NETWORK"
match:
$ip over 5m
outcome:
$risk_score = max(85)
$threat_name = array_distinct($ioc.graph.metadata.threat.threat_name)
$source_feed = array_distinct($ioc.graph.metadata.source_product)
$principal_hostname = array_distinct($net.principal.asset.hostname)
condition:
$net and $ioc
}
DNS-Abfrage, die einer schädlichen Domain entspricht
Mit dieser Regel werden NETWORK_DNS-Lookups für Domains erkannt, die in Ihren aufgenommenen Threat Feeds als schädlich gekennzeichnet sind:
rule custom_ioc_malicious_domain_query {
meta:
author = "Security Operations"
description = "Detects DNS queries for domains matching threat intel"
severity = "MEDIUM"
priority = "MEDIUM"
events:
$dns.metadata.event_type = "NETWORK_DNS"
$dns.network.dns.questions.name = $domain
$ioc.graph.entity.hostname = $domain
match:
$domain over 10m
outcome:
$threat_name = array_distinct($ioc.graph.metadata.threat.threat_name)
$source_feed = array_distinct($ioc.graph.metadata.source_product)
$client_ip = array_distinct($dns.principal.ip)
condition:
$dns and $ioc
}
Prozessausführung, die einem schädlichen SHA-256-Datei-Hash entspricht
Diese Regel wird ausgelöst, wenn ein PROCESS_LAUNCH-Ereignis mit einem bekannten schädlichen SHA-256-Dateihash übereinstimmt, der im ECG gespeichert ist:
rule custom_ioc_malicious_file_execution {
meta:
author = "Security Operations"
description = "Detects process launches matching malicious file hashes"
severity = "CRITICAL"
priority = "HIGH"
events:
$process.metadata.event_type = "PROCESS_LAUNCH"
$process.target.process.file.sha256 = $sha256
$ioc.graph.entity.file.sha256 = $sha256
match:
$sha256 over 5m
outcome:
$threat_name = array_distinct($ioc.graph.metadata.threat.threat_name)
$file_path = array_distinct($process.target.process.file.full_path)
$hostname = array_distinct($process.principal.asset.hostname)
$user = array_distinct($process.principal.user.userid)
condition:
$process and $ioc
}
Community-Blogs und zusätzliche Ressourcen
Weitere Beispiele zum Erstellen von YARA-L-Regeln und zum Korrelieren benutzerdefinierter Feeds für Threat Intelligence finden Sie in den folgenden Google Cloud Community-Ressourcen:
- Regeln mit Ihrer eigenen Threat Intelligence erstellen (Teil 1)
- Regeln mit eigenen Threat Intelligence-Daten erstellen (Teil 2)
- YARA-L – Grundlagen
- YARA-L-Regelvariablen
- YARA-L-Operatoren und ‑Modifikatoren
- Einzelereignisregel mit einem regulären Ausdruck erstellen
- Regel für mehrere Ereignisse erstellen: Ereignisse verknüpfen
- Navigation im Regeleditor
Fehlerbehebung
In diesem Abschnitt erfahren Sie, wie Sie Leistungserwartungen verwalten und häufige Probleme beheben können, wenn Sie Threat Intelligence-Feeds einbinden und Korrelationsregeln erstellen.
Latenz, Dienstkontingent und Limits
- Aufnahme und UDM-Suchindexierung: Neu aufgenommene Indikatoren werden in der Regel innerhalb von 2 bis 5 Minuten in der UDM-Suche angezeigt. Warten Sie nach der Aufnahme des Feeds mindestens 5 Minuten, bevor Sie mit der Fehlerbehebung bei fehlenden Datensätzen für Rechtssubjekte beginnen.
- Latenz beim automatischen IoC-Abgleich: Sobald ein Indikator im ECG angezeigt wird, werden Übereinstimmungen mit eingehenden Streamingereignissen innerhalb von 5 bis 15 Minuten auf der Seite IoC-Übereinstimmungen angezeigt. Der rückwirkende Batch-Abgleich mit historischen Ereignissen dauert in der Regel 1 bis 4 Stunden (bis zu 24 Stunden für die vollständige historische Korrelation).
- Korrelationszeitraum für den Entity Context Graph: Beim automatischen IoC-Abgleich und bei YARA-L-Korrelationsregeln werden Indikatoren nur innerhalb des aktiven
metadata.interval-Zeitraums ausgewertet. Bei Indikatoren mit abgelaufenenend_time-Werten werden keine Übereinstimmungen generiert. - RetroHunt-Suchzeitraum: Bei YARA-L-RetroHunts werden pro Ausführung bis zu 30 Tage an Telemetriedaten aus dem Verlauf gescannt. Die Dauer hängt von der Komplexität der Regel und der Verfügbarkeit von Systemressourcen ab.
Fehlerbehebung
In dieser Tabelle finden Sie Informationen zur Diagnose und Behebung von Problemen bei der Einrichtung von Threat Intelligence und beim Erstellen von Erkennungsregeln.
| Problem | Problembeschreibung | Korrigieren |
|---|---|---|
| Nicht geparste IoC-Logs | Im Feedstatus werden eingehende Daten angezeigt, aber Logs können nicht in UDM-Entitäten geparst werden. | Prüfen Sie, ob der Feed-Log-Typ mit Ihrem Parser übereinstimmt (z. B. STIX, MISP_IOC oder CSV_CUSTOM_IOC). Suchen Sie im Dashboard Datenaufnahme nach Fehlern im Rohschema. |
| Fehlende UDM-Suchergebnisse | Indikatorprotokolle werden ohne Fehler geparst, aber bei der UDM-Suche werden keine Entitätsdatensätze zurückgegeben. | Prüfen Sie, ob Ihre Abfrage auf graph.entity.*-Felder (z. B. graph.entity.ip) und nicht auf udm.principal.*-Ereignisfelder ausgerichtet ist. |
| Regel wird bei bekanntem Indikator nicht ausgelöst | Sowohl das Ereignis als auch der Indikator sind in der UDM-Suche vorhanden, aber die YARA-L-Regel liefert keine Erkennungen. | Prüfen Sie, ob metadata.interval.start_time und metadata.interval.end_time im Indikator den Zeitstempel des Ereignisses einschließen. |
| Warnung vor Überschwemmung während der Rückwärtssuche | Durch das Ausführen einer Retrohunt werden Hunderte von doppelten SOAR-Fällen und ‑Benachrichtigungen erstellt. | Deaktivieren Sie die Benachrichtigungsfunktion der Regel, bevor Sie einen Retrohunt starten. Prüfen Sie die erkannten Ereignisse auf der Seite Erkannte Ereignisse, bevor Sie Live-Benachrichtigungen wieder aktivieren. |
| Hohe Anzahl an Fehlalarmen | Rauschanfällige Indikatoren lösen Erkennungen auf harmlosen internen Scannern oder Administratorhosts aus. | Fügen Sie Ihrer Regel einen Ausschluss für die Referenzliste hinzu (z. B. not $net.principal.ip in %benign_scanner_ips) und fordern Sie den Kontext für Verhaltensereignisse an. |
Validierung und Tests
Bevor Sie eine benutzerdefinierte Regel für die Bedrohungsanalyse im Live-Benachrichtigungsmodus aktivieren, sollten Sie die Logik mit der integrierten Funktion Regel testen überprüfen:
- Öffnen Sie Erkennung > Regeln und Erkennungen und klicken Sie auf die gewünschte Regel, um den Regeleditor zu öffnen.
- Klicken Sie im unteren Bereich auf Regel testen, um die Regel anhand von aktuellen historischen Ereignisdaten und aktiven ECG-Entitäten zu testen, ohne Warnungen oder SOAR-Vorgänge zu generieren.
- Prüfen Sie die zurückgegebenen Testerkennungen, um zu bestätigen, dass
outcome-Variablen (z. B.$threat_nameund$source_feed) wie erwartet ausgefüllt werden.
Nächste Schritte
- Weitere Informationen zum Kontext von Entitäten in der Suche
- Weitere Informationen finden Sie unter Erste Schritte mit YARA-L und Einzel- und Mehrfachereignisregeln in YARA-L.
- Von Applied Threat Intelligence kuratierte Erkennungen
Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten