Incident Response & Threat Intelligence: der Steuerungsrahmen für Enterprise-Sicherheitsorganisationen

Das Wichtigste im Überblick

• Incident Response ohne Threat Intelligence bleibt reaktiv, Threat Intelligence ohne Incident Response bleibt folgenlos. Erst der geschlossene Regelkreis aus beidem senkt die Verweildauer eines Angreifers im Netz.
• Der Aufbau ist eine Führungsaufgabe, keine Werkzeugfrage. Entscheidend sind benannte Rollen, vordefinierte Entscheidungsbefugnisse, geübte Playbooks und eine Beweissicherung, die vor dem ersten Neustart greift.
• Threat Intelligence wird erst durch Steuerungsfragen nutzbar. Wer nicht festlegt, welche Entscheidungen die Analyse stützen soll, kauft Berichte statt Erkenntnisse.
• Der Angriffsvektor Nummer eins ist die offene Schwachstelle. Im Verizon Data Breach Investigations Report 2026 steht die Ausnutzung von Schwachstellen mit 31 Prozent erstmals an der Spitze der Erstzugriffsvektoren, nach 20 Prozent im Vorjahr.
• Die Wirksamkeit lässt sich belegen. Dwell Time, interne Erkennungsquote, Wiederholungsrate und der Anteil umgesetzter Erkenntnisse zeigen innerhalb eines Jahres, ob der Regelkreis trägt.

Was unterscheidet Incident Response von Threat Intelligence?

Incident Response ist die geordnete Reaktion auf einen eingetretenen Sicherheitsvorfall: erkennen, bewerten, eindämmen, bereinigen, wiederanlaufen, lernen. Threat Intelligence ist die systematische Analyse von Angreifern, ihren Werkzeugen und Vorgehensweisen mit dem Ziel, die eigene Abwehr vor dem Vorfall auszurichten. Getrennt betrieben, produziert das eine Hektik und das andere Papier.

Das National Institute of Standards and Technology hat die Verschränkung beider Disziplinen 2025 zur Leitidee erhoben. Die dritte Revision von NIST SP 800-61 vom April 2025 gibt die Vier-Phasen-Darstellung der Vorgängerfassung auf und beschreibt Incident Response entlang der sechs Funktionen des Cybersecurity Framework 2.0. Die Begründung im Dokument ist nüchtern: Die Details der Vorfallsbearbeitung änderten sich so häufig und unterschieden sich so stark zwischen Technologien, Umgebungen und Organisationen, dass sie sich in einer statischen Veröffentlichung nicht mehr sinnvoll festhalten ließen.

Threat Intelligence ist in dieser Systematik kein Nebenprodukt. NIST definiert Cyber Threat Intelligence als Bedrohungsinformation, die aggregiert, transformiert, analysiert, interpretiert oder angereichert wurde, um den nötigen Kontext für Entscheidungen zu liefern. Der praktische Nutzen wird im selben Dokument konkret benannt: neue Bedrohungen erkennen, die Treffsicherheit der eigenen Erkennungstechnik erhöhen und die Vorgehensweisen der Angreifer verstehen.

„CTI can be invaluable in detecting malicious activity early, reducing its impact, and shortening recovery time."Quelle: NIST, SP 800-61 Revision 3, April 2025

Warum braucht eine Organisation beides?

Eine Organisation braucht Threat Intelligence und Incident Response, da Prävention messbar durchlässig ist und weil die Angriffswege sich schneller ändern, als Schutzmaßnahmen nachgezogen werden. Drei unabhängige Datensätze zeichnen dazu ein konsistentes Bild mit einer aufschlussreichen Abweichung.

Die Abweichung bei Sophos zeigt den Methodenunterschied: Sophos befragt IT-Verantwortliche nach der selbst zugeschriebenen Ursache, Verizon und Mandiant werten forensisch festgestellte Ursachen aus. Wo keine Forensik stattfindet, bleibt die Einstiegsstelle unbekannt und wird systematisch unterschätzt. Für die eigene Standortbestimmung heißt das: Wer die Frage „Wie sind sie hereingekommen?" nach einem Vorfall nicht beantworten kann, hat keine Datenlücke, sondern eine Lücke in der Forensik-Bereitschaft.

Eine Einordnung zum Credential-Missbrauch gehört dazu, weil die 13 Prozent sonst falsch gelesen werden. Verizon zählt an dieser Stelle den Erstzugriff. Betrachtet man kompromittierte Zugangsdaten an beliebiger Stelle der Angriffskette, stehen sie mit 39 Prozent weiterhin an der Spitze.

Zwei weitere Befunde erklären, warum Reaktionsfähigkeit nicht durch mehr Prävention ersetzbar ist. Erstens schließt sich das Zeitfenster langsamer, als es sich öffnet: Die mediane Zeit bis zur Behebung bekannt ausgenutzter Schwachstellen stieg laut Verizon von 32 auf 43 Tage und nur 26 Prozent dieser Schwachstellen werden vollständig behoben, nach 38 Prozent im Vorjahr. Zweitens liegt die Ursache zunehmend außerhalb der eigenen Organisation: Bei 48 Prozent der Sicherheitsverletzungen war ein Dritter beteiligt, eine Steigerung um 60 Prozent gegenüber dem Vorjahr.

Für Deutschland kommt eine steigende Zahl der Schwachstellen hinzu: Das BSI weist im Lagebericht vom 11. November 2025 durchschnittlich 119 neue Schwachstellen pro Tag aus, ein Plus von 24 Prozent, wobei das BSI selbst anmerkt, dass ein Teil des Anstiegs auf eine geänderte Meldepolitik zurückgeht.

Wie baut man Incident Response sauber auf?

Acht Bausteine entscheiden darüber, ob ein Vorfall geordnet abläuft. Die Werkzeuge stehen in dieser Liste bewusst nicht an erster Stelle.

1. Entscheidungsbefugnis vorab klären. Wer darf ein Produktionssystem vom Netz nehmen, wer einen Vertrag mit einem Forensikdienstleister zeichnen, wer gegenüber der Aufsicht sprechen? Diese Fragen im Vorfall zu klären, kostet Stunden, die im Meldefenster fehlen.
2. Eine Incident-Command-Rolle benennen. Eine Person führt den Vorfall, koordiniert die Beteiligten und hält den Zeitplan. Sie analysiert nicht selbst. Ohne diese Trennung wird die beste technische Fachkraft zur Engstelle.
3. Schweregrade mit nachprüfbaren Kriterien definieren. An der Einstufung hängen Eskalation, Kommunikation und Meldefristen. Kriterien wie betroffene Systemklassen, Datenkategorien und Ausfallzeiten machen die Entscheidung reproduzierbar und auditierbar.
4. Playbooks für die häufigsten Fälle schreiben, nicht für alle. Ransomware, kompromittierte Geschäfts-E-Mail, Datenabfluss und Ausfall eines kritischen Dienstleisters decken den Großteil der realen Lagen ab. Jedes Playbook nennt Auslöser, erste Schritte, Beweissicherung, Entscheidungspunkte und Kommunikationsvorlagen.
5. Beweissicherung vor Wiederherstellung. Flüchtige Daten wie Arbeitsspeicher und Netzwerkverbindungen sind nach einem Neustart verloren. Wer die Reihenfolge nicht vorab festlegt, verliert die Antwort auf die Frage nach dem Einstiegsweg und damit die Grundlage jeder Nachbesserung.
6. Ausweichkommunikation bereithalten. Ist das Verzeichnisdienst- oder E-Mail-System betroffen, muss die Krisenkommunikation über einen unabhängigen Kanal laufen. Kontaktlisten gehören in eine Form, die auch ohne das eigene Netz verfügbar ist.
7. Externe Unterstützung vertraglich vorbereiten. Ein Incident-Response-Retainer regelt Reaktionszeiten, Zugriffsrechte und Haftung vorab. NIST formuliert zurückhaltend, dass Verantwortlichkeiten Dritter im Vertrag klar zu regeln seien. Praktisch heißt das: Die Vertragsverhandlung beginnt nicht am Tag des Vorfalls.
8. Üben und auswerten. Eine Tabletop-Übung mit Geschäftsleitung, Recht, Kommunikation und IT deckt in zwei Stunden mehr Lücken auf als ein Quartal Toolvaluierung. Jeder Vorfall und jede Übung endet mit einem Review, dessen Maßnahmen einen Verantwortlichen und ein Datum haben.

Der achte Punkt ist derjenige, der am häufigsten ausfällt und er ist der einzige, der den Reifegrad dauerhaft hebt. NIST macht ihn zum Kern der Systematik: Erkenntnisse aus allen Funktionen fließen in die Verbesserung und werden von dort aus in alle Funktionen zurückgespielt.

Wie wird aus Threat Intelligence ein nutzbares Produkt?

Der häufigste Fehler ist der Einkauf vor der Fragestellung. Ein Feed liefert Indikatoren, kein Feed liefert Relevanz. Nutzbar wird Threat Intelligence in folgenden vier Schritten.

Erstens: Steuerungsfragen festlegen. Welche Entscheidungen soll die Analyse stützen? Typische Fragen lauten: Welche Angreifergruppen zielen auf unsere Branche und unsere Technologien? Welche unserer Dienstleister sind attraktive Zugangswege? Welche Vorgehensweisen würden unsere aktuelle Erkennung umgehen? In der Praxis werden solche Fragen als Priority Intelligence Requirements geführt. Der Begriff stammt aus der militärischen Nachrichtendienst-Doktrin und ist etablierte Fachsprache, jedoch keine Norm; eine verbindliche Definition durch NIST, ENISA oder ISO existiert bislang nicht.

Zweitens: die drei Ebenen trennen. Strategische Analysen richten sich an Geschäftsleitung und Investitionsentscheidungen und arbeiten mit einem Horizont von Monaten bis Jahren. Operative Analysen beschreiben Kampagnen, Akteure und deren Vorgehensweisen und richten sich an Detection Engineering und Incident Response. Taktische Daten sind Indikatoren mit kurzer Halbwertszeit und gehören in die Automatisierung. Ein Bericht, der alle drei Ebenen vermischt, wird von keiner Zielgruppe vollständig gelesen und sollte daher vermieden werden.

Drittens: Relevanz filtern, bevor angereichert wird. Die Filter sind Branche, eingesetzte Technologien, Geografie und Lieferkette. Eine Kampagne gegen ein Produkt, das nicht im Einsatz ist, erzeugt keinen Handlungsbedarf und sollte auch keinen Bericht erzeugen.

Viertens: jede relevante Erkenntnis in eine Entscheidung überführen. Für eine beobachtete Vorgehensweise gibt es genau drei zulässige Ergebnisse: eine neue oder geänderte Detektionsregel, eine Maßnahme zur Härtung, oder eine dokumentierte Risikoakzeptanz. MITRE ATT&CK dient dabei als gemeinsame Sprache zwischen Analyse und Erkennung, weil sich Abdeckungslücken darüber sichtbar machen lassen. Die Version 19 erschien am 28. April 2026, aktuell ist zum Zeitpunkt dieser Recherche v19.2 (Stand September 2026).

Für die Weitergabe an Dritte hat sich das Traffic Light Protocol in Version 2.0 durchgesetzt, das seit August 2022 maßgeblich ist. Die methodische Referenz für den Austausch von Bedrohungsinformationen bleibt NIST SP 800-150 vom 4. Oktober 2016, das bis heute nicht ersetzt wurde. NIST begründet den Austausch pragmatisch damit, dass dieselben Bedrohungen mehrere Organisationen gleichzeitig treffen.

Wie greifen beide Disziplinen im Regelkreis ineinander?

Der Nutzen entsteht nicht durch die Existenz beider Funktionen, sondern durch fünf Übergaben zwischen ihnen. Jede Übergabe hat ein Ergebnis, das sich prüfen lässt.

Der Kreis schließt sich in Schritt fünf. Bleibt dieser Schritt aus, entsteht eine Erkennung, die auf dem Wissensstand des Tages ihrer Einführung stehen bleibt.

Warum dieser Kreis nötig ist, zeigt der Betriebsalltag. Orange Cyberdefense weist im Security Navigator 2026 einen realen Trichter aus: 139.373 potenzielle Vorfälle wurden analysiert, davon wurden 19.053 als tatsächliche Sicherheitsvorfälle bestätigt. Rund 86 Prozent des Aufkommens war Rauschen. Ohne Bedrohungsanalyse, die festlegt, worauf überhaupt geachtet wird, wächst dieser Trichter schneller als das Team, das ihn bearbeitet.

Welche Pflichten kommen aus NIS2, DORA und DSGVO hinzu?

Die Rechtslage hat sich 2025 und 2026 verändert.

Zwei Punkte werden in der Praxis unterschätzt. Erstens ist DORA mit vier Stunden das schärfste Regime und die Uhr startet mit der Klassifizierungsentscheidung. Damit wird die Einstufung selbst zeitkritisch und muss im Playbook vordefiniert sein, wie in Baustein drei beschrieben. Zweitens kann ein Finanzunternehmen bei einem einzigen Vorfall gleichzeitig nach DORA, nach BSIG und nach DSGVO meldepflichtig sein, an drei verschiedene Adressaten und mit drei verschiedenen Uhren.

Nach § 38 BSIG haften Geschäftsleitungen persönlich für die Umsetzung der Risikomanagementmaßnahmen und sind zur regelmäßigen Schulung verpflichtet. Das macht die oben beschriebene Tabletop-Übung zu einem Nachweis.

Welches Betriebsmodell passt zu welcher Organisation?

Die Entscheidung zwischen internem Aufbau, hybridem Modell und ausgelagertem Betrieb wird selten technisch getroffen, sondern über Personal. Der ISC2 Cybersecurity Workforce Study 2025 vom 4. Dezember 2025 meldet, dass 59 Prozent der Befragten kritischen oder erheblichen Qualifikationsbedarf sehen, nach 44 Prozent im Vorjahr. 88 Prozent hatten mindestens eine gravierende Folge für die Cybersicherheit, die auf solche Lücken zurückging. Für Deutschland beziffert der Bitkom die Lücke auf rund 109.000 fehlende IT-Fachkräfte bei einer durchschnittlichen Vakanzzeit von 7,7 Monaten.

Daraus folgt eine praktische Faustregel: 24/7-Erkennung im Eigenbetrieb erfordert realistisch acht bis zwölf Vollzeitstellen allein für die Schichtabdeckung. Wer diese Zahl nicht dauerhaft besetzen und halten kann, betreibt kein Rund-um-die-Uhr-SOC, sondern eine Bereitschaft mit Lücken.

Für den gehobenen Mittelstand ist deshalb meist die hybride Konstruktion tragfähig: Detection Engineering, Incident Command und die Steuerungsfragen der Bedrohungsanalyse bleiben im Haus, der Schichtbetrieb und die forensische Tiefe werden zugekauft. Entscheidend ist, dass die Deutungshoheit über die eigenen Prioritäten intern bleibt. Ein Dienstleister kann Erkennung betreiben, aber nicht entscheiden, welche Risiken Ihr Unternehmen tragen will.

Orange Cyberdefense betreibt dafür eine Incident-Response-Hotline mit 24/7-Erreichbarkeit und kostenfreier Ersteinschätzung; im Retainer ist ein Rückruf binnen 15 Minuten zugesagt. Unabhängig davon, wie Sie sich entscheiden: Die folgenden vier Fragen muss jede Organisation für sich selbst beantworten.

Wie können die nächsten Schritte aussehen?

1. Standort bestimmen. Erheben Sie Dwell Time, interne Erkennungsquote und Wiederholungsrate für die letzten zwölf Monate. Fehlen die Daten, ist das der erste Befund.
2. Entscheidungsbefugnisse festschreiben. Halten Sie auf einer Seite fest, wer Systeme abschalten, externe Hilfe beauftragen und gegenüber der Aufsicht sprechen darf, jeweils mit Vertretung.
3. Vier Playbooks schreiben. Ransomware, kompromittierte Geschäfts-E-Mail, Datenabfluss und Ausfall eines kritischen Dienstleisters. Mehr ist im ersten Schritt nicht nötig.
4. Steuerungsfragen für die Bedrohungsanalyse formulieren. Fünf Fragen, die Ihre Organisation wirklich beantwortet haben möchte, sind der Auftrag an jede Threat-Intelligence-Leistung, ob intern erbracht oder eingekauft.
5. Eine Übung ansetzen. Eine Tabletop-Übung mit Geschäftsleitung, Recht, Kommunikation und IT, mit Protokoll und Maßnahmenliste.
6. Retainer klären. Prüfen Sie, ob Sie im Ernstfall innerhalb von Stunden externe Forensik hinzuziehen können, vertraglich und nicht per Anruf.

Häufig gestellte Fragen (FAQ) zu Ransomware-Angriffen

Sollten wir Lösegeld zahlen?

Die Datenlage spricht dagegen. Die Zahlungsquote liegt laut Chainalysis bei 28 Prozent und damit auf einem Allzeittief. Coaxis zahlte fünf Millionen US-Dollar nicht und stand nach etwa einem Monat wieder. Umgekehrt zeigt der Fall des flachen Netzes, was passiert, wenn Backups fehlen: 500.000 Euro Lösegeld gegen den Rat des CSIRT und trotzdem über eine Million Euro Gesamtkosten. Hinzu kommen rechtliche Risiken: Die Zahlung kann insbesondere dann rechtswidrig sein, wenn die Angreifer auf Sanktionslisten stehen oder einer sanktionierten bzw. terroristischen Organisation zugeordnet werden können, da dadurch eine verbotene finanzielle Unterstützung vorliegen kann.

Schützen Backups vor moderner Ransomware?

Nur gegen den Verschlüsselungsteil, und nur wenn der Angreifer sie nicht erreicht. Im Coaxis-Fall waren die Sicherungen vom Netz isoliert. Das gab den Ausschlag. Im Fall des flachen Netzes wurden sie als Erstes gelöscht. Gegen reine Datenerpressung ändern Backups ohnehin nichts an der Veröffentlichungsdrohung.

Wie schnell müssen wir realistisch reagieren können?

Im Conti-Fall lag zwischen Anruf am späten Nachmittag und Eindämmung im Morgengrauen eine Nacht, bei einem Angreifer, der noch aktiv im Netz war. Die eigene Rufbereitschaft sollte auf Stunden ausgelegt sein, nicht auf den nächsten Werktag. Die Reaktionszeit auf Prio-1-Vorfälle liegt im CyberSOC-Betrieb bei 15 Minuten, der vollständige Abschluss im Schnitt bei 66 Stunden.

Was ist ein Compromise Assessment und wann ist es sinnvoll?

Eine gezielte forensische Untersuchung der Umgebung auf Spuren einer bereits erfolgten Kompromittierung. Sinnvoll nach dem Bekanntwerden einer massenhaft ausgenutzten Schwachstelle in eingesetzten Produkten, und immer dann, wenn Systeme wiederhergestellt wurden, bevor jemand geprüft hat, ob der Angreifer noch da ist.

Müssen wir melden, obwohl wir selbst nicht kompromittiert wurden?

Wenn ein Vorfall bei einem Dienstleister zu einer erheblichen Störung Ihrer Dienste führt, kann die Meldepflicht nach § 32 BSIG greifen. Maßgeblich ist die Erheblichkeit der Auswirkung, nicht der Ort der Kompromittierung. Der Coaxis-Fall mit 350.000 mittelbar betroffenen Unternehmen ist dafür die Blaupause.

Wie erkennen wir Datenexfiltration, wenn nichts verschlüsselt wird?

Über Ausgangsdatenverkehr, ungewöhnliche Archivierungsvorgänge auf Servern, Zugriffe auf Datenbestände außerhalb bekannter Muster und Verbindungen zu Cloud-Speichern oder Tunneldiensten. Hilfreich ist außerdem, legitime Fernwartungs- und Kopierwerkzeuge nicht nur zu kennen, sondern ihren Einsatz zu autorisieren und zu protokollieren.

Ist die Zuordnung zu einer Ransomware-Gruppe für die Reaktion relevant?

Weniger, als oft angenommen. Affiliates arbeiten markenübergreifend. Im SmokedHam-Fall wird der Akteur historisch mit DarkSide, LockBit und Hunters International in Verbindung gebracht und setzte hier Qilin ein. Die beobachteten Techniken sind aussagekräftiger als der Markenname.

Wo kann ich den Fall Coaxis im Detail nachvollziehen?

Im Dokumentarfilm „Don't Go to the Police", 56 Minuten, deutsche Fassung. Er zeigt den Fall aus Sicht des betroffenen Geschäftsführers, der Ermittler und des CERT von Orange Cyberdefense.