Incident-Response-Playbook für Azure-Umgebungen: Von der Erkennung bis zur Wiederherstellung

Ein Sicherheitsvorfall in einer Cloud-Umgebung bewegt sich schneller als On-Premises. Ein Angreifer, der einen Service Principal kompromittiert, kann Ihr gesamtes Azure-Estate in Minuten durchqueren. Ihr Incident-Response-Playbook muss diese Geschwindigkeit berücksichtigen, Cloud-native Werkzeuge nutzen und klare, ausführbare Runbooks bereitstellen, denen Ihr Team unter Druck folgen kann.

Dieses Playbook folgt dem NIST-Sechs-Phasen-IR-Modell, adaptiert fuer Azure-spezifisches Tooling und Cloud-native Angriffsmuster.

Phase 1: Vorbereitung

Vorbereitung ist die einzige Phase, die Sie vor einem Incident kontrollieren. Jede hier investierte Stunde spart zehn während eines aktiven Incidents.

Tooling-Baseline

Stellen Sie sicher, dass diese Services bereitgestellt und konfiguriert sind, bevor Sie sie benötigen:

Detection und Alerting:

• Microsoft Sentinel mit Connectors für Entra ID, Azure Activity, Defender for Cloud, Microsoft 365 und alle kritischen Anwendungslogs
• Defender for Cloud mit allen aktivierten Defender-Plänen (Servers, Containers, SQL, Storage, Key Vault, DNS, Resource Manager)
• Azure Monitor Alerts für Resource Health und Verfügbarkeit

Investigation:

• Log Analytics Workspace mit 90-Tage-Hot-Retention und 365-Tage-Archiv
• Sentinel Notebooks mit vorkonfigurierten Investigation-Templates
• Network Watcher mit NSG Flow Logs, Packet Capture in wichtigen Regionen aktiviert

Response-Automatisierung:

• Sentinel Playbooks (Logic Apps) für gängige Containment-Aktionen
• Azure Automation Runbooks für infrastrukturseitige Responses
• Vorab genehmigte Change Tickets für Notfall-Containment-Aktionen

Rollen und Eskalationsmatrix

Definieren Sie diese Rollen vor einem Incident:

Kommunikationsvorlagen

Bereiten Sie Vorlagen vor, bevor Sie sie benötigen:

Interne Eskalationsvorlage:

SICHERHEITSVORFALL — [SCHWEREGRAD]
Erkannt um: [ZEITSTEMPEL]
Betroffene Systeme: [SYSTEME]
Aktuelle Auswirkung: [BESCHREIBUNG]
Containment-Status: [IN BEARBEITUNG / EINGEDÄMMT / NICHT EINGEDÄMMT]
Nächstes Update: [UHRZEIT]
IR Lead: [NAME / KONTAKT]

Regulatorische Meldevorlage (für DORA, NIS2 oder DSGVO):

ERSTMELDUNG — ICT-BEZOGENER VORFALL
Unternehmen: [RECHTSEINHEIT]
Zuständige Behörde: [BEHÖRDE]
Datum/Uhrzeit der Erkennung: [ZEITSTEMPEL]
Datum/Uhrzeit der Klassifizierung: [ZEITSTEMPEL]
Beschreibung: [KURZBESCHREIBUNG]
Betroffene Services: [SERVICES]
Geschätzte Kundenauswirkung: [ANZAHL / BESCHREIBUNG]
Ergriffene Maßnahmen: [ZUSAMMENFASSUNG]

Vorab genehmigte Containment-Aktionen

Lassen Sie diese im Voraus vom Management genehmigen, damit Ihr Team während eines Live-Incidents ohne zusätzliche Autorisierung handeln kann:

• Deaktivierung eines kompromittierten Benutzerkontos
• Widerruf aller Refresh Tokens für einen Benutzer oder Service Principal
• Isolation einer VM durch Anwendung einer Deny-All-NSG
• Deaktivierung eines kompromittierten Service Principals
• Blockierung einer IP-Adresse in der Azure Firewall
• Rotation von Secrets in Key Vault
• Deaktivierung des externen Zugriffs auf ein Storage Account

Phase 2: Identifikation

Identifikation bedeutet die Bestätigung, dass ein Sicherheitsereignis ein tatsächlicher Incident ist, die Bestimmung seines Umfangs und die Klassifizierung seines Schweregrads.

Detection-Quellen in Azure

Priorisieren Sie diese Alertquellen nach Zuverlässigkeit:

Hohe Zuverlässigkeit (sofort untersuchen):

• Defender for Cloud Alerts mit hohem Schweregrad
• Sentinel Fusion Alerts (Multi-Stage-Angriffserkennung)
• Sentinel Analytics Rules, die bekannte Angriffsmuster erkennen
• Defender for Identity Alerts (Lateral Movement, Credential Theft)

Mittlere Zuverlässigkeit (innerhalb SLA untersuchen):

• Defender for Cloud Alerts mit mittlerem Schweregrad
• Benutzerdefinierte Sentinel Analytics Rules
• Entra ID Identity Protection Risky-Sign-In-Erkennungen (mittleres+ Risiko)

Initial-Triage-Runbook

Wenn ein Alert ausgelöst wird, sollte der diensthabende Analyst dieser Abfolge folgen:

1. Alert-Details lesen. Öffnen Sie den Sentinel Incident. Prüfen Sie die Entities (Benutzer, IPs, Hosts, Ressourcen), die Timeline und die zugeordneten MITRE ATT&CK-Techniken.

2. Auf verwandte Incidents prüfen. Verwenden Sie Sentinels Investigation Graph, um verbundene Entities zu identifizieren.

3. Blast Radius bewerten. Fragen Sie Log Analytics nach allen Aktivitäten der betroffenen Entities in den letzten 24 Stunden ab:

union SigninLogs, AuditLogs, AzureActivity
| where TimeGenerated > ago(24h)
| where Identity == "kompromittierter-user@domain.com"
    or CallerIpAddress == "verdaechtige-ip"
| project TimeGenerated, OperationName, Identity, CallerIpAddress, ResourceGroup, Result
| sort by TimeGenerated asc

4. Schweregrad klassifizieren:

5. Incident deklarieren. Ab Schweregrad Mittel oder höher formell einen Incident deklarieren und mit Phase 3 beginnen.

Phase 3: Eindämmung

Eindämmung muss schnell und entschieden erfolgen. In Cloud-Umgebungen wird Eindämmung primär durch Identity-Kontrollen und Netzwerksegmentierung erreicht.

Kurzfristige Containment-Aktionen

Kompromittiertes Benutzerkonto:

# Konto deaktivieren
Set-AzureADUser -ObjectId "user@domain.com" -AccountEnabled $false

# Alle Sessions widerrufen
Revoke-AzureADUserAllRefreshToken -ObjectId "user@domain.com"

# Passwort zurücksetzen
Set-AzureADUserPassword -ObjectId "user@domain.com" `
  -Password (ConvertTo-SecureString "TempP@ss$(Get-Random)" -AsPlainText -Force) `
  -ForceChangePasswordNextLogin $true

Kompromittierter Service Principal:

# Alle Credentials des Service Principals entfernen
Get-AzADServicePrincipal -DisplayName "kompromittierter-sp" |
  Get-AzADSpCredential | ForEach-Object {
    Remove-AzADSpCredential -ObjectId $_.ObjectId -KeyId $_.KeyId
}

Kompromittierte VM:

# Deny-All-NSG anwenden, um die VM zu isolieren (Beweise bleiben erhalten)
$nsg = New-AzNetworkSecurityGroup -Name "IR-Quarantine-NSG" `
  -ResourceGroupName "IR-RG" -Location "westeurope" `
  -SecurityRules @(
    New-AzNetworkSecurityRuleConfig -Name "DenyAllInbound" -Priority 100 `
      -Direction Inbound -Access Deny -Protocol * `
      -SourceAddressPrefix * -SourcePortRange * `
      -DestinationAddressPrefix * -DestinationPortRange *
    New-AzNetworkSecurityRuleConfig -Name "DenyAllOutbound" -Priority 100 `
      -Direction Outbound -Access Deny -Protocol * `
      -SourceAddressPrefix * -SourcePortRange * `
      -DestinationAddressPrefix * -DestinationPortRange *
)
$nic = Get-AzNetworkInterface -Name "kompromittierte-vm-nic"
$nic.NetworkSecurityGroup = $nsg
Set-AzNetworkInterface -NetworkInterface $nic

Beweissicherung

Vor der Beseitigung Beweise sichern:

• VM-Disks snapshotten vor jeder Remediation. Erstellen Sie Snapshots von OS- und Daten-Disks in einer separaten, abgesicherten Resource Group.
• Sentinel Incident exportieren mit allen zugehörigen Events, Entities und Timeline.
• NSG Flow Logs erfassen für den relevanten Zeitraum.
• Azure Activity Logs exportieren für die betroffenen Subscriptions.
• Key Vault Audit Logs sichern, falls Secrets möglicherweise zugegriffen wurden.

Verwenden Sie ein Immutable Storage Account (mit Legal Hold) für die Beweisspeicherung. Dies sichert die Chain of Custody für potenzielle rechtliche Verfahren.

Phase 4: Beseitigung

Die Beseitigung entfernt den Brückenkopf des Angreifers aus Ihrer Umgebung.

Gängige Beseitigungsmaßnahmen

• Alle Credentials rotieren, auf die die kompromittierte Identity Zugriff hatte
• Persistenzmechanismen entfernen. Prüfen Sie: neu erstellte Service Principals, modifizierte Conditional Access Policies, neue OAuth App Consents, hinzugefügte Federation Trusts, modifizierte Automation Runbooks
• Die Schwachstelle patchen, die den initialen Zugriff ermöglichte
• Entra ID Audit Logs prüfen auf Konfigurationsänderungen durch die kompromittierte Identity

Beseitigungsverifizierung

// Prüfung auf neue Service Principals während des Incident-Fensters
AuditLogs
| where TimeGenerated between (datetime("2026-04-10") .. datetime("2026-04-15"))
| where OperationName == "Add service principal"
| project TimeGenerated, InitiatedBy, TargetResources

// Prüfung auf OAuth Consent Grants während des Incident-Fensters
AuditLogs
| where TimeGenerated between (datetime("2026-04-10") .. datetime("2026-04-15"))
| where OperationName has "Consent to application"
| project TimeGenerated, InitiatedBy, TargetResources

Phase 5: Wiederherstellung

Die Wiederherstellung stellt den Normalbetrieb wieder her. Gehen Sie bedacht vor — übereilte Wiederherstellung führt häufig zur Wiedereinführung der Bedrohung.

Wiederherstellungs-Checkliste

1. Konten reaktivieren mit neuen Credentials und erweitertem Monitoring
2. Services wiederherstellen aus bekannt guten Backups oder per Redeployment aus Infrastructure-as-Code
3. Security Controls validieren — bestätigen, dass Defender Alerts feuern, Sentinel Rules aktiv sind, Conditional Access Policies durchgesetzt werden
4. Erweitertes Monitoring implementieren für die nächsten 30 Tage
5. Lösung kommunizieren an Stakeholder
6. Regulatorische Berichte einreichen falls zutreffend (DORA-Zwischen- und Abschlussberichte, DSGVO-Breach-Notification, NIS2-Meldung)

Phase 6: Lessons Learned

Führen Sie innerhalb von 5 Arbeitstagen nach der Wiederherstellung eine Post-Incident-Review durch. Dies ist nicht optional — hier verbessert sich Ihr Sicherheitsprogramm.

Post-Incident-Review-Template

Timeline-Rekonstruktion: Erstellen Sie eine minutengenaue Timeline von der Erkennung bis zur Wiederherstellung. Identifizieren Sie Verzögerungen und ihre Ursachen.

Root-Cause-Analyse: Was war der initiale Zugriffsvektor? Was hat den Angriff ermöglicht? Welche Erkennungslücken bestanden?

Was gut funktioniert hat: Welche Detection Rules haben ausgelöst? Welche Containment-Aktionen waren effektiv?

Was verbessert werden muss: Wo gab es Verzögerungen? Welche manuellen Schritte sollten automatisiert werden?

Metriken:

• Time to Detect (TTD): Wie lange vom initialen Compromise bis zum ersten Alert?
• Time to Contain (TTC): Wie lange vom ersten Alert bis zur Eindämmung?
• Time to Eradicate (TTE): Wie lange von der Eindämmung bis zur Beseitigung?
• Time to Recover (TTR): Wie lange von der Beseitigung bis zum Normalbetrieb?

Sentinel-Automatisierung: Das Gesamtbild

Erstellen Sie Sentinel Playbooks, die die hochzuverlässigen Containment-Aktionen automatisieren:

Jedes Playbook sollte monatlich als Teil Ihrer IR-Readiness-Übungen getestet werden.

Fazit

Ein Incident-Response-Playbook, das in einem Dokumentenmanagementsystem liegt und nie getestet wird, ist schlimmer als nutzlos — es vermittelt falsches Vertrauen. Bauen Sie Ihr Playbook in Ihr Tooling ein. Automatisieren Sie, was automatisiert werden kann. Testen Sie, was nicht automatisiert werden kann. Und überprüfen Sie unermüdlich.

Wenn Sie Hilfe beim Aufbau oder Stresstest Ihrer Azure-Incident-Response-Fähigkeit benötigen, kontaktieren Sie uns unter mbrahim@conceptualise.de. Wir bringen praxiserprobte IR-Erfahrung in Azure-Umgebungen ein und helfen Teams, sich auf Incidents vorzubereiten, bevor sie passieren.