Risikoanalysen für UEBA
In diesem Dokument finden Sie eine Übersicht über die Regelsätze in der Kategorie „Risikoanalysen für UEBA“, die erforderlichen Daten und die Konfiguration, mit der Sie die von den einzelnen Regelsätzen generierten Warnungen optimieren können. Mithilfe dieser Regelsätze lassen sich Bedrohungen erkennen, indem die unterstützten Logquellen ausgewertet werden.
Beschreibungen der Regelsätze
Die folgenden Regelsätze sind in der Kategorie „Risikoanalysen für UEBA“ verfügbar und nach der Art der erkannten Muster gruppiert:
Authentifizierung
- New Login by User to Device: Ein Nutzer hat sich auf einem neuen Gerät angemeldet.
- Anomalous Authentication Events by User: Für eine einzelne Nutzerentität wurden im Vergleich zur bisherigen Nutzung kürzlich anomale Authentifizierungsereignisse aufgezeichnet.
- Fehlgeschlagene Authentifizierungen nach Gerät: Für eine einzelne Geräteentität wurden im Vergleich zur bisherigen Nutzung kürzlich viele fehlgeschlagene Anmeldeversuche aufgezeichnet.
- Failed Authentications by User: Für eine einzelne Nutzerentität wurden im Vergleich zur bisherigen Nutzung kürzlich viele fehlgeschlagene Anmeldeversuche aufgezeichnet.
Analyse des Netzwerkverkehrs
- Anomalous Inbound Bytes by Device: Im Vergleich zur bisherigen Nutzung wurde kürzlich eine erhebliche Datenmenge auf eine einzelne Geräteentität hochgeladen.
- Anomalous Outbound Bytes by Device: Im Vergleich zur bisherigen Nutzung wurde kürzlich eine erhebliche Datenmenge von einer einzelnen Geräteentität heruntergeladen.
- Anomalous Total Bytes by Device: Im Vergleich zur bisherigen Nutzung hat eine Geräteentität kürzlich eine erhebliche Datenmenge hoch- und heruntergeladen.
- Anomalous Inbound Bytes by User: Im Vergleich zur bisherigen Nutzung hat eine einzelne Nutzerentität kürzlich eine erhebliche Datenmenge heruntergeladen.
- Anomalous Total Bytes by User: Im Vergleich zur bisherigen Nutzung hat eine Nutzerentität kürzlich eine erhebliche Datenmenge hoch- und heruntergeladen.
- Brute Force then Successful Login by User: Für eine einzelne Nutzerentität von einer IP-Adresse wurden mehrere fehlgeschlagene Authentifizierungsversuche für eine bestimmte Anwendung aufgezeichnet, bevor die Anmeldung erfolgreich war.
Erkennungen auf Grundlage von Benchmarking-Gruppen
Anomalous or Excessive Logins for a Newly Created User: Anomale oder übermäßige Authentifizierungsaktivität für einen kürzlich erstellten Nutzer. Dabei wird die Erstellungszeit aus AD-Kontextdaten verwendet.
Anomale oder übermäßige verdächtige Aktionen für einen neu erstellten Nutzer: anomale oder übermäßige Aktivität (einschließlich, aber nicht beschränkt auf HTTP-Telemetrie, Prozessausführung und Gruppenänderung) für einen kürzlich erstellten Nutzer. Dabei wird die Erstellungszeit aus AD-Kontextdaten verwendet.
Verdächtige Aktionen
- Excessive Account Creation by Device: Eine Geräteentität hat mehrere neue Nutzerkonten erstellt.
- Excessive Alerts by User: Für eine Nutzerentität wurde eine große Anzahl von Sicherheitswarnungen von einem Antivirenprogramm
oder einem Endpunktgerät gemeldet (z. B. Verbindung wurde blockiert, Malware wurde erkannt)
. Das war viel mehr als in der Vergangenheit.
Das sind Ereignisse, bei denen das UDM-Feld
security_result.actionaufBLOCKgesetzt ist.
Erkennungen auf Grundlage des Schutzes vor Datenverlust
- Anomalous or Excessive Processes with Data Exfiltration Capabilities: Anomale oder übermäßige Aktivität für Prozesse, die mit Funktionen zur Daten-Exfiltration verknüpft sind, z. B. Keylogger, Screenshots und Remotezugriff. Dabei wird die Dateimetadatenanreicherung von VirusTotal verwendet.
Erforderliche Daten für die Kategorie „Risikoanalysen für UEBA“
In diesem Abschnitt werden die Daten beschrieben, die für die einzelnen Regelsatzkategorien erforderlich sind, um eine optimale Leistung zu erzielen. UEBA-Erkennungen sind zwar so konzipiert, dass sie mit allen unterstützten Standard parsern funktionieren, aber die Verwendung der folgenden spezifischen Datentypen maximiert ihren Nutzen. Eine vollständige Liste der unterstützten Standardparser finden Sie unter Unterstützte Logtypen und Standardparser.
Authentifizierung
Wenn Sie einen dieser Regelsätze verwenden möchten, müssen Sie Logdaten aus Azure AD Directory Audit (AZURE_AD_AUDIT) oder Windows Event (WINEVTLOG) erheben.
Für WINEVTLOG müssen Sie die Datenerhebungskonfiguration so konfigurieren, dass die folgenden Windows-Event IDs im Ereignisprotokoll Security im Channel enthalten sind.
Diese Ereignisse werden direkt den Event types zugeordnet, die von der Erkennungs-Engine verwendet werden (z. B. USER_LOGIN oder PROCESS_LAUNCH).
Anforderungen an Windows-Ereignis-IDs
| Ereignistyp | Windows-Ereignis-ID |
|---|---|
| USER_LOGIN | 529, 4624, 4625, 4626, 4648, 4672, 4768, 4769, 4770, 4771, 4777, 4820, 4821, 4964 |
| USER_CREATION | 4720 |
| NETWORK_CONNECTION | 4096, 4097, 4321, 5156, 5632, 5633, 5157 |
| GROUP_MODIFICATION | 4728, 4729, 4732, 4733, 4735, 4737, 4745, 4746, 4747, 4750, 4751, 4752, 4755, 4756, 4757, 4760, 4761, 4762, 4764, 4784, 4785, 4786, 4787, 4788, 4791 |
| PROCESS_LAUNCH | 4688 |
| PROCESS_OPEN | 4663, 4670, 4691, 8002 |
Analyse des Netzwerkverkehrs
Wenn Sie einen dieser Regelsätze verwenden möchten, müssen Sie Logdaten erheben, die Netzwerkaktivitäten erfassen.
Zum Beispiel von Geräten wie FortiGate (FORTINET_FIREWALL), Check Point (CHECKPOINT_FIREWALL), Zscaler (ZSCALER_WEBPROXY), CrowdStrike Falcon (CS_EDR) oder Carbon Black (CB_EDR).
Erkennungen auf Grundlage von Benchmarking-Gruppen
Wenn Sie einen dieser Regelsätze verwenden möchten, müssen Sie Logdaten aus Azure AD Directory Audit (AZURE_AD_AUDIT) oder Windows Event (WINEVTLOG) erheben.
Verdächtige Aktionen
Die Regelsätze in dieser Gruppe verwenden jeweils einen anderen Datentyp.
Regelsatz „Excessive Account Creation by Device“
Wenn Sie diesen Regelsatz verwenden möchten, müssen Sie Logdaten aus Azure AD Directory Audit (AZURE_AD_AUDIT) oder Windows Event (WINEVTLOG) erheben.
Regelsatz „Excessive Alerts by User“
Wenn Sie diesen Regelsatz verwenden möchten, müssen Sie Logdaten erheben, die Endpunktaktivitäten oder Audit-Daten erfassen, z. B. die von CrowdStrike Falcon (CS_EDR), Carbon Black (CB_EDR) oder Azure AD Directory Audit (AZURE_AD_AUDIT) aufgezeichnet wurden.
Erkennungen auf Grundlage des Schutzes vor Datenverlust
Wenn Sie einen dieser Regelsätze verwenden möchten, müssen Sie Logdaten erheben, die Prozess- und Dateiaktivitäten erfassen, z. B. die von CrowdStrike Falcon (CS_EDR), Carbon Black (CB_EDR) oder SentinelOne EDR (SENTINEL_EDR) aufgezeichnet wurden.
Feldabhängigkeiten
In diesem Abschnitt werden die Messwerte und Dimensionsfelder beschrieben, die von Google SecOps UEBA-Regeln verwendet werden.
Messwertabhängigkeiten
In der folgenden Tabelle sind die Messwerte und die entsprechenden UDM-Suchanfragen aufgeführt, die die Ereignisse definieren, die zu den einzelnen Messwerten beitragen.
| Messwert | UDM-Suchanfrage für Ereignisse, die zum Messwert beitragen |
|---|---|
AUTH_ATTEMPTS_FAIL |
metadata.event_type = "USER_LOGIN" |
AUTH_ATTEMPTS_SUCCESS |
metadata.event_type = "USER_LOGIN" |
AUTH_ATTEMPTS_TOTAL |
metadata.event_type = "USER_LOGIN" |
DNS_BYTES_OUTBOUND |
network.sent_bytes > 0 |
DNS_QUERIES_FAIL |
network.dns.id > 0 |
DNS_QUERIES_SUCCESS |
network.dns.id > 0 |
DNS_QUERIES_TOTAL |
network.dns.id > 0 |
FILE_EXECUTIONS_FAIL |
metadata.event_type = "PROCESS_LAUNCH" |
FILE_EXECUTIONS_SUCCESS |
metadata.event_type = "PROCESS_LAUNCH" |
FILE_EXECUTIONS_TOTAL |
metadata.event_type = "PROCESS_LAUNCH" |
HTTP_QUERIES_FAIL |
network.http.method != "" |
HTTP_QUERIES_SUCCESS |
network.http.method != "" |
HTTP_QUERIES_TOTAL |
network.http.method != "" |
NETWORK_BYTES_INBOUND |
network.received_bytes > 0 |
NETWORK_BYTES_OUTBOUND |
network.sent_bytes > 0 |
NETWORK_BYTES_TOTAL |
(network.received_bytes > 0 AND network.received_bytes < 1000000000000000) |
NETWORK_FLOWS_INBOUND |
network.received_bytes > 0 |
NETWORK_FLOWS_OUTBOUND |
network.sent_bytes > 0 |
NETWORK_FLOWS_TOTAL |
(network.received_bytes > 0 AND network.received_bytes < 1000000000000000) |
RESOURCE_READ_FAIL |
(metadata.event_type = "FILE_OPEN" OR metadata.event_type = "RESOURCE_READ") |
RESOURCE_READ_SUCCESS |
(metadata.event_type = "FILE_OPEN" OR metadata.event_type = "RESOURCE_READ") |
RESOURCE_READ_TOTAL |
(metadata.event_type = "FILE_OPEN" OR metadata.event_type = "RESOURCE_READ") |
RESOURCE_WRITTEN_FAIL |
(metadata.event_type = "FILE_CREATION" OR metadata.event_type = "RESOURCE_CREATION") |
RESOURCE_WRITTEN_SUCCESS |
(metadata.event_type = "FILE_CREATION" OR metadata.event_type = "RESOURCE_CREATION") |
RESOURCE_WRITTEN_TOTAL |
(metadata.event_type = "FILE_CREATION" OR metadata.event_type = "RESOURCE_CREATION") |
Dimensionsabhängigkeiten
In der folgenden Tabelle sind die Dimensionen und die entsprechenden UDM-Feldoptionen aufgeführt, die zum Filtern oder Gruppieren verfügbar sind.
| Dimension | Feldoptionen |
|---|---|
| Hauptgerät | principal.asset.asset_idprincipal.asset.hostnameprincipal.asset.ipprincipal.asset.macprincipal.asset.product_object_id |
| Zielgerät | target.asset.asset_idtarget.asset.hostnametarget.asset.iptarget.asset.mactarget.asset.product_object_id |
| Hauptnutzer | principal.user.email_addressesprincipal.user.employee_idprincipal.user.product_object_idprincipal.user.useridprincipal.user.windows_sid |
| Zielnutzer | target.user.email_addressestarget.user.employee_idtarget.user.product_object_idtarget.user.useridtarget.user.windows_sid |
| Zieldienst | target.application |
| Ziel-IP | target.ip |
| Pfad der Hauptprozessdatei | principal.process.file.full_path |
| Hash der Hauptprozessdatei | principal.process.file.sha256 |
| Hash der Hauptdatei | principal.file.sha256 |
| Hauptland | principal.ip_geo_artifact.location.country_or_region |
| Sicherheitskategorie | security_result.category |
| Name der Hauptnetzwerkorganisation | principal.ip_geo_artifact.network.organization_name |
| Name der Zielnetzwerkorganisation | target.ip_geo_artifact.network.organization_name |
| Hash des Clientzertifikats | network.tls.client.certificate.sha256 |
| DNS-Abfragetyp | network.dns.questions.type |
| DNS-Domain | network.dns_domain |
| HTTP-User-Agent | network.http.user_agent |
| Ereignistyp | metadata.event_type |
| Betriebssystem | principal.platform |
Warnungen optimieren, die von Regelsätzen in dieser Kategorie zurückgegeben werden
Sie können die Anzahl der Erkennungen, die von einer Regel oder einem Regelsatz generiert werden, mithilfe von Regelausschlüssen reduzieren.
Ein Regelausschluss definiert die Kriterien, die verwendet werden, um ein Ereignis von der Auswertung durch den Regelsatz oder durch bestimmte Regeln im Regelsatz auszuschließen. Erstellen Sie einen oder mehrere Regelausschlüsse, um die Anzahl der Erkennungen zu reduzieren. Informationen dazu finden Sie unter Regelausschlüsse konfigurieren.
Beispiel für eine Regel für die Kategorie „Risikoanalysen für UEBA“
Im folgenden Beispiel wird gezeigt, wie Sie eine Regel erstellen, um Erkennungen für jeden Entitätshostnamen zu generieren, dessen Risikobewertung höher als 100 ist:
rule EntityRiskScore {
meta:
events:
$e1.principal.hostname != ""
$e1.principal.hostname = $hostname
$e2.graph.entity.hostname = $hostname
$e2.graph.risk_score.risk_window_size.seconds = 86400 // 24 hours
$e2.graph.risk_score.risk_score >= 100
// Run deduplication across the risk score.
$rscore = $e2.graph.risk_score.risk_score
match:
// Dedup on hostname and risk score across a 4 hour window.
$hostname, $rscore over 4h
outcome:
// Force these risk score based rules to have a risk score of zero to
// prevent self feedback loops.
$risk_score = 0
condition:
$e1 and $e2
}
Diese Beispielregel führt auch eine Selbstdeduplizierung mithilfe des Übereinstimmungsabschnitts durch. Wenn eine Regelerkennung ausgelöst werden könnte, der Hostname und die Risikobewertung aber innerhalb von vier Stunden unverändert bleiben, werden keine neuen Erkennungen erstellt.
Die einzigen möglichen Risikofenster für Regeln zur Risikobewertung von Entitäten sind entweder 24 Stunden oder 7 Tage (86.400 bzw. 604.800 Sekunden). Wenn Sie die Größe des Risikofensters nicht in die Regel aufnehmen, gibt die Regel ungenaue Ergebnisse zurück.
Daten zur Risikobewertung von Entitäten werden getrennt von Entitätskontextdaten gespeichert. Wenn Sie beide in einer Regel verwenden möchten, muss die Regel zwei separate Entitätsereignisse haben, eines für den Entitätskontext und eines für die Risikobewertung der Entität, wie im folgenden Beispiel gezeigt:
rule EntityContextAndRiskScore {
meta:
events:
$log_in.metadata.event_type = "USER_LOGIN"
$log_in.principal.hostname = $host
$context.graph.entity.hostname = $host
$context.graph.metadata.entity_type = "ASSET"
$risk_score.graph.entity.hostname = $host
$risk_score.graph.risk_score.risk_window_size.seconds = 604800
match:
$host over 2m
outcome:
$entity_risk_score = max($risk_score.graph.risk_score.normalized_risk_score)
condition:
$log_in and $context and $risk_score and $entity_risk_score > 100
}
Nächste Schritte
Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten