Building-Cloud-SIEM-with-Sentinel

Aufbau eines Cloud-SIEM mit Sentinel

Wann verwenden

• Bei der Einrichtung eines zentralen Security Operations Centers für Multi-Cloud-Umgebungen
• Bei der Migration von Legacy-SIEM-Plattformen (Splunk, QRadar) zu einer cloudnativen Architektur
• Beim Aufbau automatisierter Incident-Response-Workflows für Cloud-spezifische Bedrohungen
• Bei der Durchführung groß angelegter Bedrohungssuche über Petabytes an Sicherheitstelemetrie hinweg
• Bei der Integration von Bedrohungsintelligenz-Feeds mit Cloud-Sicherheitslog-Analysen

Nicht verwenden für reine AWS-Umgebungen, in denen Security Hub und GuardDuty ausreichen, für die Endpunkterkennung, die EDR-Funktionen erfordert (Defender for Endpoint verwenden), oder für das Compliance-Posture-Monitoring (siehe building-cloud-security-posture-management).

Voraussetzungen

• Azure-Abonnement mit Microsoft Sentinel, aktiviert auf einem Log Analytics-Arbeitsbereich
• Berechtigungen für Datenkonnektoren für die Ziel-Logquellen (AWS CloudTrail, Azure Activity, GCP)
• Logic Apps oder Azure Functions für automatisierte Response-Playbooks
• Kenntnisse in KQL (Kusto-Abfragesprache) zum Schreiben von Erkennungsregeln und Jagdabfragen

Workflow

Schritt 1: Sentinel-Arbeitsbereich und Datenkonnektoren bereitstellen

Erstellen Sie einen für Sicherheitsdaten optimierten Log Analytics-Arbeitsbereich und aktivieren Sie Datenkonnektoren für die Multi-Cloud-Aufnahme.

# Log Analytics-Arbeitsbereich erstellen
az monitor log-analytics workspace create \
  --resource-group security-rg \
  --workspace-name sentinel-workspace \
  --location eastus \
  --retention-time 365 \
  --sku PerGB2018

# Microsoft Sentinel im Arbeitsbereich aktivieren
az sentinel onboarding-state create \
  --resource-group security-rg \
  --workspace-name sentinel-workspace

# AWS CloudTrail-Konnektor aktivieren
az sentinel data-connector create \
  --resource-group security-rg \
  --workspace-name sentinel-workspace \
  --data-connector-id aws-cloudtrail \
  --kind AmazonWebServicesCloudTrail \
  --aws-cloud-trail-data-connector '{
    "awsRoleArn": "arn:aws:iam::123456789012:role/SentinelCloudTrailRole",
    "dataTypes": {"logs": {"state": "Enabled"}}
  }'

# Azure AD-Anmelde- und Überwachungsprotokolle aktivieren
az sentinel data-connector create \
  --resource-group security-rg \
  --workspace-name sentinel-workspace \
  --data-connector-id azure-ad \
  --kind AzureActiveDirectory \
  --azure-active-directory '{
    "dataTypes": {
      "alerts": {"state": "Enabled"},
      "signinLogs": {"state": "Enabled"},
      "auditLogs": {"state": "Enabled"}
    }
  }'

Schritt 2: KQL-Erkennungsregeln schreiben

Erstellen Sie Analyse-Regeln mit der Kusto-Abfragesprache, um Cloud-spezifische Bedrohungen zu erkennen. Ordnen Sie jede Regel den MITRE ATT&CK-Techniken zu.

// Erkennen von Impossible Travel – Anmeldungen von geografisch weit entfernten Orten
let timeframe = 1h;
let distance_threshold = 500; // km
SigninLogs
| where TimeGenerated > ago(timeframe)
| where ResultType == 0 // Nur erfolgreiche Anmeldungen
| project TimeGenerated, UserPrincipalName, IPAddress, Location,
          Latitude = toreal(LocationDetails.geoCoordinates.latitude),
          Longitude = toreal(LocationDetails.geoCoordinates.longitude)
| sort by UserPrincipalName asc, TimeGenerated asc
| extend PrevLatitude = prev(Latitude, 1), PrevLongitude = prev(Longitude, 1),
         PrevTime = prev(TimeGenerated, 1), PrevUser = prev(UserPrincipalName, 1)
| where UserPrincipalName == PrevUser
| extend TimeDiff = datetime_diff('minute', TimeGenerated, PrevTime)
| where TimeDiff < 60
| extend Distance = geo_distance_2points(Longitude, Latitude, PrevLongitude, PrevLatitude) / 1000
| where Distance > distance_threshold
| project TimeGenerated, UserPrincipalName, IPAddress, Location, Distance, TimeDiff

// Erkennen von AWS IAM-Anmeldedatenmissbrauch aus CloudTrail
AWSCloudTrail
| where TimeGenerated > ago(24h)
| where EventName in ("ConsoleLogin", "AssumeRole", "GetSessionToken")
| where ErrorCode == ""
| summarize LoginCount = count(), DistinctIPs = dcount(SourceIpAddress),
            IPList = make_set(SourceIpAddress, 10)
            by UserIdentityArn, bin(TimeGenerated, 1h)
| where DistinctIPs > 3
| project TimeGenerated, UserIdentityArn, LoginCount, DistinctIPs, IPList

// Erkennen von Massenlöschungen von S3-Objekten (potenzielle Ransomware)
AWSCloudTrail
| where TimeGenerated > ago(1h)
| where EventName == "DeleteObject" or EventName == "DeleteObjects"
| summarize DeleteCount = count(), BucketsAffected = dcount(RequestParameters_bucketName)
            by UserIdentityArn, bin(TimeGenerated, 10m)
| where DeleteCount > 100
| project TimeGenerated, UserIdentityArn, DeleteCount, BucketsAffected

Schritt 3: SOAR-Playbooks mit Logic Apps erstellen

Erstellen Sie automatisierte Response-Playbooks, die ausgeführt werden, wenn Analyse-Regeln Incidents auslösen. Übliche Aktionen sind das Blockieren von Benutzern, das Isolieren von Ressourcen und die Anreicherung von Incidents mit Bedrohungsintelligenz.

{
  "definition": {
    "triggers": {
      "Microsoft_Sentinel_incident": {
        "type": "ApiConnectionWebhook",
        "inputs": {
          "body": {"incidentArmId": "subscriptions/@{triggerBody()?['workspaceInfo']?['SubscriptionId']}/resourceGroups/@{triggerBody()?['workspaceInfo']?['ResourceGroupName']}/providers/Microsoft.OperationalInsights/workspaces/@{triggerBody()?['workspaceInfo']?['WorkspaceName']}/providers/Microsoft.SecurityInsights/Incidents/@{triggerBody()?['object']?['properties']?['incidentNumber']}"},
          "host": {"connection": {"name": "@parameters('$connections')['microsoftsentinel']['connectionId']"}}
        }
      }
    },
    "actions": {
      "Get_incident_entities": {
        "type": "ApiConnection",
        "inputs": {"method": "post", "path": "/Incidents/entities"}
      },
      "For_each_account_entity": {
        "type": "Foreach",
        "foreach": "@body('Get_incident_entities')?['Accounts']",
        "actions": {
          "Disable_Azure_AD_user": {
            "type": "ApiConnection",
            "inputs": {
              "method": "PATCH",
              "path": "/v1.0/users/@{items('For_each_account_entity')?['AadUserId']}",
              "body": {"accountEnabled": false}
            }
          },
          "Add_comment_to_incident": {
            "type": "ApiConnection",
            "inputs": {
              "body": {"message": "User @{items('For_each_account_entity')?['Name']} disabled by automated playbook"}
            }
          }
        }
      }
    }
  }
}

Schritt 4: Sentinel Data Lake für die langfristige Bedrohungssuche konfigurieren

Aktivieren Sie den Sentinel Data Lake für die Protokollaufbewahrung im Petabyte-Maßstab und die erweiterte Bedrohungssuche unter Verwendung von KQL- und SQL-Endpunkten.

// Jagdabfrage: Erkennen von Lateral Movement über AWS-Konten hinweg
let suspicious_roles = AWSCloudTrail
| where TimeGenerated > ago(7d)
| where EventName == "AssumeRole"
| extend AssumedRoleArn = tostring(parse_json(RequestParameters).roleArn)
| where AssumedRoleArn contains "cross-account" or AssumedRoleArn contains "admin"
| summarize AssumeCount = count(), UniqueSourceAccounts = dcount(RecipientAccountId)
            by UserIdentityArn, AssumedRoleArn
| where AssumeCount > 10 and UniqueSourceAccounts > 2;
suspicious_roles
| join kind=inner (
    AWSCloudTrail
    | where TimeGenerated > ago(7d)
    | where EventName in ("RunInstances", "CreateFunction", "PutBucketPolicy")
) on UserIdentityArn
| project TimeGenerated, UserIdentityArn, AssumedRoleArn, EventName, SourceIpAddress

Schritt 5: Bedrohungsintelligenz integrieren

Verbinden Sie Bedrohungsintelligenz-Anbieter und erstellen Sie indikatorbasierte Abgleichsregeln, um die Kommunikation mit bekannter bösartiger Infrastruktur zu erkennen.

# Microsoft Threat Intelligence-Konnektor aktivieren
az sentinel data-connector create \
  --resource-group security-rg \
  --workspace-name sentinel-workspace \
  --data-connector-id microsoft-ti \
  --kind MicrosoftThreatIntelligence \
  --microsoft-threat-intelligence '{
    "dataTypes": {"microsoftEmergingThreatFeed": {"lookbackPeriod": "2025-01-01T00:00:00Z", "state": "Enabled"}}
  }'

// Netzwerkindikatoren mit Cloud-Flow-Protokollen abgleichen
let TI_IPs = ThreatIntelligenceIndicator
| where TimeGenerated > ago(30d)
| where isnotempty(NetworkIP)
| distinct NetworkIP;
AzureNetworkAnalytics_CL
| where TimeGenerated > ago(24h)
| where DestIP_s in (TI_IPs)
| project TimeGenerated, SrcIP_s, DestIP_s, DestPort_d, FlowType_s

Schlüsselkonzepte

Begriff	Definition
KQL	Kusto-Abfragesprache, die primäre Abfragesprache für Microsoft Sentinel zum Durchsuchen, Analysieren und Visualisieren von Sicherheitsdaten
Analyse-Regel	Erkennungslogik in Sentinel, die Protokolldaten nach einem Zeitplan auswertet und Incidents erstellt, wenn Bedingungen zutreffen
SOAR-Playbook	Automatisierter Workflow, der durch Incidents ausgelöst wird und Reaktionsmaßnahmen wie das Blockieren von Konten, die Anreicherung von Incidents oder die Benachrichtigung von Teams durchführt
Datenkonnektor	Integrationsmodul, das Sicherheitsprotokolle von Cloud-Diensten, Identitätsanbietern und Drittanbieter-Tools in Sentinel aufnimmt
Sentinel Data Lake	Speicherschicht im Petabyte-Maßstab, die eine langfristige Protokollaufbewahrung mit KQL- und SQL-Abfrageschnittstellen für die erweiterte Bedrohungssuche bietet
Workbook	Interaktives Dashboard in Sentinel, das Visualisierungen von Sicherheitsdaten, Trends und Betriebskennzahlen anzeigt
Watchlist	Referenzdatentabellen in Sentinel, die verwendet werden, um Incidents mit Kontext wie VIP-Benutzerlisten oder genehmigten IP-Bereichen anzureichern
Fusion-Erkennung	Machine Learning-gestützte Korrelations-Engine, die automatisch mehrstufige Angriffe über mehrere Datenquellen hinweg erkennt

Tools und Systeme

• Microsoft Sentinel: Cloudnative SIEM/SOAR-Plattform, basierend auf Azure Log Analytics mit KI-gestützter Bedrohungserkennung
• Azure Logic Apps: Low-Code-Automatisierungsplattform zum Erstellen von SOAR-Playbooks, die durch Sentinel-Incidents ausgelöst werden
• Microsoft Threat Intelligence: Integrierte Bedrohungsfeeds, die IP-, Domain- und URL-Indikatoren zum Abgleich mit Sicherheitsprotokollen bereitstellen
• Azure Data Explorer: Hochleistungs-Analyse-Engine, die Sentinel-KQL-Abfragen für die großflächige Datenuntersuchung zugrunde liegt
• MITRE ATT&CK Navigator: Framework zum Zuordnen von Sentinel-Erkennungsregeln zu Angreifertaktiken und -techniken

Häufige Szenarien

Szenario: Erkennung einer Cloud-übergreifenden Kampagne zur Anmeldeinformationsdiebstahl

Kontext: Ein Angreifer kompromittiert ein Azure AD-Konto durch Phishing und verwendet dann das Konto, um über eine föderierte Identität auf AWS-Ressourcen zuzugreifen. Sentinel muss die Azure AD-Anmeldeanomalie mit ungewöhnlichen AWS-API-Aktivitäten korrelieren.

Ansatz:

1. Erstellen Sie eine Analyse-Regel, die Azure AD Impossible Travel oder ein anomales Anmelderisiko erkennt
2. Schreiben Sie eine KQL-Abfrage, die die kompromittierte Azure AD-Identität mit AWS CloudTrail AssumeRoleWithSAML-Ereignissen korreliert
3. Erstellen Sie eine Fusion-Erkennungsregel, die Azure AD-Risikoereignisse mit nachfolgenden AWS-Privilege-Escalation-Aktivitäten verknüpft
4. Stellen Sie ein SOAR-Playbook bereit, das automatisch das Azure AD-Konto deaktiviert und AWS-STS-Sitzungen widerruft
5. Erstellen Sie ein Workbook, das die Zeitleiste von der ersten Kompromittierung bis zur Lateral Movement in AWS zeigt
6. Führen Sie eine Jagdabfrage über den Data Lake durch, um nach ähnlichen Mustern zu suchen, die andere Konten betreffen

Fallstricke: Wenn die Identität nicht über Cloud-Anbieter hinweg korreliert wird, wird die gesamte Angriffskette übersehen. Eine zu niedrig eingestellte Häufigkeit der Analyse-Regel (z. B. 24 Stunden) gibt Angreifern stundenlangen unentdeckten Zugriff.

Ausgabeformat

Microsoft Sentinel SOC-Betriebsbericht
==========================================
Arbeitsbereich: sentinel-workspace
Datenquellen: 14 Konnektoren aktiv
Berichtszeitraum: 2025-02-01 bis 2025-02-23

DATENAUFNAHME:
  Azure AD-Anmeldeprotokolle:     2,3 TB (23 Tage)
  AWS CloudTrail:                  1,8 TB (23 Tage)
  Azure Activity:                  0,9 TB (23 Tage)
  Defender for Cloud-Warnungen:    45 GB (23 Tage)
  Gesamtaufnahme:                  5,1 TB

ERKENNUNGSZUSAMMENFASSUNG:
  Aktive Analyse-Regeln: 87
  Erstellte Incidents: 234
    Kritisch: 8 | Hoch: 34 | Mittel: 89 | Niedrig: 103
  Mittlere Erkennungszeit (MTTD): 4,2 Minuten
  Mittlere Reaktionszeit (MTTR): 18 Minuten

TOP-INCIDENT-TYPEN:
  Impossible Travel erkannt:                42 Incidents
  Muster unautorisierter AWS-API-Aufrufe:   28 Incidents
  Massenhafte Dateilöschung in S3:           3 Incidents
  Verdächtige Azure AD-App-Registrierung:  12 Incidents

AUTOMATISIERUNG:
  Ausgeführte Playbooks: 156
  Automatisch deaktivierte Konten: 23
  Automatisch angereicherte Incidents: 198
  Falsch-Positiv-Rate: 12 %