Incident Response Plan für KMU: Praxis-Runbook

Warum die meisten Incident Response Pläne im Ernstfall versagen

Fast jedes Schweizer KMU hat irgendwo ein Word-Dokument namens “IT-Notfallplan.docx”, das vor drei Jahren für ein Audit geschrieben wurde und seither niemand mehr geöffnet hat. Am Tag X - 3 Uhr morgens, die Produktionsleitsysteme sind verschlüsselt, das Telefon klingelt im Minutentakt - stellt sich heraus: Der Plan liegt auf dem Fileserver, der gerade verschlüsselt ist. Die Eskalationsliste enthält die Mobilnummer eines Mitarbeiters, der vor einem Jahr gekündigt hat. Und niemand weiss, wer eigentlich entscheiden darf, den Internetzugang der ganzen Firma zu kappen.

Ein Incident Response Plan (IRP) ist kein Compliance-Dokument, das man einmal schreibt und abheftet. Er ist ein Betriebssystem für den schlechtesten Tag des Jahres - und wie jedes Betriebssystem muss er getestet, aktualisiert und unter Last erprobt werden. Dieser Artikel baut auf den Grundlagen aus IT-Notfallplanung und Disaster Recovery auf, fokussiert sich aber konkret auf den Cyber-Incident: forensische Sicherung, Kommunikation, Schweizer Meldepflichten, den Wiederanlauf nach Ransomware und die Lessons-Learned-Schlaufe, die aus einem Vorfall echten Lernfortschritt macht statt nur einen weiteren Ordner im Qualitätsmanagement.

Zur Abgrenzung: Ein “Major Incident” im ITIL-Sinne (siehe Major Incident Management) ist ein Prozess-Rahmen für jede Art von schwerwiegender Störung - auch ein Serverausfall ohne böswilligen Hintergrund. Ein Security Incident Response Plan ist eine Spezialisierung davon: Er bringt zusätzliche Anforderungen mit - forensische Integrität, Strafverfolgung, Meldepflichten, Kommunikationsrisiken - die ein normaler Betriebsstörungs-Prozess nicht abdeckt.

Die vier Phasen als Rückgrat des Plans

Fast jeder brauchbare IRP folgt strukturell dem NIST-Lifecycle (NIST SP 800-61), weil er sich in der Praxis bewährt hat. Die Phasen laufen nicht streng linear ab - Containment und Eradication greifen oft ineinander, und Lessons Learned beginnt eigentlich schon während des Vorfalls in Form von Notizen.

Wichtig dabei: Der Plan gehört nicht nur auf den Fileserver. Drucke den IRP aus und leg ihn physisch griffbereit (z. B. im Serverraum-Schrank und beim Vorgesetzten zuhause). Hinterlege zusätzlich eine Kopie in einem Passwort-Tresor ausserhalb der eigenen Infrastruktur (z. B. Bitwarden-Organisation oder verschlüsseltes Cloud-Dokument). Wenn dein Plan nur auf dem verschlüsselten Fileserver liegt, hast du am Tag X keinen Plan.

Rollen: Wer entscheidet, wenn niemand mehr Zeit zum Diskutieren hat

Das grösste organisatorische Problem in KMU ist nicht fehlendes Fachwissen, sondern fehlende Entscheidungsbefugnis unter Zeitdruck. Ein minimales Incident Response Team (IRT) braucht klar benannte Rollen - auch wenn eine Person mehrere davon in Personalunion übernimmt:

• Incident Commander (IC) - trifft operative Entscheide (z. B. “wir trennen jetzt das WAN”), koordiniert alle Beteiligten, ist NICHT zwingend der technisch Involvierteste. Meist die IT-Leitung oder Geschäftsleitung.
• Technical Lead - führt die technische Analyse und Eindämmung, meist der Senior-Systemadministrator oder externer IR-Dienstleister.
• Kommunikationsverantwortliche/r - steuert interne und externe Kommunikation, Medienanfragen, Kundeninformation.
• Rechtlich/Compliance - bewertet Meldepflichten (revDSG, branchenspezifisch), Vertragsverpflichtungen gegenüber Kunden, Strafanzeige.
• Business Owner - vertritt die betroffenen Fachbereiche (Produktion, Verkauf, HR) und entscheidet über Priorisierung bei der Wiederherstellung.

Der externe IR-Dienstleister gehört dabei schon vor dem Vorfall in den Plan: Wer erst am Tag des Angriffs anfängt, einen forensischen Dienstleister zu suchen, verliert wertvolle Stunden - und viele DFIR-Firmen (Digital Forensics & Incident Response) haben Wartelisten. Schliesse im Voraus einen Retainer-Vertrag ab oder halte mindestens zwei Kontakte mit Rahmenvereinbarung bereit. Cyber-Versicherungen verlangen das ohnehin oft als Bedingung für die Police.

Schweregrad-Klassifizierung: Nicht jeder Vorfall ist eine Krise

Damit nicht jede Phishing-Mail eine Vollalarm-Eskalation auslöst und umgekehrt eine echte Kompromittierung nicht als “Ticket P3” versandet, braucht es eine klare Severity-Matrix, die vorab festgelegt wird:

Diese Tabelle gehört in jeden IRP als Anhang - inklusive der Frage, wer die Einstufung im Zweifel vornimmt (Vorschlag: der diensthabende Technical Lead, mit Eskalationsrecht nach oben, nie nach unten).

Forensische Sicherung: Isolieren, nicht löschen

Der grösste und teuerste Fehler in der ersten Stunde eines Vorfalls ist Aktionismus: Der Reflex, den infizierten Rechner sofort neu aufzusetzen oder die Malware “wegzuputzen”. Das zerstört Beweismittel, die du für Versicherung, Strafanzeige und die eigentliche Root-Cause-Analyse brauchst - und oft weisst du in der ersten Stunde noch gar nicht, wie weit sich der Angreifer schon bewegt hat.

Praktisches Vorgehen bei der Isolation

Netzwerk-Isolation ohne Stromausfall, sortiert nach Präferenz:

1. Physische Trennung - Netzwerkkabel ziehen, WLAN-Adapter im BIOS/UEFI oder per Schalter deaktivieren. Am saubersten, keine Software-Abhängigkeit.
2. Switch-Port shutdown - Falls physischer Zugriff fehlt, den Access-Port am Switch administrativ deaktivieren (siehe VLAN-Grundlagen für Segmentierungskonzepte).
3. Firewall-Isolation als Fallback, wenn 1 und 2 nicht sofort möglich sind:

# Windows: Host mit einer restriktiven Firewall-Regel isolieren,
# OHNE den Rechner herunterzufahren - damit RAM-Forensik moeglich bleibt
New-NetFirewallRule -DisplayName "IR-Isolation-Block-All-Out" `
    -Direction Outbound -Action Block -Enabled True -Profile Any
New-NetFirewallRule -DisplayName "IR-Isolation-Block-All-In" `
    -Direction Inbound -Action Block -Enabled True -Profile Any

# Management-Zugriff fuer den Forensik-Rechner gezielt wieder erlauben
New-NetFirewallRule -DisplayName "IR-Allow-Forensic-Host" `
    -Direction Inbound -Action Allow -RemoteAddress 10.10.99.5 -Enabled True

# Linux: aehnliches Vorgehen mit nftables statt Netzwerkkabel ziehen
nft add table inet ir_isolation
nft add chain inet ir_isolation block_all { type filter hook input priority 0 \; policy drop \; }
nft add chain inet ir_isolation block_all_out { type filter hook output priority 0 \; policy drop \; }
nft add rule inet ir_isolation block_all ip saddr 10.10.99.5 accept

Reihenfolge der Beweissicherung: Order of Volatility

Sichere Daten in der Reihenfolge ihrer Flüchtigkeit - was zuerst verschwindet, sicherst du zuerst:

1. Arbeitsspeicher (RAM) und laufende Prozesse/Netzwerkverbindungen
2. Temporäre Dateisysteme, Swap/Pagefile
3. Festplatteninhalt (Disk-Image, forensisch mit Hash-Wert)
4. Logs auf entfernten Systemen (SIEM, Firewall, Domain Controller) - diese überschreiben sich mit der Zeit
5. Physische Konfiguration, Netzwerktopologie, archivierte Backups

Für die RAM- und Disk-Akquise auf Windows- und Linux-Systemen eignen sich etablierte, kostenlose DFIR-Werkzeuge:

Kommunikationsplan: Wer sagt wann was zu wem

Technische Eindämmung ist nur die halbe Miete. Ein Vorfall ohne kontrollierte Kommunikation eskaliert sozial genauso schnell wie technisch: Gerüchte verbreiten sich im Team, Kunden erfahren es zuerst aus den sozialen Medien, und die Geschäftsleitung wird von der eigenen Belegschaft überrascht.

Ein Kommunikationsplan als Teil des IRP legt für jede Zielgruppe fest: Wer informiert, über welchen Kanal, mit welchem Zeithorizont, und wer die Freigabe erteilt.

Ganz wichtig ist die Out-of-Band-Kommunikation: Wenn Exchange Online oder der eigene Mailserver kompromittiert ist, darf die Krisenkommunikation nicht über denselben Kanal laufen - der Angreifer liest sonst mit. Halte eine alternative Kommunikationsgruppe bereit (privates Signal/WhatsApp der Kernrolleninhaber, private Mailadressen) und hinterlege sie im ausgedruckten IRP.

Meldepflichten in der Schweiz: NCSC/BACS und revDSG

Die Schweizer Rechtslage rund um Cybervorfälle hat sich in den letzten Jahren deutlich verschärft. Für ein KMU sind grundsätzlich zwei unabhängige Meldepflichten relevant, die je nach Fall auch gleichzeitig greifen können.

Meldepflicht für Cyberangriffe auf kritische Infrastruktur (BACS/NCSC)

Seit dem 1. April 2025 gilt in der Schweiz eine gesetzliche Meldepflicht für Betreiber kritischer Infrastrukturen (Energie- und Wasserversorger, Transportunternehmen, Finanzsektor, Gesundheitswesen, gewisse IT-Dienstleister und weitere in der Informationssicherheitsverordnung genannte Branchen). Diese müssen einen Cyberangriff innert 24 Stunden nach Entdeckung an das Bundesamt für Cybersicherheit (BACS, vormals NCSC) melden, mit einer Nachmeldefrist von 14 Tagen für die vollständigen Details. Bis Ende der Übergangsfrist (1. Oktober 2025) gab es keine Sanktionen, seither drohen bei Nichteinhaltung Bussen.

Für “normale” KMU ausserhalb kritischer Infrastruktur ist die Meldung ans BACS freiwillig, aber dringend empfohlen: Das BACS bietet auf seiner Website ein Meldeformular für Cybervorfälle jeder Art an, wertet die Meldungen anonymisiert für Lagebilder aus und kann im Einzelfall auch technische Unterstützung oder Kontakte vermitteln.

Prüfe unbedingt, ob dein Betrieb als kritische Infrastruktur gilt: Auch scheinbar “normale” KMU können darunterfallen, z. B. als Zulieferer für Energie- oder Gesundheitsbetriebe oder als IT-Dienstleister für solche Organisationen. Prüfe die Liste der betroffenen Sektoren auf ncsc.admin.ch, bevor du die Meldepflicht als “betrifft uns nicht” abhakst.

Meldepflicht bei Datenschutzverletzungen (revDSG)

Unabhängig von der BACS-Meldepflicht greift bei jedem Vorfall mit Personendaten das revidierte Datenschutzgesetz (revDSG, in Kraft seit 1. September 2023). Zentrale Punkte:

• Meldepflicht an den Eidgenössischen Datenschutz- und Öffentlichkeitsbeauftragten (EDÖB) besteht, wenn die Datensicherheitsverletzung voraussichtlich zu einem hohen Risiko für die Persönlichkeit oder Grundrechte der betroffenen Personen führt.
• Im Gegensatz zur EU-DSGVO (72-Stunden-Frist) gilt im revDSG die Formulierung “so rasch als möglich” - keine starre Frist, aber auch kein Freibrief für Verzögerung.
• Die Schwelle liegt bewusst höher als bei der DSGVO: Nicht jede Verletzung muss gemeldet werden, sondern nur jene mit hohem Risiko (z. B. Abfluss von Gesundheitsdaten, Finanzdaten oder grossen Mengen an Kundendaten).
• Betroffene Personen selbst müssen informiert werden, wenn dies zu ihrem Schutz nötig ist oder der EDÖB dies verlangt.
• Die Meldung muss mindestens Art der Verletzung und deren Folgen/Massnahmen enthalten.

Weitere Meldewege, die oft vergessen gehen

• Strafanzeige bei der Kantonspolizei oder über die Melde- und Analysestelle für Cyberangriffe empfohlen bei jedem kriminellen Vorfall (Erpressung, Datendiebstahl) - unabhängig von einer allfälligen Schadenersatzforderung.
• Branchenspezifische Meldepflichten: Banken und Versicherungen unterliegen zusätzlich der FINMA-Meldepflicht für IKT- und Cyberrisiken; das Gesundheitswesen hat eigene kantonale Vorgaben.
• Vertragliche Meldepflichten gegenüber Kunden oder Auftraggebern (z. B. Cloud-Verträge mit expliziten Incident-Notification-Klauseln) - diese sind oft strenger und schneller als die gesetzlichen Fristen.
• Cyber-Versicherung: Fast jede Police verlangt eine unverzügliche Meldung als Bedingung für die Kostenübernahme - oft mit eigener 24/48-Stunden-Frist und Pflicht, vorab genehmigte IR-Dienstleister zu nutzen.

Wiederanlauf nach Ransomware: Das Runbook

Der Moment, in dem die Systeme wieder hochgefahren werden sollen, ist gefährlicher als er aussieht. Zu früh zurück ins Netz, und der Angreifer (oder eine noch aktive Persistenz-Mechanik) verschlüsselt ein zweites Mal - das kommt in der Praxis erschreckend oft vor.

Entscheidungsbaum: Lösegeld zahlen oder nicht?

Ransomware bestätigt, Systeme verschluesselt
  |
  +-- Funktionierendes, unversehrtes Offline-/Immutable-Backup vorhanden?
  |     |
  |     +-- JA  -> Nicht zahlen. Wiederherstellung aus Backup nach Bereinigung.
  |     |
  |     +-- NEIN -> Weiter pruefen:
  |            |
  |            +-- Daten kritisch (Existenzbedrohung) UND kein Restore moeglich?
  |            |     |
  |            |     +-- JA -> Rechtsberatung + Versicherung einbeziehen,
  |            |     |         Zahlung nur als allerletzte Option, NCSC/BACS
  |            |     |         raet grundsaetzlich von Zahlung ab
  |            |     |
  |            |     +-- NEIN -> Nicht zahlen, Datenverlust in Kauf nehmen,
  |            |                 Wiederaufbau priorisierter Systeme

Schritt-für-Schritt-Wiederanlauf

1. Scope final bestätigen - über Log-Analyse (SIEM/EDR) sicherstellen, dass alle kompromittierten Systeme identifiziert sind. Ein einziger übersehener Patient Zero reicht für eine Reinfektion.
2. Alle Zugangsdaten als kompromittiert behandeln - erzwungener Passwort-Reset für alle Benutzerkonten, insbesondere Domain-Admin- und Service-Accounts.
3. krbtgt-Konto zweimal zurücksetzen (Active Directory), mit mindestens einigen Stunden Abstand, um alle bestehenden Kerberos-Golden-Tickets ungültig zu machen:

# Auf einem Domain Controller, mit Domain-Admin-Rechten
# WICHTIG: Zweimal ausfuehren mit zeitlichem Abstand (Replikation abwarten!)
$krbtgt = Get-ADUser -Identity krbtgt
Set-ADAccountPassword -Identity $krbtgt -Reset `
    -NewPassword (ConvertTo-SecureString -AsPlainText "Kompl3x!Passwort#2026" -Force)
Get-ADReplicationUpToDatenessVectorTable -Target (Get-ADDomain).DNSRoot
# Nach vollstaendiger Replikation ueber alle DCs: zweite Runde durchfuehren

4. Neuaufbau statt Bereinigung priorisieren bei allen direkt kompromittierten Servern - ein “gesäuberter” Server bleibt ein Restrisiko, wenn Persistenz-Mechanismen übersehen wurden. Aus Golden Image/Deployment-Vorlage neu aufsetzen (siehe MDT/WDS-Deployment).
5. Restore in isolierter Quarantäne-Zone, nicht direkt ins Produktivnetz - Backups aus der Zeit vor der Kompromittierung in eine separate VLAN-Zone einspielen und dort auf Schadsoftware prüfen (siehe Backup-Strategie 3-2-1-Regel und Veeam Immutable Backup für die Architektur, die genau diesen Fall abfedert).
6. Systeme priorisiert nach Business Impact zurückbringen: Domain Controller und Kernnetzwerk zuerst, dann Fileserver/ERP, dann Peripheriesysteme. Die Priorisierungsliste gehört idealerweise schon vorher im Business-Impact-Assessment festgelegt.
7. Erhöhtes Monitoring für mindestens 30-90 Tage nach dem Wiederanlauf - Angreifer hinterlassen oft Hintertüren, die erst später aktiviert werden.
8. Externe IP-Reputation prüfen und ggf. bei Blacklisting-Diensten eine Delisting-Anfrage stellen, falls die eigene Infrastruktur für Spam/C2-Kommunikation missbraucht wurde.

Vergiss dabei die Kommunikation während des Wiederanlaufs nicht: Gib der Belegschaft und wichtigen Kunden regelmässige, auch kurze Status-Updates (“Fileserver ist seit 14:00 wieder verfügbar, E-Mail folgt bis 17:00”) - Funkstille erzeugt mehr Frustration als eine ehrliche, unvollständige Information.

Tabletop-Exercises: Trocken üben, bevor es brennt

Ein IRP, der nie geübt wurde, ist eine Theorie. Tabletop-Exercises (TTX) sind moderierte Simulationsübungen am Konferenztisch, bei denen ein fiktives Szenario Schritt für Schritt durchgespielt wird - ohne echte Systeme anzufassen. Sie sind der mit Abstand kosteneffizienteste Weg, Lücken im Plan zu finden.

Aufbau einer Tabletop-Übung

1. Szenario wählen - realistisch und auf die eigene Umgebung zugeschnitten, z. B. “Ransomware verschlüsselt den Fileserver am Freitagnachmittag um 16 Uhr” oder “Ein gestohlenes Laptop mit VPN-Zugang taucht in Fremdhänden auf”.
2. Rollen besetzen - alle im IRT definierten Rollen sollten anwesend sein, inklusive Geschäftsleitung und ggf. externem Kommunikationsberater.
3. Moderator/in mit Inject-Karten - der Moderator liefert im Laufe der Übung neue Informationen (“Inzwischen meldet ein Kunde, dass seine Daten im Darknet auftauchen”) und beobachtet, wie das Team reagiert.
4. 90-120 Minuten einplanen, danach direkt eine strukturierte Manöverkritik.
5. Ergebnisse dokumentieren - was hat funktioniert, wo gab es Verzögerung, welche Kontaktdaten waren veraltet, welche Entscheidung war unklar geregelt.

Fang dabei klein an: Die erste Tabletop-Übung muss nicht perfekt sein. Schon eine einfache 60-minütige Durchsprache mit den Kernrollen deckt erfahrungsgemäss überraschend viele Lücken auf: veraltete Telefonnummern, unklare Entscheidungsbefugnisse, fehlendes Wissen darüber, wo das Backup-Passwort liegt.

Lessons Learned: Aus dem Vorfall wirklich lernen

Die Nachbereitungsphase wird in der Hektik am häufigsten übersprungen - dabei ist sie der Teil, der den nächsten Vorfall verhindert oder zumindest verkürzt. Ein gutes Post-Incident-Review findet innert 1-2 Wochen nach Abschluss der akuten Phase statt, wenn die Erinnerung noch frisch, der Druck aber raus ist.

Blameless-Prinzip

Das wichtigste Prinzip: blameless. Ziel ist die Analyse von Prozessen und Systemen, nicht die Suche nach einem Schuldigen. Ein Team, das Angst vor Konsequenzen hat, meldet zukünftige Auffälligkeiten später oder gar nicht - das ist langfristig gefährlicher als der ursprüngliche Fehler.

Struktur des Reports

• Zeitstrahl - lückenlose Chronologie von Erkennung bis Wiederanlauf, mit Zeitstempeln.
• Ursachenanalyse - wie kam der Angreifer rein (Root Cause), nicht nur “was ist explodiert” (siehe Problem Management / Root Cause für die Methodik).
• Was hat gut funktioniert - genauso wichtig wie die Fehler, damit gute Prozesse nicht versehentlich “verbessert” (sprich: kaputt optimiert) werden.
• Kennzahlen - Mean Time to Detect (MTTD), Mean Time to Respond (MTTR), Mean Time to Recover, Kosten (intern + extern).
• Massnahmenliste mit Verantwortlichen und Fristen - ohne konkrete Owner verlaufen “Lessons Learned” erfahrungsgemäss im Sand.
• Update des IRP selbst - jede Lücke, die während des Vorfalls sichtbar wurde, muss in den nächsten Planentwurf einfliessen.

Kurze Hunting-Query als Startpunkt für die Analysephase

Wer bereits Microsoft Sentinel im Einsatz hat (siehe SIEM- und SOC-Grundlagen), kann während der Analysephase schnell nach ungewöhnlichen Anmeldungen im relevanten Zeitfenster suchen:

SigninLogs
| where TimeGenerated between (datetime(2026-07-01T00:00:00Z) .. datetime(2026-07-07T23:59:59Z))
| where ResultType != "0"
| summarize FailedAttempts = count() by UserPrincipalName, IPAddress, AppDisplayName
| where FailedAttempts > 10
| order by FailedAttempts desc

Solche Abfragen ersetzen keine forensische Tiefenanalyse, liefern aber in der ersten Stunde einen schnellen Anhaltspunkt für den Scope des Vorfalls.

Weiterlernen

• BACS - Meldepflicht für Cybervorfälle - offizielle Informationen zur Meldepflicht kritischer Infrastruktur
• BACS - Ransomware: Was nun? - Sofortmassnahmen-Checkliste des Bundes
• NIST SP 800-61 Rev. 2 - Computer Security Incident Handling Guide - das Referenzmodell für die vier IR-Phasen
• EDÖB - Meldung von Datensicherheitsverletzungen - Leitfaden zur revDSG-Meldepflicht
• Velociraptor-Dokumentation - Open-Source-DFIR-Plattform für Endpoint-Forensik
• CISA Tabletop Exercise Packages - fertige, kostenlose Szenarien für Tabletop-Übungen

Verwandte Themen: IT-Notfallplanung und Disaster Recovery, Major Incident Management, SIEM- und SOC-Grundlagen, Backup-Strategie 3-2-1-Regel, Veeam Immutable Backup, NIS2 für KMU Schweiz.