Incident Response: was tun im Ernstfall

Montagmorgen, mehrere Mitarbeitende melden ungewöhnliche Anmeldeaufforderungen, ein Server reagiert deutlich langsamer als üblich und im SIEM häufen sich Warnungen. In dieser Situation entscheidet nicht allein technische Expertise über den Erfolg. Entscheidend ist, ob klar ist, wer handelt, wer informiert wird, welche Systeme geschützt werden müssen und wie Beweise gesichert werden. Incident Response schafft genau diese Struktur.

Ein Sicherheitsvorfall ist kein Beweis für individuelles Versagen. Selbst gut geschützte Unternehmen müssen damit rechnen, dass Schutzmechanismen einmal umgangen werden, Konfigurationen Lücken haben oder Mitarbeitende auf überzeugendes Social Engineering hereinfallen. Ziel ist deshalb nicht, Panik zu vermeiden, indem man Vorfälle kleinredet. Ziel ist, ruhig, nachvollziehbar und wirksam zu reagieren.

Was Incident Response leistet

Incident Response bezeichnet den vorbereiteten Umgang mit Sicherheitsvorfällen. Dazu zählen etwa kompromittierte Konten, auffällige Datenabflüsse, Schadsoftware, verdächtige Administratoraktivitäten, verlorene Geräte oder Angriffe auf Webanwendungen.

Ein guter Prozess beantwortet im Ernstfall vier Fragen:

1. Was ist passiert und welche Systeme, Daten oder Identitäten sind betroffen?
2. Wie begrenzen wir den Schaden, ohne wichtige Beweise zu zerstören?
3. Wie stellen wir einen sicheren Betrieb wieder her?
4. Was ändern wir, damit sich der Vorfall nicht wiederholt?

Nicht jede SIEM Meldung ist sofort ein Incident. Viele Hinweise sind Fehlalarme oder erklärbare Auffälligkeiten. Trotzdem braucht jeder Hinweis eine Bewertung. Wenn du erst im Ernstfall festlegst, wer diese Bewertung übernimmt, verlierst du Zeit und riskierst widersprüchliche Entscheidungen.

Den Notfallplan vor dem Vorfall vorbereiten

Ein Incident Response Plan muss im Alltag nutzbar sein. Ein langes Dokument, das im Intranet schwer auffindbar ist, hilft nachts oder unter Zeitdruck kaum. Erstelle stattdessen einen kompakten Plan mit klaren Abläufen, Kontakten und Entscheidungshilfen. Ergänzende technische Runbooks können detaillierter sein.

Der Plan sollte mindestens diese Punkte enthalten:

Bereich	Was festgelegt sein sollte
Auslöser	Welche Ereignisse eine Untersuchung auslösen, etwa Kontoübernahmen, Malware Hinweise oder Datenabfluss
Priorisierung	Kriterien für Schweregrade, zum Beispiel betroffene kritische Systeme, personenbezogene Daten oder Betriebsunterbrechungen
Rollen	Incident Lead, Technik, Kommunikation, Management, Datenschutz, Rechtsabteilung und externe Unterstützung
Kontaktwege	Erreichbare Kontakte, Vertretungen und ein Kommunikationskanal, der nicht vom betroffenen System abhängt
Sofortmaßnahmen	Vorgehen zur Eingrenzung, Beweissicherung, Dokumentation und Eskalation
Wiederherstellung	Zuständigkeiten für Backups, Freigaben, Prüfung und Rückkehr in den Regelbetrieb
Nachbereitung	Termin, Verantwortliche und Format für die Auswertung nach dem Vorfall

Lege den Plan nicht nur digital ab. Wenn das zentrale Identitätsmanagement, E Mail oder Kollaborationssystem betroffen ist, brauchen Verantwortliche alternative Kontaktwege. Dazu gehören aktuelle Telefonnummern, ein freigegebener externer Kommunikationskanal oder vorbereitete Kontaktlisten in geschützter Form.

Wichtig ist auch die Abhängigkeit von Dienstleistern. Cloud Anbieter, Managed Service Provider, forensische Dienstleister oder Softwarehersteller müssen im Plan mit Vertragsdaten, Eskalationswegen und Zuständigkeiten erfasst sein. Prüfe vorab, wer im Namen deines Unternehmens Tickets eröffnen oder Datenfreigaben erteilen darf.

Rollen, Meldeketten und Entscheidungsbefugnisse

Im Incident Response Team muss nicht jede Person alles können. Es muss aber eindeutig sein, wer Entscheidungen trifft und wer Informationen zusammenführt. Besonders problematisch sind Situationen, in denen mehrere Fachbereiche parallel handeln, ohne ihre Schritte abzustimmen.

Bewährt haben sich folgende Rollen:

• Die Einsatzleitung koordiniert den Vorfall, priorisiert Aufgaben, dokumentiert Entscheidungen und informiert das Management.
• Das technische Team analysiert Logs, Systeme, Identitäten und Netzwerkverbindungen. Es setzt abgestimmte Eindämmungsmaßnahmen um.
• Die IT Betriebsverantwortlichen stellen sicher, dass Änderungen am Betrieb nachvollziehbar und sicher umgesetzt werden.
• Datenschutz und Rechtsabteilung bewerten mögliche Meldepflichten, Vertragsfragen und den Umgang mit personenbezogenen Daten. Diese Einordnung ist keine Rechtsberatung und hängt immer vom konkreten Fall ab.
• Die Kommunikationsverantwortlichen bereiten Informationen für Mitarbeitende, Kundschaft, Partner und gegebenenfalls Öffentlichkeit vor. Technische Teams sollten externe Aussagen nicht nebenbei formulieren müssen.
• Die Geschäftsleitung entscheidet bei erheblichen Auswirkungen über Prioritäten, Risiken und notwendige Ressourcen.

Definiere für jede Rolle mindestens eine Vertretung. Kläre auch, welche Maßnahmen ohne zusätzliche Freigabe zulässig sind. Darf das Security Team ein kompromittiertes Endgerät sofort vom Netzwerk trennen? Wer darf Konten sperren? Wer entscheidet über das Abschalten eines kritischen Dienstes? Solche Entscheidungen müssen vor dem Incident geklärt werden.

Meldeketten sollten kurz sein. Wer einen Verdacht hat, braucht eine leicht erreichbare Meldestelle und muss keine technische Diagnose liefern. Mitarbeitende sollten wissen: Auffällige E Mails, unerwartete MFA Abfragen, verlorene Geräte oder ungewöhnliche Systemmeldungen werden sofort gemeldet, nicht erst nach eigener Recherche oder Rücksprache im Team.

Die ersten Schritte bei einem Sicherheitsvorfall

Wenn ein möglicher Incident eingeht, hilft eine feste Reihenfolge. Sie verhindert, dass wichtige Hinweise verloren gehen oder vorschnelle Maßnahmen den Betrieb stärker beeinträchtigen als nötig.

1. Vorfall erfassen und bewerten

Erfasse Zeitpunkt, Meldungsquelle, betroffene Systeme, Benutzerkonten, beobachtete Symptome und bereits erfolgte Maßnahmen. Halte auch Unsicherheiten fest. Eine frühe Dokumentation ist wertvoll, weil Erinnerungen und Logdaten schnell verloren gehen.

Bewerte dann die Dringlichkeit anhand klarer Kriterien:

• Sind kritische Geschäftsprozesse betroffen?
• Gibt es Hinweise auf unberechtigten Zugriff auf sensible Daten?
• Betrifft der Vorfall privilegierte Konten oder Systeme mit weitreichenden Berechtigungen?
• Ist eine Ausbreitung auf weitere Systeme erkennbar?
• Besteht akuter Handlungsbedarf, etwa durch laufende Verschlüsselung oder verdächtige Datenübertragungen?

2. Eindämmen, aber nicht blind handeln

Die Eindämmung soll weitere Schäden begrenzen. Je nach Situation kann das bedeuten, ein betroffenes Gerät vom Netzwerk zu trennen, ein Konto zu sperren, Zugangstoken zurückzusetzen oder eine verdächtige Verbindung zu blockieren.

Handle dabei abgestimmt. Ein übereiltes Neustarten, Löschen von Dateien oder Abschalten zentraler Systeme kann Beweise vernichten und die Analyse erschweren. Bei hoher Kritikalität oder unklarer Lage kann externe forensische Unterstützung sinnvoll sein. Auch dann gilt: Zugriffe, Umfang und Verantwortlichkeiten müssen klar beauftragt sein.

3. Beweise und Entscheidungen sichern

Sichere verfügbare Protokolle, Alarmmeldungen, Zeitstempel, Konfigurationsstände und relevante Kommunikationsverläufe. Dokumentiere, wer wann welche Maßnahme angeordnet und umgesetzt hat. Diese Chronologie ist wichtig für die technische Aufklärung, für interne Abstimmungen und gegebenenfalls für rechtliche Bewertungen.

Achte auf die Qualität der Zeitdaten. Unterschiedliche Zeitzonen oder nicht synchronisierte Systeme erschweren die Rekonstruktion erheblich. Eine verlässliche Zeit synchronisation gehört deshalb zur Vorbereitung.

4. Ursache beseitigen und kontrolliert wiederherstellen

Ein System einfach aus einem Backup zurückzuspielen, reicht nicht immer. Prüfe zuerst, wie der Zugriff möglich war und ob weitere Systeme oder Konten betroffen sein könnten. Sonst stellst du den Betrieb wieder her, während die Ursache fortbesteht.

Zur Beseitigung gehören je nach Befund das Schließen von Schwachstellen, das Zurücksetzen von Zugangsdaten, das Überprüfen von MFA, das Entfernen nicht benötigter Berechtigungen nach dem Least Privilege Prinzip und die Kontrolle von Persistenzmechanismen durch qualifizierte Fachkräfte. Die Wiederherstellung erfolgt schrittweise, mit Tests, verstärktem Monitoring und klarer Freigabe.

Kommunikation verhindert zusätzliche Schäden

Schweigen oder Spekulationen verschärfen viele Vorfälle. Gleichzeitig dürfen Informationen nicht unkontrolliert verbreitet werden. Lege deshalb fest, welche Zielgruppen welche Informationen erhalten.

Mitarbeitende brauchen konkrete Handlungsanweisungen, etwa verdächtige Anfragen zu ignorieren, Passwörter nicht über unsichere Wege zu teilen oder bestimmte Systeme vorübergehend nicht zu verwenden. Das Management braucht eine ehrliche Lageeinschätzung mit Auswirkungen, Risiken, offenen Fragen und nächsten Entscheidungen. Kundinnen, Kunden und Partner sollten nur über geprüfte Fakten informiert werden.

Nutze eine zentrale Lageübersicht. Dort stehen aktueller Status, betroffene Bereiche, Maßnahmen, offene Punkte, Verantwortliche und nächster Update Zeitpunkt. So vermeidest du widersprüchliche Aussagen und wiederholte Rückfragen an das technische Team.

Aus Vorfällen lernen und den Plan üben

Nach der Wiederherstellung beginnt ein oft vernachlässigter Teil: die Nachbereitung. Führe zeitnah eine sachliche Auswertung durch. Es geht nicht darum, Schuldige zu suchen, sondern Abläufe und Schutzmaßnahmen zu verbessern.

Besprecht unter anderem diese Fragen:

• Wie wurde der Vorfall entdeckt und wie viel Zeit lag bis zur Reaktion?
• Welche Logs, Alarme oder Informationen haben gefehlt?
• Waren Rollen, Kontaktwege und Freigaben eindeutig?
• Welche Kontrollmaßnahmen hätten den Vorfall früher verhindert oder begrenzt?
• Welche Aufgaben aus dem Maßnahmenplan haben eine verantwortliche Person und einen Termin?

Dokumentiere die Erkenntnisse in einem Maßnahmenregister und überprüfe die Umsetzung. Ergänze Detection Regeln, verbessere Backup Tests, passe Berechtigungen an und aktualisiere Security Awareness Inhalte, wenn der Vorfall menschliche Faktoren betraf.

Übe den Plan regelmässig mit realistischen Szenarien, zum Beispiel einer Kontoübernahme oder einem Ausfall eines zentralen Dienstes. Dabei werden Lücken in Meldeketten und Verantwortlichkeiten sichtbar, ohne dass ein echter Schaden entsteht. Sicherheitstests und Penetrationstests dürfen dabei ausschliesslich mit ausdrücklicher schriftlicher Beauftragung und klar definiertem Scope stattfinden. Ohne Auftrag sind solche Tests unzulässig und können strafbar sein.

Passende IT Security Seminare und Termine findest du bei uns auf cmt.de.