Thinkst Canary-Logs erfassen

Unterstützt in:

In diesem Dokument wird beschrieben, wie Sie Thinkst Canary-Logs erfassen, indem Sie einen Google Security Operations-Feed mit der Drittanbieter-API einrichten.

Thinkst Canary bietet täuschungsbasierte Bedrohungserkennung: Hardware-, virtuelle und Cloud-Canaries geben sich als echte Assets aus und Canarytokens fungieren als Stolperdrähte in Dateien, Anmeldedaten und URLs. Wenn ein Angreifer einen Canary berührt oder ein Token auslöst, wird in der Canary Console ein Vorfall aufgezeichnet. Der Feed ruft diese Vorfälle über die Console API ab.

Hinweis

Prüfen Sie, ob folgende Voraussetzungen erfüllt sind:

  • Eine Google SecOps-Instanz
  • Privilegierter Zugriff auf die Thinkst Canary Console

REST API in Thinkst Canary konfigurieren

  1. Melden Sie sich in der Thinkst Canary Console (https://<DOMAIN_HASH>.canary.tools) an.
  2. Klicken Sie rechts oben auf das Zahnradsymbol und wählen Sie Globale Einstellungen aus.
  3. Klicken Sie im Menü auf API.
  4. Wenn die API deaktiviert ist, klicken Sie auf API aktivieren.

  5. Verwenden Sie den vorhandenen Standard-API-Schlüssel oder klicken Sie auf + Neuen API-Schlüssel hinzufügen, um einen dedizierten Schlüssel zu erstellen:

    • API-Schlüsseltyp: Wählen Sie Nur lesen aus. Das reicht für die Logsammlung aus.
    • Hinweis: Geben Sie einen Namen für den Schlüssel ein, z. B. Google SecOps Integration.

  6. Kopieren Sie Folgendes und speichern Sie es an einem sicheren Ort:

    • Domain-Hash: Die Kennung Ihrer Console. Ihr API-Hostname ist <DOMAIN_HASH>.canary.tools.
    • Auth-Token: Der API-Schlüssel, der zur Authentifizierung von Anfragen verwendet wird.

Feed in Google SecOps konfigurieren, um Thinkst Canary-Logs aufzunehmen

  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. Thinkst Canary Logs.
  5. Wählen Sie Drittanbieter-API als Quelltyp aus.
  6. Wählen Sie Thinkst Canary als Protokolltyp aus.
  7. Klicken Sie auf Weiter.

  8. Geben Sie Werte für die folgenden Eingabeparameter an:

    • HTTP-Header für die Authentifizierung: Das zuvor generierte Token im Format auth_token:<TOKEN> (z. B. auth_token:AAAABBBBCCCC111122223333).
    • API-Hostname: Der voll qualifizierte Domainname Ihres Thinkst Canary REST API-Endpunkt im Format <DOMAIN_HASH>.canary.tools (z. B. myinstance.canary.tools).
    • 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.

Nach der Einrichtung werden die Logs chronologisch von der Thinkst Canary-Instanz abgerufen.

Updates zu Vorfällen und erneute Zustellung

Die Canary Console API gibt einen Vorfall immer dann zurück, wenn er aktualisiert wird, nicht nur, wenn er erstellt wird. Canary fasst ähnliche nachfolgende Ereignisse aus derselben Quelle im bestehenden Vorfall zusammen. Beispiel: Jeder Brute-Force-Angriffsversuch wird zu einem Ereignis innerhalb eines einzelnen Vorfalls. Auch andere Änderungen an Vorfällen können eine erneute Zustellung auslösen.

In Google SecOps ist mit folgendem Verhalten zu rechnen:

  • Vorfallsmeldungen, die bereits zugestellt wurden, werden nach der Aktualisierung wieder im Feed angezeigt.
  • Ein neu zugestellter Vorfall kann mit einem Ereigniszeitstempel angezeigt werden, der deutlich älter ist als der Zeitpunkt der Neuzustellung. Das liegt daran, dass der Parser Ereigniszeitstempel aus der ursprünglichen Erstellungszeit des Vorfalls und aus den eigenen Auftrittszeiten der gebündelten Ereignisse ableitet, nicht aus der Aktualisierungszeit.

Die erneute Zustellung selbst ist das dokumentierte Verhalten der API zum Erfassen von Vorfällen (es wird nach dem Aktualisierungszähler des Vorfalls gefiltert), nicht ein Datenverlust oder ein Parserfehler.

UDM-Zuordnungstabelle

Logfeld UDM-Zuordnung Logik
_canary_uptime_label additional.fields Zusammengeführt
desc_events_n_func_code_label additional.fields Zusammengeführt
desc_events_n_func_name_label additional.fields Zusammengeführt
desc_events_n_sfunc_code_label additional.fields Zusammengeführt
desc_events_n_sfunc_name_label additional.fields Zusammengeführt
desc_events_n_timestamp_std_label additional.fields Zusammengeführt
desc_events_n_unit_id_label additional.fields Zusammengeführt
description_created_std_label additional.fields Zusammengeführt
description_events_list_label additional.fields Zusammengeführt
event_data_list additional.fields Zusammengeführt
event_descrip_label additional.fields Zusammengeführt
events_url_label additional.fields Zusammengeführt
local_time_label additional.fields Zusammengeführt
locale_label additional.fields Zusammengeführt
lt_label additional.fields Zusammengeführt
offline_text_label additional.fields Zusammengeführt
updated_label additional.fields Zusammengeführt
updated_std_label additional.fields Zusammengeführt
_auth extensions.auth Umbenannt/zugeordnet
_metadata metadata Umbenannt/zugeordnet
_event_time metadata.event_timestamp Als UNIX geparst
_metadata_event_timestamp metadata.event_timestamp Als UNIX geparst
description.created_std metadata.event_timestamp Als UNIX_MS geparst
elem.timestamp_std metadata.event_timestamp Als yyyy-MM-dd HH:mm:ss ZZZ+0000 geparst
updated metadata.event_timestamp Als EEE, dd MMM yyyy HH:mm:ss ZZZ geparst
updated_std metadata.event_timestamp Als UNIX_MS geparst
format metadata.event_type Zugeordnet: grok → STATUS_UPDATE, grok → GENERIC_EVENT
has_principal_hostname metadata.event_type Zugeordnet: true → STATUS_UPDATE
_network network Umbenannt/zugeordnet
_observer observer Umbenannt/zugeordnet
_principal principal Umbenannt/zugeordnet
ThinkstCanary_Process principal.application Direkt zugeordnet
ThinkstCanary_Process principal.asset.hostname Direkt zugeordnet
ThinkstCanary_Hostname principal.hostname Direkt zugeordnet
_md_product_event_type security_result Zugeordnete Werte (insgesamt 10, z. B. Shared File Opened → _security_result, Host Port Scan → …
_security_result security_result Zusammengeführt
format security_result Zugeordnet: kv → _security_result, json → _security_result
_source src Umbenannt/zugeordnet
_target target Umbenannt/zugeordnet
– metadata.event_type Konstante: STATUS_UPDATE

Änderungsprotokoll

Änderungsprotokoll für diesen Parser ansehen

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