Übersicht über Risikoanalysen für die UEBA-Kategorie

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. Mit diesen Regelsätzen lassen sich Bedrohungen in Google Cloud-Umgebungen mithilfe von Google Cloud -Daten erkennen.

Beschreibungen von Regelsätzen

Die folgenden Regelsätze sind in der Kategorie „Risk Analytics for UEBA“ verfügbar und werden nach der Art der erkannten Muster gruppiert:

Authentifizierung

  • Neue Anmeldung eines Nutzers auf einem Gerät: Ein Nutzer hat sich auf einem neuen Gerät angemeldet.
  • Anomale Authentifizierungsereignisse nach Nutzer: Für eine einzelne Nutzeridentität wurden in letzter Zeit im Vergleich zur bisherigen Nutzung anomale Authentifizierungsereignisse aufgezeichnet.
  • Fehlgeschlagene Authentifizierungen nach Gerät: Bei einer Einzelgeräte-Identität gab es in letzter Zeit im Vergleich zur bisherigen Nutzung viele fehlgeschlagene Anmeldeversuche.
  • Fehlgeschlagene Authentifizierungen nach Nutzer: Bei einem Einzelnutzerkonto gab es in letzter Zeit viele fehlgeschlagene Anmeldeversuche im Vergleich zur bisherigen Nutzung.

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.
  • Anomale ausgehende Byte nach Gerät: Im Vergleich zur bisherigen Nutzung wurde in letzter Zeit eine erhebliche Menge an Daten von einem einzelnen Gerät heruntergeladen.
  • 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 einzelne Nutzeridentität hat in letzter Zeit im Vergleich zur bisherigen Nutzung eine erhebliche Menge an Daten heruntergeladen.
  • Anomale Gesamtzahl der Byte pro Nutzer: Eine Nutzeridentität 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: Eine einzelne Nutzeridentität von einer IP-Adresse hatte mehrere fehlgeschlagene Authentifizierungsversuche für eine bestimmte Anwendung, bevor die Anmeldung erfolgreich war.

Erkennungen auf Grundlage von 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. Hier 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äten (einschließlich, aber nicht beschränkt auf HTTP-Telemetrie, Prozessausführung und Gruppenänderung) für einen neu erstellten Nutzer. Dazu wird die Erstellungszeit aus AD-Kontextdaten 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 viel höher war als in der Vergangenheit. Dies 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. Dabei werden Dateimetadaten von VirusTotal verwendet.

Erforderliche Daten für die UEBA-Kategorie von Risk Analytics

In diesem Abschnitt werden die Daten beschrieben, die für die einzelnen Regelgruppenkategorien 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 Regelsets verwenden möchten, müssen Sie Logdaten aus Azure AD Directory Audit (AZURE_AD_AUDIT) oder Windows Event (WINEVTLOG) erfassen.

Analyse des Netzwerkverkehrs

Wenn Sie eines dieser Regelsets verwenden möchten, müssen Sie Logdaten 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 auf Grundlage von Benchmarking-Gruppen

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

Verdächtige Aktionen

Für die Regelgruppen in dieser Gruppe wird jeweils ein anderer Datentyp verwendet.

Regelsatz „Zu viele Konten auf einem Gerät erstellt“

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

Regelsatz „Zu viele Benachrichtigungen pro Nutzer“

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

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).

Regelsätze in dieser Kategorie basieren auf Ereignissen mit den folgenden metadata.event_type-Werten: PROCESS_LAUNCH, PROCESS_OPEN, PROCESS_MODULE_LOAD.

Benachrichtigungen optimieren, die von Regelsätzen in dieser Kategorie zurückgegeben werden

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

Mit einem Regelausschluss werden die Kriterien definiert, anhand derer ein Ereignis nicht vom Regelsatz oder von bestimmten Regeln im Regelsatz ausgewertet wird. Erstellen Sie einen oder mehrere Regelausschlüsse, um die Anzahl der erkannten Verstöße zu reduzieren. 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
}

Mit dieser Beispielregel wird auch eine Selbstdeduplizierung mithilfe des Match-Abschnitts durchgeführt. 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, werden ungenaue Ergebnisse zurückgegeben.

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