Risikoanalysen für UEBA

Unterstützt in:

Dieses Dokument bietet einen Überblick über die Regelsätze in der Kategorie „Risk Analytics for UEBA“, die erforderlichen Daten und die Konfiguration, mit der Sie die von den einzelnen Regelsätzen generierten Benachrichtigungen optimieren können. Mithilfe dieser Regelsätze lassen sich Bedrohungen erkennen, indem die unterstützten Logquellen ausgewertet werden.

Beschreibungen von Regelsätzen

Die folgenden Regelsätze sind in der Kategorie „Risikoanalyse für UEBA“ verfügbar und werden nach der Art der erkannten Muster gruppiert:

Authentifizierung

  • Neue Anmeldung des Nutzers auf dem Gerät: Ein Nutzer hat sich auf einem neuen Gerät angemeldet.
  • Anomale Authentifizierungsereignisse nach Nutzer: Bei einer einzelnen Nutzeridentität sind in letzter Zeit im Vergleich zur bisherigen Nutzung anomale Authentifizierungsereignisse aufgetreten.
  • Fehlgeschlagene Authentifizierungen nach Gerät: Bei einem Einzelgerät gab es in letzter Zeit im Vergleich zur bisherigen Nutzung viele fehlgeschlagene Anmeldeversuche.
  • Fehlgeschlagene Authentifizierungen nach Nutzer: Für eine Einzelnutzeridentität gab es in letzter Zeit im Vergleich zur bisherigen Nutzung viele fehlgeschlagene Anmeldeversuche.

Analyse des Netzwerkverkehrs

  • Anomale eingehende Byte nach Gerät: Im Vergleich zur bisherigen Nutzung wurde in letzter Zeit eine erhebliche Menge an Daten auf ein einzelnes Gerät hochgeladen.
  • Anomalous Outbound Bytes by Device (Anomale ausgehende Byte nach Gerät): Eine erhebliche Menge an Daten wurde in letzter Zeit von einer einzelnen Geräte-Entität heruntergeladen, verglichen mit der bisherigen Nutzung.
  • Anomale Gesamtzahl der Byte nach Gerät: Auf einem Geräte-Entity wurde im Vergleich zur bisherigen Nutzung in letzter Zeit eine erhebliche Menge an Daten hoch- und heruntergeladen.
  • Anomale eingehende Byte nach Nutzer: Eine Einzelnutzer-Einheit hat in letzter Zeit im Vergleich zur bisherigen Nutzung eine erhebliche Menge an Daten heruntergeladen.
  • Anomalous Total Bytes by User (Anomale Gesamtzahl der Byte pro Nutzer): Ein Nutzerkonto hat in letzter Zeit im Vergleich zur bisherigen Nutzung eine erhebliche Menge an Daten hoch- und heruntergeladen.
  • Brute-Force-Angriff, dann erfolgreiche Anmeldung durch Nutzer: Ein einzelner Nutzer von einer IP-Adresse hatte mehrere fehlgeschlagene Authentifizierungsversuche für eine bestimmte Anwendung, bevor er sich erfolgreich angemeldet hat.

Erkennungen basierend auf Benchmarking-Gruppen

  • Anomale oder übermäßige Anmeldungen für einen neu erstellten Nutzer: anomale oder übermäßige Authentifizierungsaktivitäten für einen neu erstellten Nutzer. Dazu wird die Erstellungszeit aus den Kontextdaten des Anzeigenkontexts verwendet.

  • Anomale oder übermäßige verdächtige Aktionen für einen neu erstellten Nutzer: Anomale oder übermäßige Aktivitäten (einschließlich, aber nicht beschränkt auf HTTP-Telemetrie, Prozessausführung und Gruppenänderung) für einen neu erstellten Nutzer. Hier wird die Erstellungszeit aus AD Context-Daten verwendet.

Verdächtige Aktionen

  • Übermäßige Kontoerstellung durch Gerät: Auf einem Gerät wurden mehrere neue Nutzerkonten erstellt.
  • Zu viele Benachrichtigungen pro Nutzer: Für eine Nutzeridentität wurde eine große Anzahl von Sicherheitsbenachrichtigungen von einem Antiviren- oder Endpunktgerät gemeldet (z. B. Verbindung wurde blockiert, Malware wurde erkannt), die deutlich über den bisherigen Mustern lag. Das sind Ereignisse, bei denen das UDM-Feld security_result.action auf BLOCK festgelegt ist.

Erkennungen auf Grundlage des Schutzes vor Datenverlust

  • Anomale oder übermäßige Prozesse mit Funktionen zur Daten-Exfiltration: Anomale oder übermäßige Aktivitäten für Prozesse, die mit Funktionen zur Daten-Exfiltration wie Keyloggern, Screenshots und Remotezugriff verbunden sind. Dazu werden Dateimetadaten von VirusTotal verwendet.

Erforderliche Daten für Risikoanalysen für die UEBA-Kategorie

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 für die Verwendung mit allen unterstützten Standard-Parsern konzipiert, 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 eines dieser Regelsätze verwenden möchten, müssen Sie Logdaten entweder aus Azure AD Directory Audit (AZURE_AD_AUDIT) oder Windows Event (WINEVTLOG) erfassen.

Für WINEVTLOG müssen Sie die Datenerhebungskonfiguration so konfigurieren, dass die folgenden Windows-Event IDs im Security-Ereignisprotokoll Channel enthalten sind. Diese Ereignisse werden direkt den von der Erkennungs-Engine verwendeten Event types zugeordnet, 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 eines dieser Regelsets verwenden möchten, müssen Sie Protokolldaten erfassen, in denen die Netzwerkaktivität aufgezeichnet wird. 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 basierend auf Benchmarking-Gruppen

Wenn Sie eines dieser Regelsätze verwenden möchten, müssen Sie Logdaten entweder aus Azure AD Directory Audit (AZURE_AD_AUDIT) oder Windows Event (WINEVTLOG) erfassen.

Verdächtige Aktionen

Die Regelsätze in dieser Gruppe verwenden jeweils einen anderen Datentyp.

Regelsatz „Zu viele Kontoerstellungen durch Gerät“

Wenn Sie diesen Regelsatz verwenden möchten, müssen Sie Logdaten entweder aus Azure AD Directory Audit (AZURE_AD_AUDIT) oder Windows Event (WINEVTLOG) erfassen.

Regelsatz „Zu viele Benachrichtigungen durch Nutzer“

Wenn Sie diesen Regelsatz verwenden möchten, müssen Sie Logdaten erfassen, die Endpunktaktivitäten oder Auditing-Daten erfassen, z. B. die von CrowdStrike Falcon (CS_EDR), Carbon Black (CB_EDR) oder Azure AD Directory Audit (AZURE_AD_AUDIT) aufgezeichnet werden.

Erkennungen auf Grundlage des Schutzes vor Datenverlust

Wenn Sie eines dieser Regelsätze verwenden möchten, müssen Sie Logdaten erfassen, in denen Prozess- und Dateiaktivitäten aufgezeichnet werden, z. B. von CrowdStrike Falcon (CS_EDR), Carbon Black (CB_EDR) oder SentinelOne EDR (SENTINEL_EDR).

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, mit denen die Ereignisse definiert werden, die zu den einzelnen Messwerten beitragen.

Messwert UDM-Suchanfrage für Ereignisse, die zum Messwert beitragen
AUTH_ATTEMPTS_FAIL metadata.event_type = "USER_LOGIN"
AND security_result.action != "UNKNOWN_ACTION"
AND security_result.action != "ALLOW"
AUTH_ATTEMPTS_SUCCESS metadata.event_type = "USER_LOGIN"
AND (security_result.action = "UNKNOWN_ACTION" OR security_result.action = "ALLOW")
AUTH_ATTEMPTS_TOTAL metadata.event_type = "USER_LOGIN"
AND security_result.action >= "UNKNOWN_ACTION"
DNS_BYTES_OUTBOUND network.sent_bytes > 0
AND (network.ip_protocol = "UDP" AND target.port = 53)
OR (network.ip_protocol = "TCP" AND (target.port = 53 OR target.port=3000))
DNS_QUERIES_FAIL network.dns.id > 0
AND network.dns.response_code != 0
DNS_QUERIES_SUCCESS network.dns.id > 0
AND network.dns.response_code = 0
DNS_QUERIES_TOTAL network.dns.id > 0
FILE_EXECUTIONS_FAIL metadata.event_type = "PROCESS_LAUNCH"
AND security_result.action != "ALLOW"
FILE_EXECUTIONS_SUCCESS metadata.event_type = "PROCESS_LAUNCH"
AND security_result.action = "ALLOW"
FILE_EXECUTIONS_TOTAL metadata.event_type = "PROCESS_LAUNCH"
HTTP_QUERIES_FAIL network.http.method != ""
AND (network.http.response_code >= 400 OR network.http.response_code = 0)
HTTP_QUERIES_SUCCESS network.http.method != ""
AND network.http.response_code < 400
HTTP_QUERIES_TOTAL network.http.method != ""
NETWORK_BYTES_INBOUND network.received_bytes > 0
AND network.received_bytes < 1000000000000000
NETWORK_BYTES_OUTBOUND network.sent_bytes > 0
AND network.sent_bytes < 1000000000000000
NETWORK_BYTES_TOTAL (network.received_bytes > 0 AND network.received_bytes < 1000000000000000)
OR (network.sent_bytes > 0 AND network.sent_bytes < 1000000000000000)
NETWORK_FLOWS_INBOUND network.received_bytes > 0
AND network.received_bytes < 1000000000000000
NETWORK_FLOWS_OUTBOUND network.sent_bytes > 0
AND network.sent_bytes < 1000000000000000
NETWORK_FLOWS_TOTAL (network.received_bytes > 0 AND network.received_bytes < 1000000000000000)
OR (network.sent_bytes > 0 AND network.sent_bytes < 1000000000000000)
RESOURCE_READ_FAIL (metadata.event_type = "FILE_OPEN" OR metadata.event_type = "RESOURCE_READ")
AND security_result.action != "UNKNOWN_ACTION"
AND security_result.action != "ALLOW"
RESOURCE_READ_SUCCESS (metadata.event_type = "FILE_OPEN" OR metadata.event_type = "RESOURCE_READ")
AND (security_result.action = "UNKNOWN_ACTION" OR security_result.action = "ALLOW")
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")
AND security_result.action != "UNKNOWN_ACTION"
AND security_result.action != "ALLOW"
RESOURCE_WRITTEN_SUCCESS (metadata.event_type = "FILE_CREATION" OR metadata.event_type = "RESOURCE_CREATION")
AND (security_result.action = "UNKNOWN_ACTION" OR security_result.action = "ALLOW")
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_id
principal.asset.hostname
principal.asset.ip
principal.asset.mac
principal.asset.product_object_id
Zielgerät target.asset.asset_id
target.asset.hostname
target.asset.ip
target.asset.mac
target.asset.product_object_id
Hauptnutzer principal.user.email_addresses
principal.user.employee_id
principal.user.product_object_id
principal.user.userid
principal.user.windows_sid
Zielnutzer target.user.email_addresses
target.user.employee_id
target.user.product_object_id
target.user.userid
target.user.windows_sid
Zieldienst target.application
Ziel-IP target.ip
Dateipfad des Hauptprozesses 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 anpassen, die von Regelsätzen in dieser Kategorie zurückgegeben werden

Sie können die Anzahl der Erkennungen, die durch eine Regel oder einen Regelsatz generiert werden, mithilfe von Regelausschlüssen reduzieren.

Mit einem Regelausschluss werden die Kriterien definiert, mit denen ein Ereignis aus der Auswertung durch den Regelsatz oder durch bestimmte Regeln im Regelsatz ausgeschlossen wird. Erstellen Sie einen oder mehrere Regelausschlüsse, um die Anzahl der erkannten Verstöße zu verringern. Weitere Informationen dazu finden Sie unter Regelausschlüsse konfigurieren.

Beispiel für eine Regel für Risk Analytics für die UEBA-Kategorie

Im folgenden Beispiel wird gezeigt, wie Sie eine Regel erstellen, um Erkennungen für jeden Entitätshostnamen zu generieren, dessen Risikobewertung größer 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 Abschnitts „match“ durch. Wenn eine Regel erkannt wird, der Hostname und der Risikowert aber innerhalb eines Zeitraums von vier Stunden unverändert bleiben, werden keine neuen Erkennungen erstellt.

Die einzigen möglichen Risikofenster für Regeln für den Entitätsrisikoscore 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, liefert die Regel ungenaue Ergebnisse.

Daten zum Risikowert von Einheiten werden getrennt von Kontextdaten zu Einheiten 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