Risikoanalysen für UEBA

Unterstützt in:

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.

Netzwerkverkehrsanalyse

  • 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 wurde kürzlich eine erhebliche Datenmenge von einer Geräteentität hoch- und heruntergeladen.
  • Anomalous Inbound Bytes by User: Im Vergleich zur bisherigen Nutzung wurde kürzlich eine erhebliche Datenmenge von einer einzelnen Nutzerentität heruntergeladen.
  • Anomalous Total Bytes by User: Im Vergleich zur bisherigen Nutzung wurde kürzlich eine erhebliche Datenmenge von einer Nutzerentität 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.

Auf Peer-Gruppen basierende Erkennungen

  • Anomalous or Excessive Logins for a Newly Created User: Anomale oder übermäßige Authentifizierungsaktivität für einen kürzlich erstellten Nutzer. Hierbei 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. Hierbei 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. Bei diesen Ereignissen ist das UDM-Feld security_result.action auf BLOCK gesetzt.

Auf Schutz vor Datenverlust basierende Erkennungen

  • 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. Hierbei 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, erheben Sie Logdaten aus Azure AD Directory Audit (AZURE_AD_AUDIT) oder Windows Event (WINEVTLOG).

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 (z. B. USER_LOGIN oder PROCESS_LAUNCH), die von der Erkennungs-Engine verwendet werden.

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

Netzwerkverkehrsanalyse

Wenn Sie einen dieser Regelsätze verwenden möchten, erheben Sie Logdaten, 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).

Auf Peer-Gruppen basierende Erkennungen

Wenn Sie einen dieser Regelsätze verwenden möchten, erheben Sie Logdaten aus Azure AD Directory Audit (AZURE_AD_AUDIT) oder Windows Event (WINEVTLOG).

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, erheben Sie Logdaten aus Azure AD Directory Audit (AZURE_AD_AUDIT) oder Windows Event (WINEVTLOG).

Regelsatz „Excessive Alerts by User“

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

Auf Schutz vor Datenverlust basierende Erkennungen

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

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

Warnungen optimieren, die von Regelsätzen 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 Match-Abschnitts 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 Risikozeiträume für Regeln zur Risikobewertung von Entitäten sind 24 Stunden oder 7 Tage (86.400 bzw. 604.800 Sekunden). Wenn Sie die Größe des Risikozeitraums nicht in die Regel aufnehmen, gibt die Regel ungenaue Ergebnisse zurück.

Daten zur Risikobewertung von Entitäten werden getrennt von Kontextdaten zu Entitäten 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