Incident Response

Warum Sie Incident Response brauchen¶

Die Frage ist nicht OB ein Vorfall passiert, sondern WANN. Organisationen ohne IR-Prozess:

• Erkennen spaet — durchschnittliche Verweildauer (Angreifer im Netzwerk unerkannt) betraegt 204 Tage
• Reagieren chaotisch — wer macht was? Wer entscheidet? Wer kommuniziert?
• Wiederholen Fehler — derselbe Vorfall drei Monate spaeter, weil die Root Cause nie behoben wurde
• Eskalieren falsch — entweder zu spaet oder an die falschen Personen

SIEM & Erkennung¶

Datensammlung¶

Wir zentralisieren Sicherheitsereignisse aus der gesamten Infrastruktur:

• Infrastruktur — Firewalls, VPN, Load Balancer, DNS-Server
• Identitaet — Azure AD/Okta Login-Events, MFA-Fehler, privilegierter Zugriff
• Anwendung — WAF-Logs, API Gateway, Anwendungssicherheitsereignisse
• Endpunkt — EDR (CrowdStrike, Defender), Antivirus, Geraete-Compliance
• Cloud — Azure Activity Log, AWS CloudTrail, GCP Audit Log

Korrelationsregeln¶

Rohdaten ohne Korrelation sind Rauschen. Wir bauen Erkennungsregeln fuer:

• Brute Force — N fehlgeschlagene Logins von einer IP in M Minuten
• Lateral Movement — Ungewoehnliche Service-zu-Service-Kommunikation
• Privilege Escalation — Benutzer erhaelt Admin-Rolle, ungewoehnliche sudo-Nutzung
• Datenexfiltration — Grosse Datenuebertragung an unbekanntes Ziel
• Credential Abuse — Login von unmoegliciem Standort (GeoIP), Credential-Stuffing-Muster

Anomalie-Erkennung¶

ML-Modelle zur Erkennung unbekannter Bedrohungen:

• Baseline normalen Verhaltens pro Benutzer, pro Service
• Abweichungen bei Zugriffsmustern, Datenvolumen, API-Nutzung
• Alerting mit Kontext — nicht „Anomalie erkannt”, sondern „Benutzer X hat auf 500 Datensaetze in DB zugegriffen, Durchschnitt ist 20”

Runbooks¶

Runbook-Struktur¶

Jedes Runbook folgt einer einheitlichen Struktur:

1. Erkennung — Wie manifestiert sich der Vorfall? Welcher Alert loest ihn aus?
2. Triage — Ist es ein realer Vorfall oder ein False Positive? Welcher Schweregrad?
3. Eindaemmung — Ausbreitung stoppen. Betroffenes System isolieren.
4. Beseitigung — Ursache entfernen. Patch, Config-Aenderung, Widerruf.
5. Wiederherstellung — Normalen Betrieb wiederherstellen. Verifizierung.
6. Post-Incident — Timeline, Lessons Learned, Action Items.

Top 10 Runbooks¶

Wir schreiben Runbooks fuer die wahrscheinlichsten und schwerwiegendsten Szenarien:

1. Kompromittierte Credentials — Gestohlenes Passwort/Token, unautorisierter Zugriff
2. Ransomware — Verschluesselte Dateien, Loesegeldforderung
3. DDoS — Service nicht verfuegbar, Traffic-Spike
4. Datenverletzung — Unautorisierter Datenzugriff/-exfiltration
5. Insider-Bedrohung — Boesartige oder fahrlaessige Mitarbeiteraktion
6. Phishing — Erfolgreiches Phishing, kompromittierter Endpunkt
7. Supply Chain — Kompromittierte Abhaengigkeit, boesartiges Update
8. API-Missbrauch — Automatisiertes Scraping, Credential Stuffing
9. Cloud-Fehlkonfiguration — Offener Storage, oeffentliche Datenbank
10. Zertifikatsablauf — TLS-Zertifikat abgelaufen, Serviceunterbrechung

On-Call-Prozesse¶

Rotation und Eskalation¶

• Primaerer On-Call — Reagiert auf Alerts. Woechentliche Rotation.
• Sekundaerer On-Call — Backup wenn Primaerer nicht innerhalb von 5 Minuten reagiert.
• Incident Commander — Fuer SEV1/SEV2. Koordiniert Reaktion, kommuniziert mit Stakeholdern.
• Eskalationsmatrix — Klar definiert: wer, wann, wie. Kein „ich rufe an wen ich finde”.

Schweregrad-Framework¶

Schweregrad	Beschreibung	Reaktionszeit	Kommunikation
SEV1	Business down, Kunden betroffen	15 Min	War Room, 15-Min-Updates, Exec-Benachrichtigung
SEV2	Degradierte Leistung, teilweiser Ausfall	30 Min	Slack-Kanal, stuendliche Updates
SEV3	Kleineres Problem, Workaround existiert	4h	Ticket, naechster Werktag
SEV4	Kosmetisch, kein Impact	Backlog	Sprint-Planung

Post-Mortem¶

Blameless-Kultur¶

Ein Post-Mortem sucht nach systemischen Ursachen, nicht nach Schuldigen. „John hat einen Fehler gemacht” ist keine Root Cause — „das System erlaubte John einen Fehler ohne Sicherheitsmechanismen zu machen” ist es.

Format¶

1. Timeline — Was passiert ist, chronologisch, mit Zeitstempeln
2. Impact — Wer betroffen war, wie lange, finanzieller Impact
3. Root Cause — Warum es passiert ist (5 Whys)
4. Beitragende Faktoren — Was die Situation verschlimmerte
5. Was gut lief — Was funktionierte (Erkennung, Kommunikation, Wiederherstellung)
6. Action Items — Spezifische Aufgaben mit Verantwortlichen und Deadlines
7. Lessons Learned — Was wir fuer naechstes Mal mitnehmen

Post-Mortem-Datenbank¶

Alle Post-Mortems an einem Ort (Confluence, Notion, Git). Durchsuchbar, getaggt. Ein neues Teammitglied, das die letzten 10 Post-Mortems liest, weiss mehr ueber das System als aus jeder Dokumentation.

Table-Top-Uebungen¶

Vorfall-Simulationen ohne realen Impact:

• Vierteljaehrliche Uebungen fuer das IR-Team
• Szenario: „Es ist Freitag 17 Uhr, ein Kunde hat eine Datenverletzung gemeldet. Was tun Sie?”
• Kommunikation, Eskalation, Entscheidungsfindung ueben
• Luecken in Runbooks und Prozessen identifizieren

Technologie¶

Elastic SIEM, Microsoft Sentinel, Splunk, Grafana Loki, PagerDuty, OpsGenie, Slack (Incident Channels), Jira (Post-Mortem Tracking), Confluence (Runbook Repository), CrowdStrike, Microsoft Defender.