Übersicht über Risikoanalysen für die Kategorie „UEBA“

Unterstützt in:

Dieses Dokument enthält einen Überblick über die Regelsätze in der Kategorie „Risikoanalyse für 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 können Sie anhand von Google Cloud -Daten Bedrohungen in Google Cloud-Umgebungen erkennen.

Beschreibungen von Regelsätzen

Die folgenden Regelsätze sind in der Kategorie „Risikoanalyse für UEBA“ verfügbar und 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.
  • Anomalie bei Authentifizierungsereignissen nach Nutzer: Für eine einzelne Nutzerentität wurden in letzter Zeit im Vergleich zur bisherigen Nutzung anormale Authentifizierungsereignisse erfasst.
  • Fehlgeschlagene Authentifizierungen nach Gerät: Bei einer Entität mit einem einzelnen Gerät gab es in letzter Zeit im Vergleich zur bisherigen Nutzung viele fehlgeschlagene Anmeldeversuche.
  • Fehlgeschlagene Authentifizierungen nach Nutzer: Eine Entität mit einem einzelnen Nutzer hatte in letzter Zeit im Vergleich zur bisherigen Nutzung viele fehlgeschlagene Anmeldeversuche.

Netzwerkverkehrsanalyse

  • Anormale eingehende Bytes nach Gerät: Im Vergleich zur bisherigen Nutzung wurde vor Kurzem eine erhebliche Menge an Daten auf eine einzelne Geräteentität hochgeladen.
  • Anormale ausgehende Bytes nach Gerät: Im Vergleich zur bisherigen Nutzung wurde vor Kurzem eine erhebliche Menge an Daten von einer einzelnen Geräteentität heruntergeladen.
  • Außergewöhnliche Gesamtzahl der Byte nach Gerät: Eine Geräteentität hat im Vergleich zur bisherigen Nutzung vor Kurzem eine erhebliche Menge an Daten hoch- und heruntergeladen.
  • Anormale eingehende Bytes nach Nutzer: Eine Entität mit einem einzelnen Nutzer hat im Vergleich zur bisherigen Nutzung vor Kurzem eine erhebliche Menge an Daten heruntergeladen.
  • Anomaler Gesamtwert der Bytes pro Nutzer: Eine Nutzerentität hat im Vergleich zur bisherigen Nutzung in letzter Zeit eine erhebliche Menge an Daten hoch- und heruntergeladen.
  • Brute-Force-Angriff und anschließende erfolgreiche Anmeldung des Nutzers: Ein einzelner Nutzer mit einer IP-Adresse hat mehrere fehlgeschlagene Authentifizierungsversuche bei einer bestimmten Anwendung unternommen, bevor er sich erfolgreich angemeldet hat.

Erkennungen auf Grundlage von Peer-Gruppen

  • Anormale oder übermäßige Anmeldungen für einen neu erstellten Nutzer: Anormale oder übermäßige Authentifizierungsaktivitäten für einen vor Kurzem erstellten Nutzer. Dabei wird die Erstellungszeit aus den AD-Kontextdaten verwendet.

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

Verdächtige Aktionen

  • Übermäßige Kontoerstellung durch Gerät: Eine Geräteentität hat mehrere neue Nutzerkonten erstellt.
  • Übermäßige Benachrichtigungen von Nutzern: Es wurden eine große Anzahl von Sicherheitswarnungen von einem Antivirenprogramm oder Endpunktgerät (z. B. Verbindung wurde blockiert, Malware wurde erkannt) für eine Nutzerentität gemeldet, die deutlich über den bisherigen Mustern lag. Das sind Ereignisse, bei denen das UDM-Feld security_result.action auf BLOCK festgelegt ist.

Auf dem Schutz vor Datenverlust basierende Erkennungen

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

Erforderliche Daten für die Risikoanalyse für die Kategorie „UEBA“

Im folgenden Abschnitt werden die Daten beschrieben, die für Regelsätze in jeder Kategorie erforderlich sind, um den größtmöglichen Nutzen zu erzielen. Eine Liste aller unterstützten Standardparser finden Sie unter Unterstützte Logtypen und Standardparser.

Authentifizierung

Wenn Sie eine dieser Regelgruppen verwenden möchten, erfassen Sie Protokolldaten entweder aus Azure AD-Verzeichnisaudits (AZURE_AD_AUDIT) oder Windows-Ereignissen (WINEVTLOG).

Netzwerkverkehrsanalyse

Wenn Sie eine dieser Regelsätze verwenden möchten, müssen Sie Protokolldaten erfassen, die Netzwerkaktivitäten erfassen. Beispielsweise 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 Peer-Gruppen

Wenn Sie eine dieser Regelgruppen verwenden möchten, erfassen Sie Protokolldaten entweder aus Azure AD-Verzeichnisaudits (AZURE_AD_AUDIT) oder Windows-Ereignissen (WINEVTLOG).

Verdächtige Aktionen

Für die Regelsätze in dieser Gruppe wird jeweils ein anderer Datentyp verwendet.

Regelsatz „Übermäßige Kontoerstellung nach Gerät“

Wenn Sie diesen Regelsatz verwenden möchten, erfassen Sie Protokolldaten entweder aus Azure AD-Verzeichnisaudits (AZURE_AD_AUDIT) oder Windows-Ereignissen (WINEVTLOG).

Zu viele Benachrichtigungen pro Nutzer

Wenn Sie diesen Regelsatz verwenden möchten, erfassen Sie Protokolldaten, die Endpunktaktivitäten oder Prüfdaten enthalten, z. B. von CrowdStrike Falcon (CS_EDR), Carbon Black (CB_EDR) oder Azure AD Directory Audit (AZURE_AD_AUDIT).

Auf dem Schutz vor Datenverlust basierende Erkennungen

Wenn Sie eines dieser Regelsätze verwenden möchten, erfassen Sie Protokolldaten, die Prozess- und Dateiaktivitäten erfassen, z. B. von CrowdStrike Falcon (CS_EDR), Carbon Black (CB_EDR) oder SentinelOne EDR (SENTINEL_EDR).

Regelsätze in dieser Kategorie hängen von Ereignissen mit den folgenden metadata.event_type-Werten ab: PROCESS_LAUNCH, PROCESS_OPEN, PROCESS_MODULE_LOAD.

Tuning-Benachrichtigungen, die von Regelsätzen dieser Kategorie zurückgegeben werden

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

Mit einem Regelausschluss werden die Kriterien definiert, mit denen ein Ereignis von der Auswertung durch den Regelsatz oder durch bestimmte Regeln im Regelsatz ausgeschlossen wird. Erstellen Sie eine oder mehrere Regelausschlüsse, um die Anzahl der erkannten Probleme zu reduzieren. Weitere Informationen dazu finden Sie unter Regelausschlüsse konfigurieren.

Beispiel für eine Regel für die Risikoanalyse für die Kategorie „UEBA“

Im folgenden Beispiel wird gezeigt, wie Sie eine Regel erstellen, um Erkennungen für jeden Entitäts-Hostnamen zu generieren, dessen Risikowert über 100 liegt:

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
}

In dieser Beispielregel wird auch eine Deduplizierung mithilfe des Abgleichsabschnitts durchgeführt. Wenn eine Regelerkennung ausgelöst werden könnte, 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ätsrisikowert sind 24 Stunden oder 7 Tage (entsprechend 86.400 oder 604.800 Sekunden). Wenn Sie die Größe des Risikofensters nicht in die Regel aufnehmen, werden fehlerhafte Ergebnisse zurückgegeben.

Daten zum Risikowert von Entitäten werden getrennt von Daten zum Entitätskontext 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 den Entitätsrisikowert, 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