Folgen Regulatorische Erkennungsverpflichtungen sind die Sicherheitsziele, die DORA, NIS2, PCI DSS v4.0.1, und die SEC-Offenlegungsvorschriften von einer Organisation erfordert werden, um sie durch Erkennung, Überwachung, Protokollierung und Offenlegung zu erreichen und nachzuweisen.
Keines dieser vier Regime schreibt ein spezifisches Erkennungswerkzeug vor. Nur DORA benennt Erkennung als eigenständige Verpflichtung. Jedes Rahmenwerk verlangt ein Ergebnis: rechtzeitige Erkennung, kontinuierliche Überwachung, strukturierte Protokollierung oder rechtzeitige Offenlegung. Die Erkennungsfähigkeit ist das, was der Nachweis andeutet, nicht eine Kontrolle, die ein Regulator namentlich vorschreibt.
MITRE ATT&CK ordnet diesen Nachweis in eine Struktur, die ein Prüfer nach Gegner-Verhaltenskategorien abfragen kann. ATT&CK wird weder von DORA, NIS2, PCI DSS noch von den SEC-Vorschriften verlangt.
DORA ist lex specialis oder ein spezielles Gesetz, das Vorrang vor einem allgemeinen Gesetz hat. DORA Artikel 1(2) macht es zu einem sektorspezifischen Unionsrechtsakt für die Zwecke von NIS2 Artikel 4. Ein Finanzinstitut im DORA-Umfang wendet DORA für das IKT-Risikomanagement und die Vorfallberichterstattung an. NIS2 erreicht die nicht-finanzielle Lieferkette einer Bank, nicht die Bank selbst.
Welche Erkennungsnachweise unterstützen Verpflichtungen unter PCI DSS 4.0 und DORA?
Beide PCI DSS v4.0.1 und DORA behandeln Erkennung als Mittel zu einem beweismäßigen Zweck. Die Regulierung fragt, ob Erkennungen die Protokolle erzeugen, die die Überwachungsverpflichtung erfordert, nicht ob Erkennungen existieren.
Fünf Beweisklassen tragen diesen Nachweis. Beide Regime erfordern sie im Wesentlichen.
| Beweisklasse | PCI DSS v4.0.1 | DORA |
|---|---|---|
| Gesammelte Protokollquellen | Anforderung 10: Audit-Protokolle erfassen, Verlauf beibehalten | Artikel 9(1): kontinuierliches Überwachen und Steuern der Sicherheit und Funktionalität von IKT-Systemen; Artikel 10(3): Nutzeraktivität, IKT-Anomalien und IKT-bezogene Vorfälle überwachen |
| Eingesetzte Regeln, mit Eigentümer | Anforderung 11: Eindringungserkennung/-verhinderung, Änderungsdetektion vorhanden | Artikel 10: mehrere Kontrollebenen, definierte Alarmgrenzen und Kriterien |
| Nachweis der Auslösung | Anforderung 10: Protokolle überprüfen, Kontrollsystemausfälle erkennen | Artikel 10: Alarme ausgelöst und an verantwortliches Personal weitergeleitet |
| Änderungshistorie | Anforderung 11: Änderungs- und Manipulationserkennung | Artikel 17: dokumentierter Vorfallmanagementprozess mit Ursachenanalyse |
| Datiertes Abdeckungsbericht | Anforderung 10.5.1: Audit-Protokollverlauf für mindestens 12 Monate erhalten, die letzten drei Monate unmittelbar verfügbar (PCI SSC Dokumentbibliothek) | Artikel 10(1): Erkennungsmechanismen regelmäßig gemäß Artikel 25 getestet |
PCI DSS v4.0 wurde am 31. Dezember 2024 außer Betrieb genommen und PCI DSS v4.0.1 ist die einzige aktive Version (PCI SSC, Juni 2024). Die 51 zukunftsorientierten Anforderungen wurden am 31. März 2025 wirksam (PCI SSC, August 2024). Die H2 oben verwendet „PCI DSS 4.0“, um die Suchanfrage des Nutzers zu erfüllen.
Eine Erkennungsregel, die implementiert wird, aber keinen prüfbaren Datensatz generiert, ist für einen Prüfer unsichtbar.
Welche Erkennungs- und Überwachungspflichten erlegen DORA, NIS2, PCI DSS 4.0 und die SEC-Offenlegungsvorschriften tatsächlich auf?
Jedes Regime auferlegt eine Ergebnisverpflichtung anstelle eines Werkzeugsmandats. Die folgende Tabelle weist jeder Verpflichtung die Erkennungsnachweise zu, die sie impliziert.
| Regime | Artikel oder Anforderung | Verpflichtung | Implizierter Erkennungsnachweis |
|---|---|---|---|
| DORA | Art 9(1), Art 10(3) | Kontinuierliches Überwachen und Steuern der Sicherheit und Funktionalität von IKT-Systemen (Art 9(1)); Nutzeraktivität, IKT-Anomalien und IKT-bezogene Vorfälle überwachen (Art 10(3)) | Inventar der Protokollquellen, kontinuierliche Sammlungsergebnisse |
| DORA | Art 10(1), (2) | Anomale Aktivitäten erkennen; mehrere Kontrollschichten mit Alarmgrenzen und Kriterien, einschließlich automatischer Alarme an das für die Vorfallreaktion zuständige Personal; Erkennungsmechanismen regelmäßig gemäß Artikel 25 getestet | Regelinventar mit Eigentümern, Schwellenwertebegründung, Nachweis, dass Alarme die Reagierenden erreicht haben, Testaufzeichnungen |
| DORA | Art 17 | Erkennen, Verwalten und Benachrichtigen von IKT-bezogenen Vorfällen mit Ursachenanalyse | Prozessdokumentation, Erkennungs- und Handlungsnachweise pro Vorfall |
| DORA | Art 19 + Delegierte VO (EU) 2025/301 | Berichterstattung über schwerwiegende Vorfälle an die zuständige Behörde | Zeitgestempelte Erkennungs- und Klassifizierungsaufzeichnungen (erste Benachrichtigung innerhalb von 4 Stunden nach der Klassifizierung des Vorfalls als schwerwiegend und nicht später als 24 Stunden nach Bekanntwerden; Zwischenbericht innerhalb von 72 Stunden nach der ersten Benachrichtigung; Schlussbericht innerhalb eines Monats nach dem Zwischenbericht) |
| NIS2 | Art 21(2) | Risikomanagementmaßnahmen einschließlich Vorfallbehandlung (Punkt (b)) und Richtlinien zur Bewertung der Wirksamkeit der Maßnahmen (Punkt (f)); Überwachungs- und Protokollierungspflichten sind in den Implementierungsregeln unten festgelegt, nicht in Artikel 21 selbst | Dokumentierte Maßnahmen, Erkennungsnachweise |
| NIS2 | Art 23(4) | Benachrichtigung über wesentliche Vorfälle | Frühwarnung innerhalb von 24 Stunden nach Bekanntwerden, Vorfallbenachrichtigung innerhalb von 72 Stunden, Schlussbericht nicht später als einen Monat nach der Vorfallsbenachrichtigung |
| NIS2 | Durchführungsverordnung (EU) 2024/2690 | Überwachung und Protokollierung (Abschnitt 3.2 des Anhangs) für die elf in Artikel 1(1) genannten Entitätstypen, einschließlich verwalteter Sicherheitsdienstleister | Explizite Protokollnachweise für abgedeckte Einheiten |
| PCI DSS v4.0.1 | Anf 10 | Alle Zugriffe auf Systemkomponenten und Karteninhaberdaten protokollieren und überwachen | Audit-Protokolle mindestens täglich überprüfen (10.4.1), automatisierte Protokollüberprüfung (10.4.1.1), aufbewahrte Protokollgeschichte (10.5.1), Erkennung, Meldung und rasche Reaktion auf Ausfälle kritischer Sicherheitssysteme (10.7, 10.7.2); Text im PCI SSC Dokumentbibliothek |
| PCI DSS v4.0.1 | Anf 11 | Sicherheit von Systemen und Netzwerken regelmäßig testen | Erkennungs- und Verhinderungsprotokolle (11.5.1), Änderungsdetektionsalarme (11.5.2), Zahlungsseitenänderungs- und Manipulationserkennungsalarme (11.6.1) |
| SEC | 8-K Punkt 1.05 | Wesentliche Vorfälle innerhalb von vier Geschäftstagen nach der Wesentlichkeitsbestimmung offenlegen, die selbst ohne unangemessene Verzögerung nach Entdeckung getroffen werden muss (Formular 8-K, Punkt 1.05) | Prozess der Wesentlichkeitsbestimmung, Erkennungsnachweise für Vorfälle |
| SEC | S-K Punkt 106 | Beschreiben der Prozesse zur Bewertung, Identifizierung und Verwaltung wesentlicher Cyber-Sicherheitsrisiken im jährlichen 10-K (Punkt 1C) | Dokumentierter Risikoidentifizierungsprozess einschließlich Erkennungsfähigkeit |
DORA (Verordnung (EU) 2022/2554, in Anwendung seit dem 17. Januar 2025) ist direkt anwendbar. Ihre Meldeuhren werden von Delegierte Verordnung (EU) 2025/301gesetzt: erste Benachrichtigung innerhalb von 4 Stunden nach Klassifizierung eines Vorfalls als schwerwiegend und nicht später als 24 Stunden nach Bekanntwerden, ein Zwischenbericht innerhalb von 72 Stunden nach der ersten Benachrichtigung und ein Schlussbericht innerhalb eines Monats nach dem Zwischenbericht. Da die erste Uhr bei Erkennung und Klassifizierung startet, ist der Vorfallzeitstrahl selbst ein prüfbarer Nachweis.
NIS2 (Richtlinie (EU) 2022/2555) bindet durch das Umsetzungsrecht jedes Mitgliedstaats, nicht direkt. Die Umsetzungsfrist endete am 17. Oktober 2024 (Artikel 41). Am 7. Mai 2025 sandte die Europäische Kommission begründete Stellungnahmen an 19 Mitgliedstaaten wegen Nichtmeldung der vollständigen Umsetzung, und am 8. Juli 2026 verwies sie Irland, Spanien, Frankreich und die Niederlande an den Gerichtshof der Europäischen Union. Am 20. Januar 2026 schlug die Kommission Änderungen vor an NIS2 (COM(2026) 13), die Artikel 21(5) berühren und Ransomware-Absätze zu Artikel 23 hinzufügen, wobei die Maßnahmen nach Artikel 21(2) und die Meldeuhren nach Artikel 23(4) unverändert bleiben. Die Verpflichtung, der sich ein Käufer gegenübersieht, hängt vom Umsetzungsrecht des Mitgliedstaats ab.
Durchführungsverordnung (EU) 2024/2690, veröffentlicht am 18. Oktober 2024 und in Kraft ab dem 7. November 2024, legt spezifische Überwachungs- und Protokollierungsanforderungen fest (Anhang Abschnitt 3.2) für DNS-Dienstanbieter, TLD-Namensregister, Cloud-Computing, Rechenzentren, CDNs, verwaltete Dienstleister und verwaltete Sicherheitsdienstleister, Online-Marktplätze, Suchmaschinen, soziale Netzwerke und Vertrauensdiensteanbieter. Dies betrifft MSSPs als regulierte Einheiten in ihrem eigenen Recht, unabhängig von den Verpflichtungen ihrer Kunden.
PCI DSS v4.0.1 ist die einzige aktive Version. Die Anforderungen 10 und 11 tragen die Erkennungs- und Überwachungsverpflichtungen.
SEC (endgültige Regelveröffentlichung 33-11216, angenommen am 26. Juli 2023) ist eine Offenlegungs- und Governance-Regel, kein Nachweis-kontrollmandat. Erkennung ist abgeleitet: ein Registrant kann keine Wesentlichkeit bestimmen, ohne die Fähigkeit zu haben, Vorfälle zu erkennen und zu bewerten. Die Einhaltung von Punkt 1.05 war ab dem 18. Dezember 2023 für die meisten Registranten und ab dem 15. Juni 2024 für kleinere Berichterstattungsunternehmen erforderlich.
Welche Nachweise suchen Prüfer typischerweise, um zu bestätigen, dass unsere Erkennungssysteme effektiv sind?
Fünf Beweisklassen wiederholen sich in diesen Regimen. Ein Abdeckungsprozentsatz allein ist für keinen von ihnen ein Nachweis.
| # | Beweisklasse | Was es beweist |
|---|---|---|
| 1 | Gesammelte Protokollquellen | Welche Telemetrie aufgenommen wird, aus welchen Systemen, und dass die Sammlung kontinuierlich ist. Der Prüfer überprüft, ob die Überwachung läuft, nicht ob sie einmal konfiguriert wurde. |
| 2 | Eingesetzte Regeln | Erkennungsregeln vorhanden, jede Regel der Verpflichtung, die sie unterstützt, und ihrer ATT&CK Technik zugeordnet, wo zutreffend, mit einem Eigentümer. |
| 3 | Nachweis der Auslösung | Regeln, die auf echte oder simulierte Ereignisse ausgelöst wurden und Alarme erreichten die Reagierenden. Eine implementierte Regel, die nie ausgelöst wurde, ist aus der Sicht des Prüfers ungetestet. |
| 4 | Änderungshistorie | Wer eine Regel geändert hat, wann und warum: Versionskontrolle, eine Prüfspur und eine dokumentierte Begründung für jede Änderung. |
| 5 | Datiertes Abdeckungsbericht | Bericht zu einem bestimmten Zeitpunkt mit Datum, sodass Trend und Aktualität nachweisbar sind. Ein undatierter Bericht beweist nichts über die Zeit, in der Abdeckung bestand. |
ATT&CK fungiert als Überbrückung, die diesen Nachweis nach Gegnerverhalten abfragbar macht. Eine Technik-ID ist Metadaten, die an bereits vorhandene Nachweise (Datenquellen, implementierte Regeln, Auslösungsprotokolle) angehängt werden, sodass diese Nachweise nach Verhaltenskategorien abrufbar werden. ATT&CK wird durch keines dieser vier Regime verlangt. Es ordnet Beweise gegen die Verpflichtungen, die sie auferlegen.
Können Sie einem Prüfer zeigen, wer eine Regel geändert hat, wann und warum?
Detection-as-Code beantwortet dies. Jede Erkennungsregel ist ein versioniertes Artefakt in der Quellcodeverwaltung. Die Änderungsgeschichte dokumentiert den Autor, den Zeitstempel, die Überprüfungsgenehmigung und den Grund für die Änderung.
Dieser Verlauf wird zu spezifischen Verpflichtungen zugeordnet:
- DORA Artikel 17 erfordert einen dokumentierten Vorfallmanagementprozess mit Ursachenanalyse.
- PCI DSS v4.0.1 Anforderung 11 umfasst Änderungs- und Manipulationserkennung.
- Der Artikel 106 der SEC erwartet, dass ein Registrant seine Risikoidentifizierungsprozesse beschreibt.
Jeder Rahmen fragt, ob die Organisation Erkennungsregeln als kontrollierte Artefakte regiert, nicht nur, ob Regeln existieren.
Der operationale Test: Angenommen, eine Regel hat im letzten Quartal ausgelöst, kann das Team seine vollständige Herkunft nachweisen? Wer hat sie geschrieben, wer hat sie überprüft, wann wurde sie zuletzt geändert, warum, welche Verpflichtung sie abdeckt und welche Technik sie anspricht. Eine Erkennungsinhaltsplattform, die Regeln als versionierten Code verwaltet, produziert diesen Verlauf als Nebenprodukt des normalen Betriebs.
Wenn Regeln in einer Konsole bearbeitet werden, ohne Versionenkontrolle, hat der Prüfer keine Herkunft für den aktuellen Regelzustand. Governance von Detection-as-Code beseitigt diese Ambiguität durch die Konstruktion.
Wie wird die Erkennungsabdeckung zu einer Compliance-Position?
Die Erkennungskapazität liegt tendenziell in den Betriebsbudgets, sichtbar für den SOC-Manager, unsichtbar für den CFO. Drei Fakten machen Abdeckung zu einem Thema im Vorstandsgespräch.
- Meldeuhren starten bei Erkennung. DORAs 4-Stunden-Klassifizierungsuhr und die 4-Geschäftstage-Wesentlichkeitsuhr der SEC beginnen beide, wenn die Organisation erkennt oder sich dessen bewusst wird. Schnellere Erkennung ist der Anfang der Compliance-Zeitlinie.
- Erkennungsnachweise sind prüfbar. Die oben genannten fünf Beweisklassen sind das, was ein Prüfer überprüft. Ihre Erstellung kostet Zeit und Personal, unabhängig davon, ob das Team seine eigenen Regeln erstellt oder eine Erkennungsinhaltsquelle abonniert.
- Zeit bis zur Abdeckung ist messbar. Das Fenster zwischen der öffentlichen Bekanntmachung einer Technik und der Auslösung einer validierten Erkennung in der eigenen Umgebung der Organisation ist nachvollziehbar.
Ein Ingenieursteam beantragt Erkennungskapazität in Form von Personal und Werkzeugen. Ein Compliance-Team beantragt sie in Form von Beweiserstellung. Die zweite Rahmenstellung verbindet Erkennungsausgaben mit einer regulatorischen Verpflichtung, die der Vorstand bereits verfolgt.
Ein SOC-Haltungs-Audit erzeugt die Abdeckungskarte, die Prüfer verlangen: Regeln, die auf MITRE ATT&CK abgebildet sind, Protokollquellen, die auf dieselbe Matrix abgebildet sind, und die Lücken mit einem Plan aufgelistet.
Wo dies nicht zutrifft
Mehrere Einschränkungen gelten.
Nicht jede Verpflichtung kartiert auf Erkennung. SEC Punkt 1.05 verlangt Offenlegung, keine spezifischen Kontrollen. Artikel 21 von NIS2 und DORA umfassen sowohl Lieferketten-Sicherheit, Geschäftskontinuität als auch Zugriffsmanagement. Keines davon kartiert auf ATT&CK-Techniken. ATT&CK organisiert den Erkennungs- und Überwachungsanteil, nicht die gesamte Compliance-Oberfläche.
NIS2-Transponierung ist unvollständig. Wo das Umsetzungsrecht eines Mitgliedstaats nicht in Kraft ist, sind Artikel 21 und 23 von NIS2 nicht lokal durchsetzbar. Die vorgeschlagenen Änderungen vom Januar 2026 nummerieren Artikel 21 oder 23 nicht um.
Die SEC-Regeln werden angefochten. The Widerspruchs-Petition gegen Punkt 1.05, eingereicht am 22. Mai 2025 von fünf Banken- und Wertpapier-Verbänden (SEC Aktenzeichen Nr. 4-856), bleibt ungeklärt: Zum 21. September 2026 hat die SEC keine Änderung von Punkt 1.05 vorgeschlagen, obwohl die Petenten die Anfrage in einem Kommentarbrief im April 2026 im Rahmen der Überprüfung der Regulation S-K der Kommission erneuert hatten. Eine Stellungnahme vom 21. Mai 2024 von Erik Gerding, damals Direktor der Abteilung für Unternehmensfinanzen, klärte Punkt 1.05 ist für Vorfälle reserviert, die ein Registrant als wesentlich bestimmt hat, und ermutigte zur Offenlegung anderer Vorfälle unter einem anderen Punkt wie Punkt 8.01; die Abteilung folgte mit Ausführungen zu Compliance und Offenlegung am 24. Juni 2024.
Unteranforderungsnummern folgen v4.0.1. Die hier zitierten PCI DSS Unteranforderungen (10.4.1, 10.4.1.1, 10.5.1, 10.7, 10.7.2, 11.5.1, 11.5.2, 11.6.1) verwenden die v4.0.1-Nummerierung; der Standard selbst befindet sich in der PCI SSC Dokumentbibliothek, und Anforderung 10.7.2 gilt für alle Einheiten ab dem 31. März 2025.
ATT&CK ist ein Überbrückung, keine regulatorische Verpflichtung. Die Zuordnung von Erkennungen zu ATT&CK-Techniken organisiert Nachweise. Es erfüllt keine regulatorische Verpflichtung und keine der hier geprüften Rahmenwerke fordert es.
DORA ist lex specialis für Finanzinstitute. Eine Bank im DORA-Umfang wendet die Artikel 21 und 23 von NIS2 nicht zusätzlich für ihr eigenes IKT-Risikomanagement und die Vorfallberichterstattung an. NIS2 erreicht die nicht-finanzielle Lieferkette einer Bank, nicht die eigenen IKT-Operationen der Bank.
AUDIT BEWEISLISTE: ERKENNUNGSVERPFLICHTUNGEN
1. SAMMLE PROTOKOLLQUELLEN
[ ] Inventar der aufgenommenen Telemetriequellen
[ ] Nachweis der kontinuierlichen Sammlung (nicht zum Zeitpunkt)
[ ] Jede Quelle dem Systemen, den Vermögenswerten und
den Verpflichtungen zugeordnet, die sie abdeckt
2. EINGESETZTE REGELN
[ ] Erkennungsregeln Inventar mit benannten Eigentümern
[ ] Jede Regel der regulatorischen Verpflichtung zugeordnet, die sie unterstützt
[ ] Jede Regel einer ATT&CK-Technik zugeordnet, wo zutreffend
(Überbrückung, nicht durch Vorschrift gefordert)
[ ] Alarmgrenzen dokumentiert mit Begründung
3. NACHWEIS DER AUSLÖSUNG
[ ] Nachweis, dass Regeln auf echte oder simulierte Ereignisse ausgelöst wurden
[ ] Aufzeichnungen, dass Alarme die designierten Reagierenden erreichten
[ ] Datierten Testaufzeichnungen für Erkennungsmechanismen
(DORA Artikel 10)
4. ÄNDERUNGSHISTORIE
[ ] Versionskontrolle für jede Erkennungsregel
(Detection-as-Code)
[ ] Autor, Prüfer, Zeitstempel und Begründung pro Änderung
[ ] Überprüfungs- und Genehmigungspfad
[ ] Aufzeichnungen zur Manipulations- und Änderungsdetektion
5. DATIERTER ABDECKUNGSBERICHT
[ ] Berichte zum Zeitpunkt der Abdeckung mit Datum
[ ] Abdeckung gegen priorisierte Technikensätze gemessen,
nicht die volle ATT&CK-Matrix
[ ] Verlaufsdaten, die die Abdeckung über die Zeit zeigen
[ ] Berichte pro Umgebung (nicht eine aggregierte Zahl)
REGIME-SPEZIFISCHE PUNKTE
[ ] DORA: Alarmgrenzen dokumentiert mit Begründung
(Artikel 10)
[ ] DORA: Vorfallzeitstempel auf den Meldeuhren
(4h ab Klassifizierung / 24h ab Bekanntwerden,
72h Zwischenberichte, 1-Monats Schlussberichte)
[ ] NIS2: Nachweis der auf das nationale Umsetzungsrecht abgebildet ist,
nicht nur der Text der Richtlinie
[ ] PCI DSS v4.0.1: Protokollaufbewahrung gemäß geltender
Unteranforderungen
[ ] SEC: dokumentierter Prozess der Wesentlichkeitsbestimmung
(Punkt 1.05)
[ ] SEC: Aufsichtsrolle des Vorstands und Managementrolle beschrieben
(Punkt 106)
ANMERKUNGEN
- ATT&CK ist die Überbrückung, die verwendet wird, um diese Nachweise zu organisieren.
Es wird weder von DORA, NIS2, PCI DSS noch von den SEC-Vorschriften verlangt.
- DORA ist lex specialis: Eine Bank im DORA-Umfang wendet DORA an,
nicht die Artikel 21 und 23 von NIS2, für das IKT-Risikomanagement.
- PCI DSS v4.0.1 ist die einzige aktive Version
(v4.0 wurde am 31. Dezember 2024 außer Betrieb genommen).
- Jede regulatorische Spezifikation in diesem Dokument wird
von CISO-CTO-SME vor der Veröffentlichung validiert.
FAQ
Welche Erkennungsnachweise unterstützen Verpflichtungen unter PCI DSS 4.0 und DORA?
Beide Regime erfordern Nachweise für laufende Erkennung und Überwachung, nicht nur Nachweise dafür, dass Erkennungstools eingesetzt wurden. Die fünf Beweisklassen sind: gesammelte Protokollquellen, mit Eigentümern implementierte Erkennungsregeln, Nachweise dafür, dass diese Regeln auslösen, Änderungshistorie mit Versionskontrolle und ein datierter Abdeckungsbericht. MITRE ATT&CK organisiert diese Nachweise nach Gegner-Verhaltenskategorien. ATT&CK wird von keinem der beiden Rahmenwerke verlangt.
Welche Nachweise suchen Prüfer, um die Effektivität der Erkennungssysteme zu bestätigen?
Prüfer suchen nach fünf Beweisklassen: welche Telemetriequellen gesammelt werden und dass die Sammlung kontinuierlich ist, Erkennungsregeln, die den Verpflichtungen und ATT&CK-Techniken mit benannten Eigentümern zugeordnet sind, Nachweise dafür, dass diese Regeln auf reale oder simulierte Ereignisse auslösen, versionskontrollierte Änderungshistorie für jede Regel und ein datierter Abdeckungsbericht zum Zeitpunkt. Ein Abdeckungsprozentsatz allein, ohne die zugrunde liegenden Aufzeichnungen, ist kein Nachweis.
Erfüllt die Zuordnung von Erkennungen zu MITRE ATT&CK einen Regulator?
ATT&CK ist die Überbrückung, die Erkennungsnachweise nach Gegnerverhalten organisiert. Es macht Nachweise abfragbar und berichtsfähig nach Technik. Es erfüllt selbst keine regulatorische Verpflichtung. DORA, NIS2, PCI DSS und die SEC-Vorschriften fordern Nachweise des Betriebs: Überwachung, Erkennung, Protokollierung und Offenlegung. ATT&CK organisiert diese Nachweise. Kein hier geprüftes Rahmenwerk erfordert es.
Was sind die Vorfallberichtszeitleisten unter DORA und NIS2?
Unter DORA setzt die Delegierte Verordnung (EU) 2025/301 die Uhren für schwerwiegende Vorfälle: erste Benachrichtigung innerhalb von 4 Stunden nach der Klassifizierung des Vorfalls als schwerwiegend (nicht später als 24 Stunden nach Bekanntwerden), ein Zwischenbericht innerhalb von 72 Stunden nach der ersten Benachrichtigung und ein Schlussbericht innerhalb eines Monats nach dem Zwischenbericht. Unter NIS2 erfordern wesentliche Vorfälle eine Frühwarnung innerhalb von 24 Stunden nach Bekanntwerden, eine Vorfallbenachrichtigung innerhalb von 72 Stunden und einen Schlussbericht nicht später als einen Monat nach der Vorfallbenachrichtigung. Beide Zeitleisten beginnen bei Erkennung, wodurch der Erkennungszeitstempel selbst ein prüfbarer Nachweis wird.
SOC Prime’s Custom Content Engineering implementiert Erkennungen in Ihrem SIEM oder EDR und bietet eine hochrangige Dokumentation ihres Zwecks, ihrer Funktion und Nutzung.
