ITDR-Strategie für ISO 27001, NIS2, DORA und GDPR

Um 3:00 Uhr an einem Dienstag wurde Sarah, CISO von FinScale, durch eine Warnung geweckt, die moderne Sicherheitsverantwortliche zunehmend fürchten. Eine aktive Sitzung eines Senior-Entwicklers, die erst wenige Stunden zuvor per MFA authentifiziert worden war, wurde von einer ungewöhnlichen Quelle aus genutzt, um Schemata von Produktionsdatenbanken zu enumerieren.

Es gab keinen Malware-Beacon. Keine Ransomware-Notiz. Keinen Firewall-Exploit. Nur Identität.

Das SOC erkannte die Aktivität, doch die Reaktion verlief ungeordnet. Handelte es sich um eine MFA-Umgehung, ein gestohlenes Sitzungstoken oder eine Kompromittierung des Identitätsanbieters selbst? Wer war befugt, die aktive Sitzung zu beenden? Reichte der Widerruf des Passworts aus, oder musste das Team Refresh Tokens ungültig machen, API-Zugangsdaten rotieren und OAuth-Berechtigungen prüfen? Bis die Aktivität eingedämmt war, war der Angreifer 47 Minuten aktiv gewesen.

Am nächsten Morgen wurde aus dem Sicherheitsvorfall ein Governance-Problem. Das Leitungsorgan verlangte eine nachvollziehbare Erklärung, ob die Cyberhygiene von FinScale nach NIS2 versagt hatte. Das Compliance-Team wollte wissen, ob das Ereignis als schwerwiegender IKT-bezogener Vorfall nach DORA eingestuft werden könnte. Die Rechtsabteilung benötigte eine belastbare Antwort darauf, ob nach GDPR Article 32 auf personenbezogene Daten zugegriffen worden war und ob eine Bewertung einer Verletzung des Schutzes personenbezogener Daten erforderlich war. Der externe Auditor fragte, ob die Kontrollen nach ISO/IEC 27001:2022 wirksam betrieben wurden und nicht nur in Richtlinien dokumentiert waren.

Sarahs Problem war nicht ein Mangel an Werkzeugen. FinScale verfügte über einen Identitätsanbieter, MFA, ein SIEM, Endpoint-Kontrollen, Cloud-Protokolle und einen Incident-Response-Prozess. Das Problem war, dass Identitätsmanagement, Protokollierung, Überwachung, Incident Response, Datenschutzbewertung und Beweismittelmanagement in Silos betrieben wurden.

Das ist das ITDR-Problem des Jahres 2026. Identity Threat Detection and Response ist nicht mehr nur eine Fähigkeit des Sicherheitsbetriebs. ITDR ist eine Nachweis-Engine für die organisationsweite Einhaltung von ISO/IEC 27001:2022, NIS2, DORA und GDPR Article 32.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, die Richtliniensuite und Zenith Controls: The Cross-Compliance Guide Zenith Controls unterstützen Organisationen dabei, Identitätsangriffe von chaotischen Untersuchungen in wiederholbare, auditierbare Kontrollprozesse zu überführen.

Warum Identity Threat Detection and Response jetzt ein Thema für das Leitungsorgan ist

Identitätsangriffe funktionieren, weil sie legitime Zugriffspfade missbrauchen. Ein Angreifer, der ein Sitzungstoken stiehlt, eine bösartige OAuth-Anwendung registriert, ein Servicekonto kompromittiert oder einen Benutzer durch MFA-Push-Fatigue zur Zustimmung bewegt, kann für Systeme, die nur prüfen, ob die Authentifizierung erfolgreich war, wie ein gültiger Benutzer aussehen.

Damit unterscheidet sich ITDR von klassischer Perimeterverteidigung. Ein reifes Programm muss folgende Fragen beantworten können:

• Welche menschlichen Identitäten sowie Service-, Lieferanten- und Anwendungsidentitäten existieren?
• Welche Identitäten sind privilegiert, inaktiv, gemeinsam genutzt oder extern föderiert?
• Welche Authentifizierungsereignisse sind normal, risikobehaftet oder unmöglich?
• Welche OAuth-Berechtigungen, SaaS-Token und API-Zugangsdaten können auf sensitive Daten zugreifen?
• Welche Warnungen lösen Vorfallklassifizierung, Beweissicherung und regulatorische Entscheidungsfindung aus?
• Welche Kontrollen belegen, dass der Zugriff auf personenbezogene Daten durch geeignete technische und organisatorische Maßnahmen geschützt ist?

NIS2 macht dies zu einer Governance-Frage. Article 20 verpflichtet Leitungsorgane wesentlicher und wichtiger Einrichtungen, Maßnahmen zum Management von Cybersicherheitsrisiken zu genehmigen, deren Umsetzung zu überwachen und Schulungen zu erhalten. Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen, einschließlich Risikoanalyse, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, Bewertung der Kontrollwirksamkeit, Cyberhygiene, Schulung, Zugriffskontrolle, Asset-Management sowie Multi-Faktor-Authentifizierung oder kontinuierliche Authentifizierung, soweit angemessen.

DORA setzt Finanzunternehmen ähnlich unter Druck. Es verlangt ein dokumentiertes Rahmenwerk für das Management von IKT-Risiken, Verantwortung des Leitungsorgans, Erkennungsmechanismen, Vorfallmanagement, Klassifizierung, Berichterstattung, Resilienztests und Management von IKT-Drittparteirisiken. DORA gilt ab dem 17. Januar 2025. Für Finanzunternehmen, die zugleich unter NIS2 fallen, fungiert DORA als sektorspezifisches Regelwerk für überschneidende IKT-Risiko- und Vorfallpflichten.

GDPR ergänzt die Ebene der datenschutzrechtlichen Rechenschaftspflicht. Article 5 verlangt Integrität, Vertraulichkeit und Rechenschaftspflicht. Article 4 definiert eine Verletzung des Schutzes personenbezogener Daten weit und umfasst auch unbefugten Zugriff auf personenbezogene Daten. Article 32 verlangt geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten. Bei Identitätsvorfällen werden Protokolle, Zugriffskontrollen, Authentifizierungsaufzeichnungen und Vorfallsnachweise zentral, um zu belegen, ob personenbezogene Daten geschützt waren.

ISO/IEC 27001:2022 ist das Managementsystem, das diese Verpflichtungen zusammenführen kann. Clause 4 verlangt, dass die Organisation ihren Kontext, interessierte Parteien sowie rechtliche, regulatorische und vertragliche Anforderungen versteht. Clause 6 verlangt Risikobeurteilung, Risikobehandlung, Freigabe durch Risikoverantwortliche und aufbewahrte Nachweise. Annex A enthält Maßnahmen für Identitätsmanagement, sichere Authentifizierung, Protokollierung, Überwachung, Vorfallmanagement, Beweissicherung, Lieferantenbeziehungen, Cloud-Services und Datenschutz.

ITDR gehört in das ISMS, weil Identitätsrisiken erst dann auditierbar werden, wenn sie abgegrenzt, verantwortet, bewertet, behandelt, überwacht und verbessert werden.

Das Identitätsangriffsszenario, das Aufsichtsbehörden interessiert

Betrachten wir einen Cloud-basierten Anbieter finanzieller Workflow-Dienste für EU-Kunden. Er nutzt Microsoft 365, eine SaaS-Plattform für Kundensupport, Cloud-Infrastruktur, einen Zahlungsdienstleister und mehrere API-basierte Integrationen. Ein Senior-Supportingenieur erhält eine überzeugende Aufforderung, eine Produktivitätsanwendung erneut zu verbinden. Der OAuth-Zustimmungsdialog fordert Lesezugriff auf Postfächer und Offline-Zugriff an. Der Ingenieur genehmigt dies.

Innerhalb weniger Minuten nutzt der Angreifer das Token, um nach Kundenkennungen und Support-Anhängen zu suchen. Er enumeriert Gruppenmitgliedschaften und versucht, auf ein Administrationsportal zuzugreifen. MFA war aktiviert, aber der Angreifer benötigt das Passwort nicht erneut, weil das Token dauerhaften Zugriff gewährt. Das SOC erkennt ungewöhnlichen Postfachzugriff, eine neue OAuth-Anwendung, fehlgeschlagene Versuche am Administrationsportal und Aktivitäten aus einer ungewöhnlichen geografischen Region.

Dieses einzelne Szenario überschneidet sich mit mehreren Kontrollbereichen:

• Identitätslebenszyklus, weil Rolle und Berechtigungen des Benutzers den möglichen Schadensradius bestimmen.
• Sichere Authentifizierung, weil MFA allein den Missbrauch von Token nicht verhindert hat.
• Protokollierung und Überwachung, weil die Erkennung von Protokollen des Identitätsanbieters, von SaaS und von Anwendungen abhängt.
• Incident Response, weil Zugangsdaten, Sitzungen, Token und OAuth-Berechtigungen schnell widerrufen werden müssen.
• Beweissicherung, weil Datenexposition und regulatorische Berichterstattung folgen können.
• Lieferanten- und Cloud-Governance, weil SaaS-Protokolle und Audit-APIs Teil der Nachweiskette sind.
• Datenschutz, weil der Zugriff auf personenbezogene Daten nach GDPR bewertet werden muss.

Die bessere Frage lautet nicht: „Welches Werkzeug ist ausgefallen?“ Die bessere Frage lautet, ob die Organisation über eine konzipierte, getestete und auditierbare ITDR-Kontrollkette verfügte.

Die ISO 27001:2022-Kontrollkette hinter wirksamer ITDR

Die wirksamsten ITDR-Programme verbinden präventive, detektive, korrektive und nachweisbezogene Kontrollen.

In Zenith Controls wird ISO/IEC 27001:2022 Maßnahme 5.16 Identitätsmanagement als präventive Kontrolle behandelt, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt. Sie ist direkt mit 5.15 Zugriffskontrolle, 5.17 Authentifizierungsinformationen, 5.18 Zugriffsrechte, 5.19 Informationssicherheit in Lieferantenbeziehungen, 5.36 Einhaltung von Richtlinien, Regeln und Standards für Informationssicherheit sowie 8.2 Privilegierte Zugriffsrechte verbunden.

Das ist entscheidend, weil Identitätserkennung scheitert, wenn die Identitäts-Governance schwach ist. Ist ein Servicekonto nicht dokumentiert, eine Lieferantenidentität nicht verwaltet oder eine privilegierte Rolle ohne Verantwortlichen, kann die Überwachung zwar ein Ereignis erkennen, die Incident Handler können es aber nicht schnell einordnen.

Maßnahme 8.5 Sichere Authentifizierung ist ein weiterer ITDR-Anker. In Zenith Controls ist diese Kontrolle mit Identitätsmanagement, Authentifizierungsinformationen, privilegierten Zugriffsrechten, Beschränkung des Informationszugriffs, Überwachungstätigkeiten, Vorfallmanagement und Datenschutz für PII verbunden. Authentifizierung endet nicht beim Login. Sitzungsmanagement, Handhabung von Token, Schutz von Zugangsdaten und Nachvollziehbarkeit gehören zur selben Nachweisführung.

Maßnahme 8.16 Überwachungstätigkeiten ist das Scharnier zwischen der Erfassung von Protokollen und der Entscheidungsfindung. Sie hängt von 8.15 Protokollierung ab und unterstützt 5.25 Bewertung und Entscheidung über Informationssicherheitsereignisse, 5.26 Reaktion auf Informationssicherheitsvorfälle und ein breiteres Vorfallmanagement. Für ITDR ist 8.16 der Punkt, an dem verdächtiges Identitätsverhalten zu einem triagierten Ereignis, einem erklärten Vorfall oder einem dokumentierten False Positive wird.

Die Tabelle ist keine theoretische Zuordnung. Sie ist die praktische Nachweiskette, die ein Auditor, ein Mitglied des Leitungsorgans oder eine Aufsichtsbehörde nach einem Identitätsvorfall erwartet.

Was Clarysec-Richtlinien ergänzen: Verantwortlichkeit, Auslöser und Nachweisregeln

Identitätswerkzeuge schaffen nicht automatisch Rechenschaftspflicht. In einer Krise benötigen Incident Handler die Befugnis, Sitzungen zu widerrufen, Konten zu deaktivieren, Protokolle zu exportieren, Beweismittel zu sichern und Eskalationsentscheidungen zu treffen. Auditoren müssen erkennen können, dass diese Maßnahmen nicht improvisiert wurden.

Die Clarysec-Richtliniensuite stellt dieses Betriebsmodell bereit.

Aus der unternehmensweiten User Account and Privilege Management Policy User Account and Privilege Management Policy, Governance Requirements clause 5.9:

Die Organisation muss ein detailliertes Inventar aller aktiven und inaktiven Zugangsdaten, privilegierten Konten sowie Servicekonten auf Systemebene führen. Dieses Inventar ist fortlaufend zu aktualisieren und quartalsweise zu überprüfen.

Damit wird das Identitätsinventar zu einer expliziten Kontrollpflicht. Dies ist besonders wichtig, weil Servicekonten, API-Schlüssel und inaktive Zugangsdaten häufige blinde Flecken in ITDR-Programmen sind.

Dieselbe Richtlinie legt in Governance Requirements clause 5.8 fest:

Alle administrativen Tätigkeiten und Aktionen privilegierter Konten müssen manipulationserkennbar protokolliert und auf Anomalien oder Richtlinienverstöße überwacht werden.

Diese Klausel verbindet Privileged Access Management mit Erkennung. Eine privilegierte Aktion wird nicht nur zugelassen oder verweigert. Sie muss auf Verhalten überwacht werden, das nicht zu Benutzer, Rolle, Quelle, Zeit oder Geschäftsprozess passt.

Für kleinere Organisationen formuliert die User Account and Privilege Management Policy - SME User Account and Privilege Management Policy - SME in Enforcement and Compliance clause 8.1.1 eine prägnante Erwartung:

Die IT-Leitung muss Systemprotokolle regelmäßig auf unbefugte Zugriffsversuche, Anmeldeanomalien oder nicht genehmigte Änderungen von Berechtigungen überprüfen.

Hier beginnen viele ITDR-Programme in KMU. Es erfordert kein großes SOC. Es erfordert benannte Verantwortlichkeit und eine regelmäßige Prüfung der richtigen Identitätssignale.

Die Protokollierungsrichtlinie schafft die Nachweisgrundlage. Die Logging and Monitoring Policy - SME Logging and Monitoring Policy - SME legt in Governance Requirements clause 5.4.2 fest:

Authentifizierungsprotokolle: erfolgreiche und fehlgeschlagene Anmeldeversuche, Sitzungsdauer, MFA-Nutzung

Diese Felder sind nicht optional. Sie helfen nachzuweisen, ob das verdächtige Ereignis erfolgreiche Authentifizierung, wiederholte Fehlschläge, MFA-Nutzung, Sitzungsfortbestand oder ungewöhnliche Dauer umfasste.

Die unternehmensweite Logging and Monitoring Policy Logging and Monitoring Policy erweitert den erforderlichen Protokollumfang in Policy Implementation Requirements clause 6.1.1:

Alle abgedeckten Systeme müssen Protokolle erzeugen, die Folgendes erfassen: 6.1.1.1 Benutzerauthentifizierung und Zugriffsversuche 6.1.1.2 Aktivitäten privilegierter Benutzer 6.1.1.3 Konfigurationsänderungen 6.1.1.4 Fehlgeschlagene Zugriffsversuche oder Systemereignisse 6.1.1.5 Erkennungen von Schadsoftware und Sicherheitswarnungen 6.1.1.6 Externe Kommunikation und Auslöser von Firewall-Regeln

Konfigurationsänderungen sind bei Identitätsangriffen besonders wichtig. Angreifer fügen häufig OAuth-Berechtigungen hinzu, erstellen Weiterleitungsregeln, registrieren Geräte, ändern MFA-Methoden oder schaffen Notfallzugriffspfade.

Die Incident-Response-Richtlinie gibt den Incident Handlern anschließend Befugnisse. Die unternehmensweite Incident Response Policy Incident Response Policy legt in Policy Implementation Requirements clause 6.2.1 fest:

Das SOC muss betroffene Systeme unverzüglich isolieren, kompromittierte Zugangsdaten widerrufen oder bösartigen Datenverkehr mithilfe von Firewall- oder Endpoint-Security-Tools blockieren.

Die Incident Response Policy - SME Incident Response Policy - SME legt in Roles and Responsibilities clause 4.2.2 fest:

Führt Eindämmungs- und Wiederherstellungsmaßnahmen durch, beispielsweise durch Deaktivierung von Zugriff oder Wiederherstellung von Backups.

Für ITDR reicht der Widerruf eines Passworts nicht aus. Runbooks müssen die Deaktivierung von Konten, den Widerruf von Sitzungen, die Ungültigmachung von OAuth-Berechtigungen, die Rotation von Secrets, das Zurücksetzen von MFA-Methoden und die Prüfung delegierter Berechtigungen umfassen.

Der Umgang mit Beweismitteln ist der Unterschied zwischen Reagieren und Nachweisen. Die unternehmensweite Evidence Collection and Forensics Policy Evidence Collection and Forensics Policy legt in Governance Requirements clause 5.5 fest:

Alle gesammelten Beweismittel müssen eindeutig identifiziert, gekennzeichnet und in einem sicheren Repository gespeichert werden, mit: 5.5.1 Integritätsprüfung, etwa SHA-256-Hashwerten 5.5.2 Zeitgestempelten Zugriffsprotokollen 5.5.3 Einträgen zur Chain of Custody, die von jedem Verwahrer unterzeichnet werden

Die Evidence Collection and Forensics Policy - SME Evidence Collection and Forensics Policy - SME legt in Policy Implementation Requirements clause 6.1.1 fest:

Eine forensische Kopie oder ein Export muss immer erstellt werden; das ursprüngliche Beweismittel darf niemals direkt bearbeitet werden.

Im FinScale-Szenario bedeutet dies, dass das SOC Protokolle des Identitätsanbieters, SaaS-Audit-Protokolle, Postfachzugriffsaufzeichnungen, OAuth-Zustimmungsaufzeichnungen, Aufzeichnungen zum Sitzungswiderruf und SIEM-Warnungen in ein Beweismittel-Repository mit Integritätsschutz und Chain of Custody exportiert.

Aufbau der ITDR-Roadmap mit Zenith Blueprint

Zenith Blueprint übersetzt die Kontrollkette in Umsetzungsschritte.

In der Phase „Controls in Action“, Step 19, Technological Controls I, ist der Blueprint in Bezug auf Authentifizierung eindeutig:

Wo möglich, sollte reine Passwortauthentifizierung vermieden werden, insbesondere für Administratorkonten, Cloud-Konsolen, Fernzugriffswerkzeuge und jedes System, das dem Internet ausgesetzt ist. MFA mit einem zweiten Faktor wie Hardware-Schlüssel, mobiler App oder Biometrie ist heute eine Baseline und kein Luxus. Sie mindert die Risiken durch Diebstahl von Zugangsdaten, Phishing und Brute-Force-Angriffe.

Derselbe Schritt geht über Passwörter hinaus. Er verlangt sichere Speicherung und Übertragung von Authentifizierungsdaten, sichere Handhabung von API-Token, Sitzungskennungen und OAuth-Zugangsdaten, Geheimnismanagement für Maschine-zu-Maschine-Authentifizierung, Token-Rotation, Kontrollen der Sitzungslebensdauer, sichere Cookie-Flags und Prüfung von Authentifizierungsprotokollen.

Step 22, Organizational Controls, formalisiert den Zugriffslebenszyklus. Er leitet Teams an, Bereitstellung und Deprovisionierung mit HR zu integrieren, dokumentierte quartalsweise Berechtigungsüberprüfungen durchzuführen, Identitätstypen wie individuelle, gemeinsame und Servicekonten zu definieren, MFA für privilegierte Konten durchzusetzen, inaktive Konten zu beseitigen und Service-Zugangsdaten zu rotieren.

Step 19 beschreibt außerdem den Verbesserungspfad für Protokollierung: kritische Protokolle an ein SIEM oder einen Log-Aggregator weiterleiten, Aufbewahrung validieren, ein aktuelles Ereignis anhand von Protokollen nachverfolgen, Merkmale der Protokollintegrität dokumentieren und Warnungen für fehlgeschlagene Logins oder Rechteerweiterungen bestätigen. Zeitsynchronisierung ist entscheidend, weil die Rekonstruktion von Vorfällen scheitert, wenn Identitätsanbieter-, SaaS-, Endpoint- und Cloud-Protokolle unterschiedliche Zeitstempel aufweisen.

Step 23, Organizational Controls for 5.19 to 5.37, validiert Fähigkeiten zum Vorfallmanagement. Er verlangt einen aktuellen Incident Response Plan, definierte meldepflichtige Ereignisse, Tabletop-Übungen, dokumentierte Entscheidungen, Kommunikationsaufzeichnungen, Lessons Learned und forensische Beweissicherung wie Protokoll-Snapshots, Backups und sichere Isolation.

Eine pragmatische Clarysec-ITDR-Abfolge sieht wie folgt aus:

1. Identitätstypen und Verantwortliche definieren.
2. Authentifizierung, Token und Sitzungen absichern.
3. Authentifizierungs-, Berechtigungs- und SaaS-Protokolle erfassen.
4. Auf risikobehaftetes Verhalten überwachen.
5. Entscheidungsregeln vom Ereignis zum Vorfall definieren.
6. Beweismittel sichern.
7. Berichten, wiederherstellen und verbessern.

Ein einwöchiges ITDR-Nachweispaket

Ein fokussiertes „Nachweispaket für Identitätsvorfälle“ ist eine der schnellsten Methoden, um Lücken sichtbar zu machen. Wählen Sie ein Hochrisikoszenario aus, zum Beispiel: „Ein privilegierter SaaS-Benutzer erteilt einer nicht autorisierten OAuth-Anwendung seine Zustimmung, und das Token wird für den Zugriff auf Kundendaten verwendet.“

Erstellen Sie anschließend innerhalb einer Woche das Nachweispaket.

Nehmen Sie mindestens eine tatsächliche Nachverfolgung auf. Verwenden Sie eine harmlose aktuelle Anmeldeanomalie und zeigen Sie, wie das Team von der Warnung zur Benutzeridentität, zum Gerät, zur Quell-IP, zur MFA-Methode, zur Sitzungsdauer, zu den aufgerufenen SaaS-Ressourcen, zu den berührten Daten und zur Eindämmungsentscheidung gelangt. Wenn die Organisation diese Kette in einer Tabletop-Übung nicht rekonstruieren kann, wird sie bei einem echten Vorfall Schwierigkeiten haben.

Das Ergebnis wird zu wiederverwendbaren Nachweisen für interne Audits nach ISO/IEC 27001:2022, Tests des DORA-IKT-Vorfallprozesses, NIS2-Aufsicht über Cyberhygiene und Rechenschaftspflicht nach GDPR.

Zuordnung von ITDR zu NIS2, DORA und GDPR Article 32

Die Stärke eines einheitlichen ITDR-Modells liegt darin, dass dieselben Nachweise mehrere Verpflichtungen erfüllen und zugleich die Sprache des jeweiligen Rahmenwerks respektieren.

NIS2 Article 21 erwartet risikobasierte, verhältnismäßige technische, operative und organisatorische Maßnahmen. Für ITDR bedeutet dies Zugriffskontrolle, Asset-Management, Cyberhygiene, Schulung, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Bewertung der Kontrollwirksamkeit sowie MFA oder kontinuierliche Authentifizierung, soweit angemessen. Article 23 schafft gestufte Berichterstattung für erhebliche Vorfälle, einschließlich Frühwarnung innerhalb von 24 Stunden, Vorfallmeldung innerhalb von 72 Stunden und Abschlussbericht innerhalb eines Monats.

DORA Articles 8 to 14 verlangen die Identifizierung von IKT-Assets und Abhängigkeiten, Schutz und Prävention, Erkennungsmechanismen, Kontinuität und Wiederherstellung, Lernen und Kommunikation. Articles 17 to 19 verlangen Vorfallmanagement, Ursachenidentifizierung, Frühwarnindikatoren, Klassifizierung nach Schweregrad und Kritikalität der Dienstleistung, Eskalation, Benachrichtigung des Leitungsorgans, Meldung an die zuständige Behörde und Kundenbenachrichtigung, wenn finanzielle Interessen betroffen sind.

GDPR verlangt geeignete technische und organisatorische Maßnahmen sowie nachweisbare Rechenschaftspflicht. Bei Identitätsangriffen umfassen GDPR-Fragen, ob unbefugter Zugriff stattgefunden hat, welche personenbezogenen Daten betroffen waren, ob Schutzmaßnahmen wirksam waren und ob Schwellenwerte für die Meldung von Verletzungen des Schutzes personenbezogener Daten ausgelöst werden.

Für Fintech-Unternehmen ist das Verhältnis zwischen NIS2 und DORA relevant. DORA wird für in den Anwendungsbereich fallende Finanzunternehmen als sektorspezifisches Rahmenwerk behandelt, soweit überschneidende IKT-Risiko- und Vorfallmeldepflichten bestehen. In der Praxis sollten Organisationen ein einheitliches ITDR-Nachweismodell aufbauen und Meldeentscheidungen dem jeweils anwendbaren Rechtsweg zuordnen.

Für SaaS-, Cloud-, Managed-Service-, Managed-Security- und digitale Plattformorganisationen muss der NIS2-Geltungsbereich sorgfältig geprüft werden. NIS2 erfasst viele Sektoren aus Annex I und Annex II, einschließlich digitaler Infrastruktur, Cloud-Computing-Anbieter, Rechenzentren, Vertrauensdienste, DNS, TLD-Register, Managed Service Provider, Managed Security Service Provider, Online-Marktplätze, Suchmaschinen und Plattformen sozialer Netzwerke. Die Festlegung des Geltungsbereichs nach ISO/IEC 27001:2022 Clause 4 und die Analyse interessierter Parteien sind daher keine Formalität. Sie definieren, welche Verpflichtungen das ISMS adressieren muss.

Lieferanten- und SaaS-Identitätsrisiko

Identitätsvorfälle hängen häufig von Lieferantennachweisen ab. Kann der SaaS-Anbieter Audit-Protokolle exportieren? Zeigt er OAuth-Zustimmungsereignisse? Unterstützt er sichere Zugriffskontrollen, Protokollierung und Datenschutz? Sind Vorfallunterstützung, Datenstandort, Unterauftragsvergabe, Zugriffsrechte und Exit-Regelungen vertraglich abgedeckt?

Clarysecs Cloud Usage Policy - SME Cloud Usage Policy - SME enthält eine direkte Anforderung aus Governance Requirements clause 5.2.4:

Der Dienst stellt sichere Zugriffskontrollen, Protokollierung und Datenschutzfunktionen bereit

Dieser einfache Satz ist eine Beschaffungskontrolle. Wenn eine SaaS-Plattform die für Incident Response erforderlichen Identitätsprotokolle nicht liefern kann, erzeugt sie ein Compliance-Risiko.

DORA macht dies durch Verpflichtungen zu IKT-Drittparteirisiken ausdrücklich. Finanzunternehmen bleiben für die Einhaltung verantwortlich, müssen Register der IKT-Dienstleistungsverträge führen, kritische oder wichtige Funktionen unterscheiden, Due Diligence durchführen, Konzentrationsrisiken bewerten, Audit- und Zugriffsrechte aufnehmen, Vorfallunterstützung definieren und Exit-Strategien sicherstellen.

In Zenith Controls ist ISO/IEC 27001:2022 Maßnahme 8.16 Überwachungstätigkeiten mit 5.22 Überwachung, Überprüfung und Änderungsmanagement von Lieferantendienstleistungen verbunden. Dies spiegelt die operative Realität wider. Warnungen des Identitätsanbieters, SaaS-Audit-Protokolle, Cloud-Administratoraktivitäten und Konten von Managed Service Providern bilden gemeinsam die ITDR-Angriffsfläche.

Wie Auditoren ITDR bewerten werden

Ein starkes ITDR-Programm sollte mehreren Audit-Perspektiven standhalten. Jede Zielgruppe stellt andere Fragen, aber die Nachweise sollten aus demselben Kontrollsystem stammen.

Ein Auditor nach ISO/IEC 27001:2022 wird fragen, ob Identitätsbedrohungen in der Risikobeurteilung enthalten sind, ob Risikoverantwortliche die Behandlung genehmigt haben, ob die Anwendbarkeitserklärung (Statement of Applicability, SoA) relevante Annex A-Maßnahmen enthält, ob Richtlinien umgesetzt sind und ob Nachweise zeigen, dass Kontrollen betrieben werden. Er kann ein privilegiertes Konto stichprobenartig auswählen und Genehmigung, MFA-Einstellung, Protokollaktivität, Berechtigungsüberprüfung und Deprovisionierung nachverfolgen.

Ein NIST CSF 2.0-Assessor wird GOVERN-, IDENTIFY-, PROTECT-, DETECT-, RESPOND- und RECOVER-Ergebnisse untersuchen. ITDR passt natürlich in ein Profil, das auf Identitätskompromittierung, SaaS-Token-Missbrauch oder missbräuchliche Nutzung privilegierter Zugriffe ausgerichtet ist.

Ein DORA-Prüfer wird Verantwortung des Leitungsorgans, IKT-gestützte Geschäftsfunktionen, Erkennungsmechanismen, Kriterien zur Vorfallklassifizierung, Eskalation, Regeln zur Kundenkommunikation, Ursachenanalyse und IKT-Drittparteienabhängigkeiten prüfen.

Ein GDPR-Prüfer wird fragen, ob die Organisation eine angemessene Sicherheit personenbezogener Daten nachweisen kann. Er wird Zugriffsbeschränkung, Erkennung unbefugter Zugriffe, Protokolle, die zeigen, welche Daten möglicherweise aufgerufen wurden, Bewertung von Verletzungen des Schutzes personenbezogener Daten und Nachweise zur Rechenschaftspflicht prüfen.

Ein Auditor nach COBIT 2019 oder im ISACA-Stil wird Governance, Kontrollziele, Verantwortlichkeit, Leistungsüberwachung und Assurance untersuchen.

Zenith Controls ist hier nützlich, weil es als Cross-Compliance-Leitfaden dient. Es schafft keine separaten „Zenith-Kontrollen“. Es ordnet Kontrollbereiche aus ISO/IEC 27001:2022 verwandten ISO-Kontrollen, anderen Standards, Auditerwartungen und Umsetzungsbeziehungen zu.

Kennzahlen, die belegen, dass ITDR betrieben wird

Leitungsorgane und Auditoren benötigen kein rohes SIEM-Rauschen. Sie benötigen Nachweise, dass Identitätskontrollen funktionieren und verbessert werden. Nützliche ITDR-Kennzahlen umfassen:

• Anteil privilegierter Konten mit phishingresistenter MFA.
• Anzahl inaktiver Konten, die älter als der Richtlinienschwellenwert sind.
• Anzahl von Servicekonten ohne Verantwortlichen oder Rotationsdatum.
• Anteil kritischer SaaS-Plattformen, die Authentifizierungsprotokolle an das SIEM senden.
• Mittlere Zeit bis zur Erkennung verdächtiger Identitätsaktivität.
• Mittlere Zeit bis zum Widerruf kompromittierter Sitzungen und Token.
• Anzahl genehmigter, abgelehnter oder entfernter OAuth-Anwendungen.
• Anteil von Identitätsvorfällen mit vollständigen Nachweispaketen.
• Anzahl überfälliger Feststellungen aus Berechtigungsüberprüfungen.
• Anzahl von Lieferantenplattformen ohne erforderliche Identitätsprotokolle.

Diese Kennzahlen sollten in die ISO/IEC 27001:2022-Managementbewertung, die NIS2-Governance-Aufsicht, die DORA-IKT-Risikoberichterstattung und GDPR-Diskussionen zur Rechenschaftspflicht einfließen.

Häufige ITDR-Audit-Feststellungen und Abhilfen

Clarysec sieht regelmäßig fünf wiederkehrende Feststellungen.

Erstens aktivieren Organisationen MFA, überwachen aber das MFA-Verhalten nicht. Beheben Sie dies durch Protokollierung von Änderungen an MFA-Methoden, fehlgeschlagenen Challenges, unmöglichen Reisen, Registrierung neuer Geräte und wiederholten Push-Versuchen.

Zweitens sind Servicekonten von der Identitäts-Governance ausgenommen. Beheben Sie dies, indem Sie Konten auf Systemebene inventarisieren, Verantwortliche zuweisen, Secrets rotieren, eingebettete Zugangsdaten entfernen und anomales API-Verhalten überwachen.

Drittens ist SaaS-Zustimmung nicht verwaltet. Beheben Sie dies, indem Sie Benutzerzustimmung beschränken, OAuth-Anwendungen prüfen, neue Berechtigungen überwachen, genehmigte Integrationen dokumentieren und ungenutzte Anwendungen entfernen.

Viertens werden Beweismittel während der Untersuchung verändert. Beheben Sie dies, indem Sie die Regel der Evidence Collection and Forensics Policy befolgen: forensische Kopien oder Exporte erstellen, Originale niemals direkt bearbeiten und Beweismittel mit Hashwerten und Chain-of-Custody-Aufzeichnungen speichern.

Fünftens ist die Vorfallklassifizierung zu langsam. Beheben Sie dies, indem Sie Schwellenwerte für Identitätsereignisse vorab definieren, einschließlich Kompromittierung privilegierter Konten, Zugriff auf personenbezogene Daten, SaaS-Token-Missbrauch mit Kundenauswirkung, Störung kritischer Services und Kompromittierung von Lieferantenidentitäten.

Jede Feststellung hat eine Kontroll-, Richtlinien- und Nachweisantwort. Das ist der praktische Wert eines einheitlichen ITDR-Programms: Es definiert, was verantwortet, überwacht, getestet, nachgewiesen und verbessert werden muss.

Identitätsrisiko in auditfähige Nachweise überführen

Wenn Ihr nächster Identitätsvorfall morgen eintreten würde: Könnten Sie nachweisen, wer worauf zugegriffen hat, wie die Authentifizierung erfolgte, welches Token oder welche Sitzung verwendet wurde, welche Daten berührt wurden, wer die regulatorische Klassifizierung entschieden hat und welche Korrekturmaßnahmen abgeschlossen wurden?

Wenn die Antwort unsicher ist, beginnen Sie mit einem fokussierten ITDR-Readiness-Sprint.

Nutzen Sie Zenith Blueprint, um den Umsetzungspfad über Authentifizierung, Zugriffslebenszyklus, Protokollierung, Überwachung, Incident Response und Beweismittelmanagement zu strukturieren. Nutzen Sie Clarysecs Richtlinien zu Zugriffskontrolle, Protokollierung, Cloud, Incident Response und Forensik, um Verantwortlichkeit und Reaktionsbefugnisse zuzuweisen. Nutzen Sie Zenith Controls, um Identitätsmanagement, sichere Authentifizierung und Überwachungstätigkeiten ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 und Auditerwartungen zuzuordnen.

Das Ziel ist einfach: Identitätsangriffe müssen erkennbar, eindämmbar, meldbar und belastbar nachweisbar sein.

Clarysec kann Sie dabei unterstützen, ein ITDR-Nachweispaket aufzubauen, es anhand eines Tabletop-Szenarios zu testen und die Feststellungen in einen Risikobehandlungsplan zu überführen, den Ihr Leitungsorgan, Ihre Aufsichtsbehörde und Ihr Auditor verstehen. Beginnen Sie mit der Prüfung der Logging and Monitoring Policy, der User Account and Privilege Management Policy - SME, von Zenith Blueprint und Zenith Controls, und planen Sie anschließend eine ITDR-Readiness-Bewertung, um Identitätsrisiken in auditfähige Nachweise zu überführen.