Cloud Threats-Kategorie – Übersicht

Unterstützt in:

In diesem Dokument finden Sie einen Überblick über die Regelsätze in der Kategorie „Cloud-Bedrohungen“, die erforderlichen Datenquellen 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 mit Google Cloud -Daten und in AWS-Umgebungen mit AWS-Daten erkennen.

Beschreibungen von Regelsätzen

Die folgenden Regelsätze sind in der Kategorie „Cloud-Bedrohungen“ verfügbar.

Die Abkürzung CDIR steht für Cloud Detection, Investigation, and Response (Cloud-Erkennung, -Untersuchung und -Reaktion).

Ausgewählte Erkennungen für Google Cloud -Daten

Google Cloud Mithilfe von Regelsätzen können Bedrohungen in Google Cloud Umgebungen anhand von Ereignis- und Kontextdaten erkannt werden. Dazu gehören die folgenden Regelsätze:

  • Administratoraktion: Aktivität, die mit administrativen Aktionen verbunden ist und je nach Verwendung in der Organisation als verdächtig, aber potenziell legitim eingestuft wird.
  • CDIR SCC Enhanced Exfiltration: Enthält kontextbezogene Regeln, die Ergebnisse zur Datenexfiltration in Security Command Center mit anderen Protokollquellen in Beziehung setzen, z. B. Cloud Audit Logs, Sensitive Data Protection-Kontext, BigQuery-Kontext und Security Command Center-Protokolle zu Fehlkonfigurationen.
  • CDIR SCC Enhanced Defense Evasion: Enthält kontextbezogene Regeln, die Ergebnisse zu Umgehung oder Abwehr von Systemen in Security Command Center mit Daten aus anderenGoogle Cloud Datenquellen wie Cloud-Audit-Logs in Beziehung setzen.
  • CDIR SCC Enhanced Malware: Enthält kontextbezogene Regeln, die Malware-Ergebnisse aus Security Command Center mit Daten wie dem Vorkommen von IP-Adressen und Domains sowie deren Prävalenzbewertungen in Beziehung setzen, zusätzlich zu anderen Datenquellen wie Cloud DNS-Logs.
  • CDIR SCC Enhanced Persistence: Enthält kontextbezogene Regeln, die die Ergebnisse zur Persistenz in Security Command Center mit Daten aus Quellen wie Cloud DNS-Logs und IAM-Analyse-Logs in Beziehung setzen.
  • CDIR SCC Enhanced Privilege Escalation: Enthält kontextbezogene Regeln, die Ergebnisse zur Privilegienerhöhung in Security Command Center mit Daten aus mehreren anderen Datenquellen wie Cloud-Audit-Logs in Beziehung setzen.
  • CDIR SCC Credential Access: Enthält kontextbezogene Regeln, die Ergebnisse zum Anmeldedatenzugriff in Security Command Center mit Daten aus mehreren anderen Datenquellen in Beziehung setzen, z. B. Cloud-Audit-Logs.
  • CDIR SCC Enhanced Discovery: Enthält kontextbezogene Regeln, die Ergebnisse der Eskalierung von Security Command Center Discovery mit Daten aus Quellen wie Google Cloud -Diensten und Cloud-Audit-Logs in Beziehung setzen.
  • CDIR SCC Brute Force: Enthält kontextbezogene Regeln, die Ergebnisse zur Brute-Force-Eskalation in Security Command Center mit Daten wie Cloud DNS-Logs in Beziehung setzen.
  • CDIR SCC Data Destruction: Enthält kontextbezogene Regeln, die Ergebnisse der Eskalierung von Datenvernichtungen in Security Command Center mit Daten aus mehreren anderen Datenquellen wie Cloud-Audit-Logs in Beziehung setzen.
  • CDIR SCC Inhibit System Recovery: Enthält kontextbezogene Regeln, die Ergebnisse von Security Command Center zu „Systemwiederherstellung verhindern“ mit Daten aus mehreren anderen Datenquellen wie Cloud-Audit-Logs in Beziehung setzen.
  • CDIR SCC Execution: Enthält kontextbezogene Regeln, die die Ergebnisse der Security Command Center-Ausführung mit Daten aus mehreren anderen Datenquellen wie Cloud-Audit-Logs in Beziehung setzen.
  • CDIR SCC Initial Access: Enthält kontextbezogene Regeln, die Ergebnisse zu Erstzugriff aus Security Command Center mit Daten aus mehreren anderen Datenquellen wie Cloud-Audit-Logs in Beziehung setzen.
  • CDIR SCC Impair Defenses: Enthält kontextbezogene Regeln, die Ergebnisse von Security Command Center Impair Defenses mit Daten aus mehreren anderen Datenquellen wie Cloud-Audit-Logs in Beziehung setzen.
  • CDIR SCC Impact: Enthält Regeln, mit denen Auswirkungs-Ergebnisse aus Security Command Center mit den Klassifizierungen „Kritisch“, „Hoch“, „Mittel“ und „Niedrig“ erkannt werden.
  • CDIR SCC Cloud IDS: Enthält Regeln, mit denen Cloud Intrusion Detection System-Ergebnisse aus Security Command Center mit den Klassifizierungen „Kritisch“, „Hoch“, „Mittel“ und „Niedrig“ erkannt werden.
  • CDIR SCC Cloud Armor: Enthält Regeln, mit denen Google Cloud Armor-Ergebnisse aus dem Security Command Center erkannt werden.
  • CDIR SCC Custom Module: Enthält Regeln, mit denen Ergebnisse des benutzerdefinierten Event Threat Detection-Moduls aus dem Security Command Center erkannt werden.
  • Cloud-Hacktool: Aktivität, die von bekannten offensiven Sicherheitsplattformen oder von offensiven Tools oder Software stammt, die von Angreifern in der Praxis verwendet wird und sich speziell auf Cloud-Ressourcen richtet.
  • Cloud SQL-Erpressung: Erkennt Aktivitäten im Zusammenhang mit der Datenexfiltration oder Erpressung von Daten in Cloud SQL-Datenbanken.
  • Verdächtige Kubernetes-Tools: Erkennt Erkundungs- und Ausnutzungsverhalten von Open-Source-Kubernetes-Tools.
  • Missbrauch der rollenbasierten Zugriffssteuerung (RBAC) in Kubernetes: Erkennt Kubernetes-Aktivitäten im Zusammenhang mit dem Missbrauch der rollenbasierten Zugriffssteuerung (RBAC), bei denen eine Rechteausweitung oder laterale Bewegung versucht wird.
  • Kubernetes Certificate Sensitive Actions (Zertifikatsbezogene Aktionen für Kubernetes): Erkennt Aktionen mit Kubernetes-Zertifikaten und Anfragen zur Zertifikatssignierung (Certificate Signing Requests, CSRs), die zum Herstellen von Persistenz oder zum Eskalieren von Berechtigungen verwendet werden könnten.
  • IAM-Missbrauch: Aktivitäten im Zusammenhang mit dem Missbrauch von IAM-Rollen und ‑Berechtigungen, um Berechtigungen potenziell zu eskalieren oder sich innerhalb eines bestimmten Cloud-Projekts oder einer Cloud-Organisation lateral zu bewegen.
  • Potenzielle Exfiltrationsaktivität: Erkennt Aktivitäten im Zusammenhang mit einer potenziellen Datenexfiltration.
  • Ressourcen-Masquerading: Erkennt Google Cloud Ressourcen, die mit Namen oder Merkmalen einer anderen Ressource oder eines anderen Ressourcentyps erstellt wurden. Dies kann dazu verwendet werden, schädliche Aktivitäten zu verschleiern, die von oder innerhalb der Ressource ausgeführt werden, um legitim zu erscheinen.
  • Serverless Threats : Hiermit werden Aktivitäten erkannt, die mit einer potenziellen Manipulation oder einem Missbrauch von serverlosen Ressourcen in Google Cloudin Verbindung stehen, z. B. Cloud Run und Cloud Run-Funktionen.
  • Dienstunterbrechung: Erkennen von zerstörerischen oder schädlichen Aktionen, die bei Ausführung in einer funktionierenden Produktionsumgebung zu einem erheblichen Ausfall führen können. Das erkannte Verhalten ist in Test- und Entwicklungsumgebungen häufig und wahrscheinlich harmlos.
  • Verdächtiges Verhalten: Aktivitäten, die in den meisten Umgebungen als ungewöhnlich und verdächtig eingestuft werden.
  • Verdächtige Infrastrukturänderung: Erkennt Änderungen an der Produktionsinfrastruktur, die mit bekannten Persistenztaktiken übereinstimmen
  • Geschwächte Konfiguration: Aktivität, die mit der Schwächung oder Beeinträchtigung einer Sicherheitskontrolle in Verbindung steht. Wird als verdächtig eingestuft, aber je nach geschäftlicher Nutzung möglicherweise legitim.
  • Potenzielle Daten-Exfiltration durch Insider über Chrome: Hiermit werden Aktivitäten erkannt, die mit potenziellen Insiderbedrohungen wie Daten-Exfiltration oder Verlust potenziell sensibler Daten außerhalb einer Google Workspace-Organisation in Verbindung stehen. Dazu gehören auch Verhaltensweisen in Chrome, die im Vergleich zu einem 30-tägigen Referenzzeitraum als anormal eingestuft werden.
  • Potenzielle Datenexfiltration durch Insider aus Drive: Hiermit werden Aktivitäten erkannt, die mit potenziellen Insiderbedrohungen in Verbindung stehen, z. B. Datenexfiltration oder Verlust potenziell sensibler Daten außerhalb einer Google Workspace-Organisation. Dazu gehören auch Verhaltensweisen in Drive, die im Vergleich zu einem 30-tägigen Referenzzeitraum als anormal eingestuft werden.
  • Potenzielle Datenexfiltration durch Insider aus Gmail: Hiermit werden Aktivitäten erkannt, die mit potenziellen Insiderbedrohungen wie Datenexfiltration oder Verlust potenziell vertraulicher Daten außerhalb einer Google Workspace-Organisation in Verbindung stehen. Dazu gehören auch Verhaltensweisen in Gmail, die im Vergleich zu einem 30-tägigen Referenzzeitraum als anormal eingestuft werden.
  • Potenzielle Manipulation eines Workspace-Kontos: Hiermit werden Verhaltensweisen von Insidern erkannt, die darauf hinweisen, dass das Konto möglicherweise manipuliert wurde und es zu Versuchen der Berechtigungserweiterung oder lateralen Bewegung innerhalb einer Google Workspace-Organisation kommen kann. Dazu gehören Verhaltensweisen, die im Vergleich zu einem 30-tägigen Referenzzeitraum als selten oder anomalos eingestuft werden.
  • Verdächtige Workspace-Verwaltungsaktionen: Hier werden Verhaltensweisen erkannt, die auf eine potenzielle Umgehung, eine Herabstufung der Sicherheit oder seltene und anormale Verhaltensweisen von Nutzern mit höheren Berechtigungen wie Administratoren hinweisen, die in den letzten 30 Tagen nicht beobachtet wurden.

Unterstützte Geräte und Protokolltypen

In den folgenden Abschnitten werden die Daten beschrieben, die für Regelsätze in der Kategorie „Cloud-Bedrohungen“ erforderlich sind.

Informationen zum Aufnehmen von Daten aus Google Cloud Diensten finden Sie unter Cloud-Logs in Google Security Operations aufnehmen. Wenden Sie sich an Ihren Google Security Operations-Ansprechpartner, wenn Sie diese Protokolle mit einem anderen Mechanismus erfassen müssen.

Google Security Operations stellt Standardparser bereit, die Rohprotokolle von Google Cloud -Diensten analysieren und normalisieren, um UDM-Einträge mit den von diesen Regelsätzen erforderlichen Daten zu erstellen.

Eine Liste aller von Google Security Operations unterstützten Datenquellen finden Sie unter Unterstützte Standardparser.

Alle Regelsätze

Wenn Sie einen Regelsatz verwenden möchten, empfehlen wir, Google CloudGoogle Cloud-Audit-Logs zu erfassen. Gemäß bestimmten Regeln müssen Kunden das Cloud DNS-Logging aktivieren. Achten Sie darauf, dass die Google Cloud Dienste so konfiguriert sind, dass Daten in den folgenden Protokollen aufgezeichnet werden:

Cloud SQL-Regelsatz für Lösegeldforderungen

Wenn Sie den Regelsatz Cloud SQL Ransom verwenden möchten, empfehlen wir, die folgenden Google Cloud Daten zu erfassen:

Erweiterte Regelsätze für CDIR SCC

Alle Regelsätze, die mit dem Namen CDIR SCC Enhanced beginnen, verwenden Security Command Center Premium-Ergebnisse, die in Bezug auf mehrere andere Google Cloud Logquellen gesetzt wurden, darunter:

  • Cloud-Audit-Logs
  • Cloud DNS-Logs
  • Analyse der Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM)
  • Kontext für den Schutz sensibler Daten
  • BigQuery-Kontext
  • Compute Engine-Kontext

Wenn Sie die Regelsätze CDIR SCC Enhanced verwenden möchten, empfehlen wir, die folgenden Google Cloud Daten zu erheben:

  • Logdaten, die im Bereich Alle Regelsätze aufgeführt sind.

  • Die folgenden Protokolldaten, aufgelistet nach Produktname und Aufnahmelabel für Google Security Operations:

    • BigQuery (GCP_BIGQUERY_CONTEXT)
    • Compute Engine (GCP_COMPUTE_CONTEXT)
    • IAM (GCP_IAM_CONTEXT)
    • Schutz sensibler Daten (GCP_DLP_CONTEXT)
    • Cloud-Audit-Logs (GCP_CLOUDAUDIT)
    • Google Workspace-Aktivitäten (WORKSPACE_ACTIVITY)
    • Cloud DNS-Abfragen (GCP_DNS)

  • Die folgenden Security Command Center-Ergebnisklassen, aufgelistet nach findingClass-ID und Google Security Operations-Aufnahmelabel:

    • Threat (GCP_SECURITYCENTER_THREAT)
    • Misconfiguration (GCP_SECURITYCENTER_MISCONFIGURATION)
    • Vulnerability (GCP_SECURITYCENTER_VULNERABILITY)
    • SCC Error (GCP_SECURITYCENTER_ERROR)

Die Regelsätze CDIR SCC Enhanced hängen ebenfalls von Daten aus Google Cloud -Diensten ab. Damit Sie die erforderlichen Daten an Google Security Operations senden können, müssen Sie Folgendes tun:

Mit den folgenden Regelsätzen wird eine Erkennung erstellt, wenn Ergebnisse aus Security Command Center Event Threat Detection, Google Cloud Armor, dem Security Command Center Sensitive Actions Service und benutzerdefinierten Modulen für Event Threat Detection erkannt werden:

  • CDIR SCC Cloud IDS
  • CDIR SCC Cloud Armor
  • Auswirkungen des CDIR-SCC
  • CDIR SCC Enhanced Persistence
  • CDIR SCC Enhanced Defense Evasion
  • Benutzerdefiniertes SCC-Modul für CDIR

Regelsatz für verdächtige Kubernetes-Tools

Wenn Sie den Regelsatz Verdächtige Kubernetes-Tools verwenden möchten, empfehlen wir Ihnen, die im Abschnitt Alle Regelsätze aufgeführten Daten zu erheben. Prüfen Sie, ob Google Cloud Dienste so konfiguriert sind, dass Daten in Google Kubernetes Engine-Knotenprotokollen (GKE) protokolliert werden.

Kubernetes-RBAC-Missbrauchsregelsatz

Wenn Sie den Regelsatz Missbrauch von Kubernetes-RBAC verwenden möchten, empfehlen wir, Cloud-Audit-Logs zu erfassen, die im Abschnitt Alle Regelsätze aufgeführt sind.

Regelsatz für vertrauliche Aktionen mit Kubernetes-Zertifikaten

Wenn Sie den Regelsatz Kubernetes-Zertifikatssensible Aktionen verwenden möchten, empfehlen wir, Cloud-Audit-Logs zu erfassen, die im Abschnitt Alle Regelsätze aufgeführt sind.

Google Workspace-bezogene Regelsätze

Mit den folgenden Regelsätzen werden Muster in Google Workspace-Daten erkannt:

  • Potenzieller Datendiebstahl durch Insider aus Chrome
  • Potenziell unbefugte Datenweitergabe aus Google Drive
  • Potenzieller Datenabfluss durch Insider aus Gmail
  • Potenziell manipuliertes Workspace-Konto
  • Verdächtige Workspace-Verwaltungsaktionen

Für diese Regelsätze sind die folgenden Protokolltypen erforderlich, aufgelistet nach Produktname und Google Security Operations-Aufnahmelabel:

  • Aktivitäten im Arbeitsbereich (WORKSPACE_ACTIVITY)
  • Workspace-Benachrichtigungen (WORKSPACE_ALERTS)
  • Workspace-ChromeOS-Geräte (WORKSPACE_CHROMEOS)
  • Workspace-Mobilgeräte (WORKSPACE_MOBILE)
  • Workspace-Nutzer (WORKSPACE_USERS)
  • Google Chrome-Verwaltung über die Cloud (CHROME_MANAGEMENT)
  • Gmail-Protokolle (GMAIL_LOGS)

So nehmen Sie die erforderlichen Daten auf:

Regelsatz für serverlose Bedrohungen

Cloud Run-Logs umfassen Anfrage- und Container-Logs, die in Google Security Operations als GCP_RUN-Logtyp aufgenommen werden. GCP_RUN-Logs können direkt oder über Feeds und Cloud Storage aufgenommen werden. Informationen zu bestimmten Logfiltern und weitere Details zur Datenaufnahme finden Sie unter Logs in Google Security Operations exportieren Google Cloud . Mit dem folgenden Exportfilter werden Google Cloud Cloud Run-Logs (GCP_RUN) zusätzlich zu den Standard-Logs sowohl über den direkten Datenaufnahmemechanismus als auch über Cloud Storage und Senken exportiert:

log_id("run.googleapis.com/stdout") OR
log_id("run.googleapis.com/stderr") OR
log_id("run.googleapis.com/requests") OR
log_id("run.googleapis.com/varlog/system)

Ausgewählte Erkennungen für AWS-Regelsätze

Mit den AWS-Regelsätzen in dieser Kategorie lassen sich anhand von Ereignis- und Kontextdaten Bedrohungen in AWS-Umgebungen erkennen. Dazu gehören die folgenden Regelsätze:

  • AWS – Computing: Erkennt anormale Aktivitäten im Zusammenhang mit AWS-Rechenressourcen wie EC2 und Lambda.
  • AWS – Daten: Erkennt AWS-Aktivitäten im Zusammenhang mit Datenressourcen wie RDS-Snapshots oder öffentlich zugänglichen S3-Buckets.
  • AWS – GuardDuty: Kontextsensitive AWS GuardDuty-Benachrichtigungen zu Verhalten, Anmeldedatenzugriff, Kryptomining, Erkennung, Umgehung, Ausführung, Exfiltration, Auswirkungen, Erstzugriff, Malware, Penetrationstests, Persistenz, Richtlinien, Berechtigungseskalierung und unbefugtem Zugriff.
  • AWS – Hacktools: Erkennt die Verwendung von Hacktools in einer AWS-Umgebung, z. B. Scanner, Toolkits und Frameworks.
  • AWS – Identität: Erkennungen von AWS-Aktivitäten im Zusammenhang mit IAM- und Authentifizierungsaktivitäten, z. B. ungewöhnliche Anmeldungen von mehreren Standorten, übermäßig permissive Rollenerstellung oder IAM-Aktivitäten von verdächtigen Tools.
  • AWS – Logging und Monitoring: Erkennt AWS-Aktivitäten im Zusammenhang mit der Deaktivierung von Logging- und Monitoring-Diensten wie CloudTrail, CloudWatch und GuardDuty.
  • AWS – Netzwerk: Hier werden unsichere Änderungen an AWS-Netzwerkeinstellungen wie Sicherheitsgruppen und Firewalls erkannt.
  • AWS – Organisation: Hier werden AWS-Aktivitäten erfasst, die mit Ihrer Organisation in Verbindung stehen, z. B. das Hinzufügen oder Entfernen von Konten und unerwartete Ereignisse im Zusammenhang mit der Nutzung der Region.
  • AWS – Secrets: Erkennt AWS-Aktivitäten im Zusammenhang mit Secrets, Tokens und Passwörtern, z. B. das Löschen von KMS-Secrets oder Secrets Manager-Secrets.

Unterstützte Geräte und Protokolltypen für AWS

Diese Regelsätze wurden getestet und werden von den folgenden Google Security Operations-Datenquellen unterstützt. Sie sind nach Produktname und Aufnahmelabel aufgelistet.

Informationen zum Einrichten der Datenaufnahme von AWS-Daten finden Sie unter Aufnahme von AWS-Daten konfigurieren.

Eine Liste aller unterstützten Datenquellen finden Sie unter Unterstützte Standardparser.

In den folgenden Abschnitten werden die erforderlichen Daten für Regelsätze beschrieben, mit denen Muster in Daten erkannt werden.

Sie können AWS-Daten mit einem Amazon S3-Bucket (Amazon Simple Storage Service) als Quelltyp oder optional mit Amazon S3 und Amazon Simple Queue Service (Amazon SQS) aufnehmen. Im Groben müssen Sie Folgendes tun:

  • Konfigurieren Sie Amazon S3 oder Amazon S3 mit Amazon SQS, um Protokolldaten zu erfassen.
  • Google Security Operations Feed zum Aufnehmen von Daten aus Amazon S3 oder Amazon SQS konfigurieren

Eine detaillierte Anleitung zum Konfigurieren von AWS-Diensten und zum Konfigurieren eines Google Security Operations-Feeds für die Aufnahme von AWS-Daten finden Sie unter AWS-Protokolle in Google Security Operations aufnehmen.

Mit den Testregeln für die Verwaltung von AWS-Erkennungstests können Sie prüfen, ob AWS-Daten in die SIEM-Lösung von Google Security Operations aufgenommen werden. Mit diesen Testregeln können Sie prüfen, ob AWS-Protokolldaten wie erwartet aufgenommen werden. Nachdem Sie die Aufnahme von AWS-Daten eingerichtet haben, führen Sie Aktionen in AWS aus, die die Testregeln auslösen sollten.

Informationen zum Überprüfen der Datenaufnahme von AWS für die Kategorie „Cloud-Bedrohungen“

Ausgewählte Erkennungen für Azure-Daten

Bestimmte Regelsätze in dieser Kategorie sind für die Verwendung mit Azure-Daten konzipiert, um mithilfe von Ereignisdaten, Kontextdaten und Benachrichtigungen Bedrohungen in Azure-Umgebungen zu erkennen. Dazu gehören:

  • Azure – Compute: Hier werden anormale Aktivitäten im Zusammenhang mit Azure-Rechenressourcen wie Kubernetes und virtuellen Maschinen (VMs) erkannt.
  • Azure – Daten: Hier werden Aktivitäten erkannt, die mit Datenressourcen verknüpft sind, z. B. Azure-Blob-Berechtigungen, Änderungen und Einladungen externer Nutzer zur Nutzung von Azure-Diensten im Mandanten.
  • Azure – Defender for Cloud: Hier werden Benachrichtigungen identifiziert, die vom kontextbezogenen Microsoft Defender for Cloud zu Nutzerverhalten, Anmeldedatenzugriff, Kryptomining, Erkennung, Umgehung, Ausführung, Exfiltration, Auswirkungen, Erstzugriff, Malware, Penetrationstests, Persistenz, Richtlinien, Berechtigungseskalierung oder nicht autorisiertem Zugriff in allen Azure-Cloud-Diensten empfangen wurden.
  • Azure – Hacktools: Erkennt die Verwendung von Hacking-Tools in einer Azure-Umgebung, z. B. Tor- und VPN-Anonymisierer, Scanner und Red-Teaming-Toolkits.
  • Azure – Identität: Hier werden Aktivitäten im Zusammenhang mit Authentifizierung und Autorisierung erkannt, die auf ungewöhnliches Verhalten hinweisen, z. B. gleichzeitiger Zugriff von mehreren geografischen Standorten, zu großzügige Zugriffsverwaltungsrichtlinien oder Azure-RBAC-Aktivitäten von verdächtigen Tools.
  • Azure – Logging und Monitoring: Hiermit werden Aktivitäten im Zusammenhang mit der Deaktivierung von Logging- und Monitoring-Diensten in Azure erkannt.
  • Azure – Netzwerk: Erkennt unsichere und bemerkenswerte Änderungen an Azure-Netzwerkgeräten oder ‑einstellungen, z. B. an Sicherheitsgruppen oder Firewalls, der Azure Web Application Firewall und den Richtlinien für den Dienstausfall.
  • Azure – Organisation: Hier werden Aktivitäten erkannt, die mit Ihrer Organisation in Verbindung stehen, z. B. das Hinzufügen oder Entfernen von Abos und Konten.
  • Azure – Secrets: Erkennt Aktivitäten im Zusammenhang mit Secrets, Tokens und Passwörtern (z. B. Änderungen an Azure Key Vault- oder Speicherkontozugriffsschlüsseln).

Unterstützte Geräte und erforderliche Protokolltypen für Azure

Diese Regelsätze wurden getestet und werden von den folgenden Datenquellen unterstützt. Sie sind nach Produktname und Google SecOps-Aufnahmelabel aufgelistet.

Azure- und Microsoft Entra ID-Daten aufnehmen

Sie müssen Daten aus jeder Datenquelle aufnehmen, um eine maximale Abdeckung der Regeln zu erreichen. In der folgenden Dokumentation finden Sie Informationen zum Aufnehmen von Daten aus den einzelnen Quellen.

Im folgenden Abschnitt wird beschrieben, wie Sie die Aufnahme von Azure-Daten mithilfe vordefinierter Testregeln überprüfen.

Datenaufnahme von Azure prüfen

Im Dashboard für die Datenaufnahme und -integrität von Google SecOps finden Sie Informationen zum Typ, Volumen und zur Integrität aller Daten, die mithilfe von SIEM-Aufnahmefunktionen in Google SecOps aufgenommen werden.

Sie können auch Testregeln für die verwaltete Erkennung in Azure verwenden, um die Aufnahme von Azure-Daten zu überprüfen. Nachdem Sie die Datenaufnahme eingerichtet haben, führen Sie im Azure-Portal Aktionen aus, die die Testregeln auslösen sollen. Sie sollen prüfen, ob Daten aufgenommen wurden und im erwarteten Format vorliegen, um die ausgewählten Erkennungen für Azure-Daten zu verwenden.

Testregeln für die verwaltete Erkennung in Azure aktivieren

  1. Klicken Sie in Google Security Operations auf Erkannte Probleme > Regeln und erkannte Probleme, um die Seite „Ausgewählte erkannte Probleme“ zu öffnen.
  2. Wählen Sie Verwaltete Erkennung – Tests > Azure – Verwaltete Erkennung – Tests aus.
  3. Aktivieren Sie sowohl Status als auch Benachrichtigung für die allgemeinen und genauen Regeln.

Daten zu Nutzeraktionen senden, um die Testregeln auszulösen

Um zu prüfen, ob Daten wie erwartet aufgenommen werden, erstellen Sie einen Nutzer und melden Sie sich an, um zu prüfen, ob diese Aktionen die Testregeln auslösen. Informationen zum Erstellen von Nutzern in Microsoft Entra ID finden Sie unter Nutzer erstellen, einladen und löschen.

  1. Erstellen Sie in Azure einen neuen Microsoft Entra ID-Nutzer.

    1. Rufen Sie das Azure-Portal auf.
    2. Öffnen Sie Microsoft Entra ID.
    3. Klicken Sie auf Hinzufügen und dann auf Neuen Nutzer erstellen. So definieren Sie den Nutzer:
      1. Geben Sie die folgenden Informationen ein:
        • Nutzerprinzipalname: GCTI_ALERT_VALIDATION
        • Nutzerprinzipalname: GCTI_ALERT_VALIDATION
        • Anzeigename: GCTI_ALERT_VALIDATION
      2. Wählen Sie Passwort automatisch generieren aus, um ein Passwort für diesen Nutzer automatisch generieren zu lassen.
      3. Klicken Sie das Kästchen Konto aktiviert an.
      4. Öffnen Sie den Tab Prüfen + Erstellen.
      5. Merken Sie sich das automatisch generierte Passwort. Sie benötigen sie in den nächsten Schritten.
      6. Klicken Sie auf Erstellen.
    4. Öffnen Sie ein Browserfenster im Inkognitomodus und rufen Sie das Azure-Portal auf.
    5. Melden Sie sich mit dem neu erstellten Nutzer und dem Passwort an.
    6. Ändern Sie das Nutzerpasswort.
    7. Aktivieren Sie die Multi-Faktor-Authentifizierung (MFA) gemäß den Richtlinien Ihrer Organisation.
    8. Melden Sie sich aus dem Azure-Portal ab.

  2. So prüfen Sie, ob Benachrichtigungen in Google Security Operations erstellt werden:

    1. Klicken Sie in Google Security Operations auf Erkannte Probleme > Regeln und erkannte Probleme, um die Seite Ausgewählte erkannte Probleme zu öffnen.

    2. Klicken Sie auf Dashboard.

    3. Prüfen Sie in der Liste der Erkennungen, ob die folgenden Regeln ausgelöst wurden:

      • tst_azure_ad_user_creation
      • tst_azure_ad_user_login

  3. Nachdem Sie bestätigt haben, dass Daten gesendet und diese Regeln ausgelöst werden, deaktivieren oder widerrufen Sie die Bereitstellung des Nutzerkontos.

Beispielbenachrichtigungen senden, um die Testregeln auszulösen

Führen Sie die folgenden Schritte aus, um zu prüfen, ob die Testregeln durch das Generieren von Beispielsicherheitswarnungen in Azure ausgelöst werden. Weitere Informationen zum Generieren von Beispiel-Sicherheitswarnungen in Microsoft Defender for Cloud finden Sie unter Warnungen in Microsoft Defender for Cloud validieren.

  1. Rufen Sie im Azure-Portal Alle Dienste auf.
  2. Öffnen Sie unter Sicherheit die Seite Microsoft Defender for Cloud.
  3. Gehen Sie zu Sicherheitswarnungen.
  4. Klicken Sie auf Beispielbenachrichtigungen und gehen Sie dann so vor:
    1. Wählen Sie Ihr Abo aus.
    2. Wählen Sie für Defender for Cloud-Abos die Option alle aus.
    3. Klicken Sie auf Beispielbenachrichtigungen erstellen.
  5. Prüfen Sie, ob Testbenachrichtigungen ausgelöst werden.
  6. Klicken Sie in Google Security Operations auf Erkannte Probleme > Regeln und erkannte Probleme, um die Seite Ausgewählte erkannte Probleme zu öffnen.
  7. Klicken Sie auf Dashboard.
  8. Prüfen Sie in der Liste der Erkennungen, ob die folgenden Regeln ausgelöst wurden:
    • tst_azure_activity
    • tst_azure_defender_for_cloud_alerts

Führen Sie eine GET API-Anfrage im Microsoft Graph Explorer aus, um die Testregeln auszulösen.

Führen Sie die folgenden Schritte aus, um zu prüfen, ob die Testregeln durch das Generieren von Beispielsicherheitswarnungen in Azure ausgelöst werden.

  1. Rufen Sie den Microsoft Graph Explorer auf.
  2. Achten Sie darauf, dass oben rechts der richtige Tenant ausgewählt ist.
  3. Klicken Sie auf Abfrage ausführen.
  4. Prüfen Sie, ob Testbenachrichtigungen ausgelöst werden.
  5. Klicken Sie in Google Security Operations auf Erkannte Probleme > Regeln und erkannte Probleme, um die Seite Ausgewählte erkannte Probleme zu öffnen.
  6. Klicken Sie auf Dashboard.
  7. Prüfen Sie in der Liste der Erkennungen, ob die Regel tst_microsoft_graph_api_get_activity ausgelöst wurde.

Regelsätze für Azure Managed Detection Testing deaktivieren

  1. Klicken Sie in Google Security Operations auf Erkennung > Regeln und Erkennungen, um die Seite Ausgewählte Erkennungen zu öffnen.
  2. Wählen Sie die Regeln Managed Detection Testing > Azure Managed Detection Testing aus.
  3. Deaktivieren Sie sowohl Status als auch Benachrichtigung für die allgemeinen und genauen Regeln.

Von Regelsätzen zurückgegebene Optimierungswarnungen

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.

Nächste Schritte