Cisco Identity Intelligence-Logs erfassen

Unterstützt in:

In diesem Dokument wird beschrieben, wie Sie Cisco Identity Intelligence so konfigurieren, dass Logs über Webhooks an Google Security Operations gesendet werden.

Cisco Identity Intelligence (früher Oort Security) ist eine Plattform zur Erkennung und Reaktion auf Identitätsbedrohungen, die das Nutzerverhalten, Authentifizierungsmuster, die Gerätenutzung und Zugriffsberechtigungen bei Identitätsanbietern kontinuierlich überwacht. Es erkennt identitätsbasierte Bedrohungen, Fehlkonfigurationen und Compliance-Verstöße, indem es Nutzeraktivitäten, fehlgeschlagene Sicherheitsprüfungen, Vertrauenswürdigkeitswerte und riskantes Verhalten analysiert.

Hinweis

Folgende Voraussetzungen müssen erfüllt sein:

  • Eine Google SecOps-Instanz
  • Privilegierter Zugriff auf einen Cisco Identity Intelligence-Mandanten
  • Administratorberechtigungen zum Verwalten von Integrationen in Cisco Identity Intelligence
  • Zugriff auf die Google Cloud Console (zum Erstellen von API-Schlüsseln)

Webhook-Feed in Google SecOps erstellen

Feed erstellen

  1. Rufen Sie die SIEM-Einstellungen > Feeds auf.
  2. Klicken Sie auf Neuen Feed hinzufügen.
  3. Klicken Sie auf der nächsten Seite auf Einen einzelnen Feed konfigurieren.
  4. Geben Sie im Feld Feedname einen Namen für den Feed ein, z. B. Cisco Identity Intelligence Events.
  5. Wählen Sie Webhook als Quelltyp aus.
  6. Wählen Sie Cisco Identity Intelligence als Log type (Logtyp) aus.
  7. Klicken Sie auf Weiter.
  8. Geben Sie Werte für die folgenden Eingabeparameter an:
    • Trennzeichen für Aufteilung (optional): Geben Sie \n ein, um mehrzeilige Ereignisse aufzuteilen.
    • Asset-Namespace: Der Asset-Namespace
    • Labels für Datenaufnahme: Das Label, das auf die Ereignisse aus diesem Feed angewendet werden soll
  9. Klicken Sie auf Weiter.
  10. Prüfen Sie die neue Feedkonfiguration auf dem Bildschirm Abschließen und klicken Sie dann auf Senden.

Secret-Schlüssel generieren und speichern

Nachdem Sie den Feed erstellt haben, müssen Sie einen geheimen Schlüssel für die Authentifizierung generieren:

  1. Klicken Sie auf der Feed-Detailseite auf Secret Key generieren.
  2. In einem Dialogfeld wird der geheime Schlüssel angezeigt.
  3. Kopieren und speichern Sie den geheimen Schlüssel sicher.

Feed-Endpunkt-URL abrufen

  1. Rufen Sie den Tab Details des Feeds auf.
  2. Kopieren Sie im Abschnitt Endpoint Information (Endpunktinformationen) die Feed endpoint URL (Feed-Endpunkt-URL).

  3. Das URL-Format lautet:

    https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate

    oder

    https://<REGION>-malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate

  4. Speichern Sie diese URL für die nächsten Schritte.

  5. Klicken Sie auf Fertig.

Google Cloud API-Schlüssel erstellen

Für die Authentifizierung in Chronicle ist ein API-Schlüssel erforderlich. Erstellen Sie in der Google Cloud Console einen eingeschränkten API-Schlüssel.

API-Schlüssel erstellen

  1. Rufen Sie die Seite „Anmeldedaten“ in der Google Cloud Console auf.
  2. Wählen Sie Ihr Projekt aus (das Projekt, das mit Ihrer Chronicle-Instanz verknüpft ist).
  3. Klicken Sie auf Anmeldedaten erstellen > API-Schlüssel.
  4. Ein API-Schlüssel wird erstellt und in einem Dialogfeld angezeigt.
  5. Klicken Sie auf API-Schlüssel bearbeiten, um den Schlüssel einzuschränken.

API-Schlüssel einschränken

  1. Auf der Seite mit den API-Schlüssel-Einstellungen:
    • Name: Geben Sie einen aussagekräftigen Namen ein, z. B. Chronicle Webhook API Key.
  2. Gehen Sie unter API-Einschränkungen so vor:
    1. Wählen Sie Schlüssel einschränken aus.
    2. Suchen Sie im Drop-down-Menü APIs auswählen nach Google SecOps API (oder Chronicle API) und wählen Sie die API aus.
  3. Klicken Sie auf Speichern.
  4. Kopieren Sie den API-Schlüsselwert aus dem Feld API-Schlüssel oben auf der Seite.
  5. Speichern Sie den API-Schlüssel sicher.

Cisco Identity Intelligence-Webhook konfigurieren

Webhook-URL erstellen

  • Kombinieren Sie die Chronicle-Endpunkt-URL und den API-Schlüssel:

    <ENDPOINT_URL>?key=<API_KEY>&secret=<SECRET_KEY>

    • Beispiel:

      https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate?key=AIzaSyD...&secret=abcd1234...

Ersetzen Sie Folgendes:

  • <ENDPOINT_URL>: Die zuvor kopierte Chronicle-Feed-Endpunkt-URL
  • <API_KEY>: Der zuvor erstellte Google Cloud API-Schlüssel
  • <SECRET_KEY>: Der zuvor generierte geheime Schlüssel für Chronicle-Webhooks

Webhook-Benachrichtigungsziel in Cisco Identity Intelligence erstellen

  1. Melden Sie sich in Cisco Identity Intelligence an.
  2. Rufen Sie Integrationen auf.
  3. Klicken Sie auf Integration hinzufügen.
  4. Scrollen Sie nach unten zum Abschnitt Webhook.
  5. Klicken Sie auf Webhook-Ziel hinzufügen.
  6. Geben Sie die folgenden Konfigurationsdetails an:
    • Name: Geben Sie einen aussagekräftigen Namen ein, z. B. Chronicle SIEM Integration.
    • Webhook-URL: Fügen Sie die vollständige Endpunkt-URL mit API-Schlüssel und geheimem Schlüssel von oben ein.
    • Autorisierungstyp: Wählen Sie API-Schlüssel aus.
    • Name des API-Schlüssels: Geben Sie einen Schlüsselnamen ein (z. B. x-goog-chronicle-auth).
    • API-Schlüsselwert: Geben Sie den Google Cloud API-Schlüssel ein.
  7. Maximieren Sie den Bereich Invocation HTTP Parameters (HTTP-Parameter für Aufruf).
  8. Fügen Sie die folgenden Parameter mit dem Typ Header hinzu:
    • Schlüssel: Content-Type, Wert: application/json
    • Schlüssel: Accept, Wert: application/json
  9. Wählen Sie im Bereich Dieses Ziel verwenden für die Option Fehlgeschlagene Prüfung aus, um Benachrichtigungen zu erhalten, wenn bei Identitätsprüfungen fehlgeschlagene Ergebnisse erkannt werden.

  10. Klicken Sie auf Speichern.

Webhook-Verbindung testen

  1. Suchen Sie auf der Seite Integrationen nach dem von Ihnen erstellten Webhook-Benachrichtigungsziel.
  2. Klicken Sie rechts in der Zeile auf das Dreipunkt-Menü.
  3. Wählen Sie Konnektivität testen aus.
  4. Prüfen Sie, ob die Testnachricht erfolgreich zugestellt wurde.

Webhook für Identitätsüberprüfungen aktivieren

Nachdem Sie das Webhook-Benachrichtigungsziel erstellt haben, müssen Sie es für die spezifischen Identitätsüberprüfungen aktivieren, die Sie überwachen möchten.

  1. Rufen Sie in Cisco Identity Intelligence die gewünschte Detailseite Check auf.
  2. Klicken Sie oben rechts auf der Seite auf das Drop-down-Menü.
  3. Aktivieren Sie das Kästchen für das von Ihnen erstellte Webhook-Benachrichtigungsziel.

  4. Wiederholen Sie den Vorgang für jede Prüfung, die Sie an Google SecOps senden möchten.

Weitere Informationen finden Sie in der Dokumentation zu Cisco Identity Intelligence-Webhooks.

Referenz zu Authentifizierungsmethoden

Chronicle-Webhook-Feeds unterstützen mehrere Authentifizierungsmethoden. Wählen Sie die Methode aus, die von Ihrem Anbieter unterstützt wird.

Wenn Ihr Anbieter benutzerdefinierte HTTP-Header unterstützt, sollten Sie diese Methode für mehr Sicherheit verwenden.

  • Anfrageformat:

    POST <ENDPOINT_URL> HTTP/1.1
Content-Type: application/json
x-goog-chronicle-auth: <API_KEY>
x-chronicle-auth: <SECRET_KEY>

{
    "event": "data",
    "timestamp": "2025-01-15T10:30:00Z"
}

Vorteile:

  • API-Schlüssel und Secret sind in der URL nicht sichtbar
  • Sicherer (Header werden nicht in Webserver-Zugriffslogs protokolliert)
  • Bevorzugte Methode, wenn der Anbieter sie unterstützt

Methode 2: Abfrageparameter

Wenn Ihr Anbieter keine benutzerdefinierten Headern unterstützt, hängen Sie die Anmeldedaten an die URL an.

  • URL-Format:

    <ENDPOINT_URL>?key=<API_KEY>&secret=<SECRET_KEY>

  • Beispiel:

    https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate?key=AIzaSyD...&secret=abcd1234...

  • Anfrageformat:

    POST <ENDPOINT_URL>?key=<API_KEY>&secret=<SECRET_KEY> HTTP/1.1
Content-Type: application/json

{
    "event": "data",
    "timestamp": "2025-01-15T10:30:00Z"
}

Nachteile:

  • Anmeldedaten in der URL sichtbar
  • Möglicherweise in Webserver-Zugriffsprotokollen protokolliert
  • Weniger sicher als Header

Methode 3: Hybrid (URL + Header)

Bei einigen Konfigurationen wird der API-Schlüssel in der URL und der geheime Schlüssel im Header verwendet.

  • Anfrageformat:

    POST <ENDPOINT_URL>?key=<API_KEY> HTTP/1.1
Content-Type: application/json
x-chronicle-auth: <SECRET_KEY>

{
    "event": "data",
    "timestamp": "2025-01-15T10:30:00Z"
}

Namen von Authentifizierungsheadern

Chronicle akzeptiert die folgenden Headernamen für die Authentifizierung:

Für API-Schlüssel:

  • x-goog-chronicle-auth (empfohlen)
  • X-Goog-Chronicle-Auth (keine Unterscheidung zwischen Groß- und Kleinschreibung)

Geheimer Schlüssel

  • x-chronicle-auth (empfohlen)
  • X-Chronicle-Auth (keine Unterscheidung zwischen Groß- und Kleinschreibung)

Webhook-Limits und Best Practices

Anfragelimits

Limit Wert
Maximale Anfragengröße 4 MB
Maximale Abfragen pro Sekunde 15.000
Zeitlimit für Anfragen 30 Sekunden
Wiederholungsverhalten Automatisch mit exponentiellem Backoff

UDM-Zuordnungstabelle

Logfeld UDM-Zuordnung Logik
Konto account_label.value Wert direkt kopiert
Konto account_label.key Auf „Konto“ festgelegt
account_label security_result.detection_fields Mit „detection_fields“ zusammengeführt
additional_detaildescription.key additional_detaildescription.key Auf „detail description“ festgelegt
detaildescription additional_detaildescription.value.list_value.values Zusammengeführt aus „detaildescription“
additional_detaildescription event.idm.read_only_udm.additional.fields In „additional.fields“ zusammengeführt
additional_recommendedaction.key additional_recommendedaction.key Auf „empfohlene Maßnahme“ festgelegt
recommendedAction additional_recommendedaction.value.list_value.values Zusammengeführt aus „recommendedAction“
additional_recommendedaction event.idm.read_only_udm.additional.fields In „additional.fields“ zusammengeführt
data1 usersFailing_label Wert direkt kopiert
data.login login_label Wert direkt kopiert
detail-type security_result.summary Wert direkt kopiert
detail.id security_result.rule_id Wert direkt kopiert
detail.title security_result.rule_name Wert direkt kopiert
detail.severity security_result.severity Wert aus „detail.severity“, wenn er in [CRITICAL,ERROR,HIGH,INFORMATIONAL,LOW,MEDIUM] enthalten ist, andernfalls MEDIUM, wenn er moderat ist.
detaildescription value_array.string_value Wert direkt kopiert
detailsdata.key add_label.value, add_label.key Wert aus detailsdata.value, Schlüssel als „loginDetails %{index} details %{detailindex} %{detailsdata.key}“, wenn nicht failedSigninDetails oder ips
detailsdata.value add_label.value, add_label.key
detailsdata.key security_result.detection_fields „add_label“ zusammengeführt, wenn Bedingungen erfüllt
detailsdata.value security_result.detection_fields
field_.value security_result.detection_fields Zusammengeführt für verschiedene verschachtelte Felder in json_array (msg, ipInfo, asn, coordinates, first_event, second_event, locations) mit Schlüsseln wie „%{index} %{detailindex} %{index1} %{key}“ usw., mit Ausnahme von ipAddress, ip usw.
field_.key security_result.detection_fields
id metadata.product_log_id Wert direkt kopiert
login_label principal.user.email_addresses Zusammengeführt, wenn mit dem regulären Ausdruck für E‑Mail-Adressen übereinstimmt
msg.ipAddress principal.ip Zusammengeführt, wenn nicht leer
msg.first_event.ip_address principal.ip Zusammengeführt, wenn nicht leer
msg.second_event.ip_address principal.ip Zusammengeführt, wenn nicht leer
msg_travels_first_event_ip_address principal.ip Zusammengeführt, wenn nicht leer
msg_travels_second_event_ip_address principal.ip
recommendedAction value_array.string_value Wert direkt kopiert
security_result event.idm.read_only_udm.security_result Mit security_result zusammengeführt
source source_label.value Wert direkt kopiert
source source_label.key Auf „Quelle“ festgelegt
source_label event.idm.read_only_udm.src.labels In „src.labels“ zusammengeführt
Zeit @timestamp Geparsed mit Datumsfilter mit ISO8601, RFC 3339, yyyy-MM-ddTHH:mm:ss.SSSSSSZ
usersFailing_label principal.user.email_addresses Zusammengeführt, wenn mit dem regulären Ausdruck für E‑Mail-Adressen übereinstimmt
Version metadata.product_version Wert direkt kopiert
has_principal event.idm.read_only_udm.metadata.event_type Auf „STATUS_UPDATE“ festgelegt, wenn „has_principal“ auf „true“ gesetzt ist. Andernfalls „USER_UNCATEGORIZED“, wenn „has_user“ auf „true“ gesetzt ist. Andernfalls „GENERIC_EVENT“.
has_user event.idm.read_only_udm.metadata.event_type
metadata.product_name metadata.product_name Auf „OORT“ festgelegt
metadata.vendor_name metadata.vendor_name Auf „OORT“ festgelegt
detail.published event.idm.read_only_udm.metadata.collected_timestamp Aus dem Änderungsprotokoll zugeordnet
detail.login event.idm.read_only_udm.principal.user.userid Aus dem Änderungsprotokoll zugeordnet
detail.userTrustLevel event.idm.read_only_udm.principal.user.attribute.labels Aus dem Änderungsprotokoll zugeordnet
detail.login event.idm.read_only_udm.principal.user.user_display_name Aus dem Änderungsprotokoll zugeordnet
detail.checkTopics event.idm.read_only_udm.security_result.category_details Aus dem Änderungsprotokoll zugeordnet
region event.idm.read_only_udm.additional.fields Aus dem Änderungsprotokoll zugeordnet
detail.checkId event.idm.read_only_udm.security_result.detection_fields Aus dem Änderungsprotokoll zugeordnet
detail.checkScope event.idm.read_only_udm.security_result.detection_fields Aus dem Änderungsprotokoll zugeordnet
detail.frameworks event.idm.read_only_udm.security_result.detection_fields Aus dem Änderungsprotokoll zugeordnet
detail.explainabilityEventIds event.idm.read_only_udm.security_result.detection_fields Aus dem Änderungsprotokoll zugeordnet
data.value event.idm.read_only_udm.security_result.detection_fields Aus dem Änderungsprotokoll zugeordnet

Änderungsprotokoll

Änderungsprotokoll für diesen Parser ansehen

Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten