Zum Inhalt springen
Decision-State-Infrastruktur
ende
Anwendungen

Cybervorfall

ANWENDUNG / CYBERVORFALL

Was muss entschieden werden, bevor der vollständige Umfang eines Cybervorfalls bekannt ist?

Ein schwerwiegender Cybervorfall wartet nicht darauf, dass die Forensik abgeschlossen ist. Systeme müssen möglicherweise isoliert, ein Enterprise Crisis State aktiviert, regulatorische Meldepflichten bewertet und Kunden, Mitarbeitende oder Geschäftspartner informiert werden, während wesentliche Teile des Incident Scope noch unbekannt sind.

Im illustrativen Fall trifft ein Enterprise-Ransomware- und Double-Extortion-Angriff eine große europäische Unternehmensgruppe. Ein privilegierter Account wurde missbraucht, mehrere interne Systeme wurden erreicht, Ransomware-Aktivität ist bestätigt und erste Services sind beeinträchtigt.

Zu diesem Zeitpunkt ist noch nicht vollständig geklärt, wie weit der Angreifer vorgedrungen ist, ob und welche Daten exfiltriert wurden, welche personenbezogenen Daten und Kunden betroffen sind, ob weitere Persistence besteht, welche Backups vertrauenswürdig sind und welche regulatorischen oder vertraglichen Reporting States bereits erreicht wurden.

Die zentrale Frage lautet nicht, was die Organisation am Ende über den Cybervorfall weiß. Sie lautet, welcher Wissenszustand vorlag, als eine konkrete Eskalations-, Melde-, Kommunikations- oder Recovery-Entscheidung getroffen werden musste.

EVENT TIMELINE ≠ KNOWLEDGE TIMELINE ≠ DECISION TIMELINE

I / DER INCIDENT

Der Incident beginnt, bevor die Organisation seinen vollständigen Umfang kennen kann

01

Ein Enterprise-Ransomware-Incident beginnt mit Evidence, nicht mit vollständiger Gewissheit

Wir betrachten eine illustrative große europäische Unternehmensgruppe. Die Branche ist bewusst nicht festgelegt. Die Gruppe betreibt unter anderem zentrales Identity Management, ERP- und Order-Processing-Systeme, File- und Collaboration-Plattformen, Finance- und HR-Systeme, Customer Services, mehrere europäische Standorte und ein zentralisiertes Security Operations Center.

Um 07:42 Uhr erkennt das SOC ungewöhnliche privilegierte Aktivität außerhalb des erwarteten Betriebszustands, verdächtige Remote Execution, Credential-Access-Verhalten und Verbindungen zu mehreren Servern. Ransomware ist noch nicht bestätigt.

SUSPICIOUS SECURITY EVENT — UNDER ASSESSMENT

Ein technisches Event und der Wissenszustand der Organisation über dieses Event sind nicht dasselbe.

02

Wenige Minuten später kann sich der State grundlegend ändern

Um 08:17 Uhr bestätigen SOC und Incident Response missbräuchliche Verwendung des privilegierten Accounts, Remote Execution auf mehreren Systemen, Manipulation eines Security Agents, Credential-Dumping-Verhalten, erste verschlüsselte Dateien und eine Ransomware-Komponente.

CYBER INCIDENT — CONFIRMED

MALICIOUS ACTIVITY — CONFIRMED

PRIVILEGED ACCESS ABUSE — CONFIRMED

RANSOMWARE ACTIVITY — CONFIRMED

 

FULL INCIDENT SCOPE — UNKNOWN

DATA EXFILTRATION — UNKNOWN

PERSONAL DATA IMPACT — UNKNOWN

ROOT CAUSE — UNKNOWN

Unvollständiges Wissen bedeutet nicht, dass kein Incident vorliegt. Ein bestätigter Incident bedeutet nicht, dass jede nachgelagerte Entscheidung bereits finalisierbar ist.

03

Incident Response beginnt, bevor regulatorische Finalität existiert

Sobald der Cybervorfall bestätigt ist, beginnt die technische Response: privilegierte Accounts können deaktiviert, Sessions invalidiert, Hosts isoliert, Netzwerkpfade eingeschränkt, Credentials rotiert, Backups geschützt und Forensic Preservation aktiviert werden.

Technische Response

Detect

Governance Decisions

Classify

Technische Response

Analyse

Governance Decisions

Escalate

Technische Response

Contain

Governance Decisions

Assess

Technische Response

Eradicate

Governance Decisions

Report

Technische Response

Recover

Governance Decisions

Communicate

NIS2 ist auf eine gestufte Meldung während eines laufenden Incident ausgelegt. Technische Eindämmung, Eradication und Recovery warten deshalb nicht auf einen vollständigen Reporting State.

Primärquelle: Richtlinie (EU) 2022/2555 — NIS2

Epistemis macht operative Eindämmung, Eradication oder Recovery nicht von SEAL abhängig.

04

Drei Zeitachsen beschreiben denselben Incident

Spätere Forensik kann Initial Access um 03:18, Credential Theft um 04:06, Data Staging um 06:10, mögliche Exfiltration um 06:48 und Ransomware Deployment um 07:36 rekonstruieren. Die Organisation erkennt relevante Aktivität erstmals um 07:42 und trifft Governance Decisions später.

Timeline

EVENT TIMELINE

Leitfrage

Wann geschah etwas technisch?

Timeline

KNOWLEDGE TIMELINE

Leitfrage

Wann wurde eine Aussage für die Organisation belastbar?

Timeline

DECISION TIMELINE

Leitfrage

Wann wurde auf dieser Grundlage eine konkrete Entscheidung getroffen?

EVENT TIME

≠

EVIDENCE TIME

≠

DECISION TIME

Die spätere forensische Event Timeline zeigt allein nicht, was die Organisation bei einer früheren Decision wusste. Ereignis, Wissen und Entscheidung teilen keinen gemeinsamen Timestamp.

EVENT TIMELINE

03:18

Initial Access — später rekonstruiert

EVENT TIMELINE

04:06

Credential Theft

EVENT TIMELINE

06:10

Data Staging

EVENT TIMELINE

06:48

Mögliche Exfiltration

EVENT TIMELINE

07:36

Ransomware Deployment

KNOWLEDGE TIMELINE

07:42

Suspicious Activity erkannt

KNOWLEDGE TIMELINE

08:17

Incident bestätigt

KNOWLEDGE TIMELINE

09:05

Exfiltration vermutet

DECISION TIMELINE

10:10

Enterprise Crisis aktiviert

DECISION TIMELINE

12:15

NIS2 Significance gelöst — illustrativ

KNOWLEDGE TIMELINE

13:40

Personal Data Breach bestätigt

DECISION TIMELINE

17:30

Early Warning freigegeben

KNOWLEDGE TIMELINE

21:15

Exfiltration bestätigt

DECISION TIMELINE

DAY 2

Privacy Reporting Decisions

EVENT TIME ≠ EVIDENCE TIME ≠ DECISION TIME

II / WAS JETZT BEKANNT IST

Derselbe Incident enthält Facts, Inferences, Hypothesen, Unknowns und Konflikte

05

Fact, Inference und Hypothesis dürfen nicht verschmelzen

State

CONFIRMED

Bedeutung

ausreichend direkt belegt

State

SUPPORTED INFERENCE

Bedeutung

durch mehrere Evidenzen gestützte Schlussfolgerung

State

SUSPECTED

Bedeutung

plausibel, aber noch nicht ausreichend belegt

State

HYPOTHESIS

Bedeutung

aktive Untersuchungshypothese

State

UNKNOWN

Bedeutung

derzeit nicht bestimmbar

State

CONFLICTING

Bedeutung

widersprüchliche Evidence oder Assessments

State

DISPROVED

Bedeutung

durch neue Evidence widerlegt

FACT

≠

INFERENCE

≠

HYPOTHESIS

≠

ASSUMPTION

≠

UNKNOWN

06

Der Incident Scope wächst nicht linear

Um 09:05 sind mehrere Systeme betroffen, eine zentrale Business-Anwendung ist beeinträchtigt, auf einem Server wurden Archive erzeugt und ungewöhnlicher ausgehender Netzwerkverkehr wurde beobachtet.

Zeit

08:17

Claim

Ransomware Activity

State

CONFIRMED

Zeit

09:05

Claim

Enterprise Compromise

State

CONFIRMED

Zeit

09:05

Claim

Data Exfiltration

State

SUSPECTED

Zeit

11:25

Claim

Personal Data Impact

State

UNDER ASSESSMENT

Zeit

13:40

Claim

Personal Data Breach

State

CONFIRMED

Zeit

21:15

Claim

Data Exfiltration

State

CONFIRMED

07

Unknown ist ein eigener Zustand und kein negatives Faktum

Eine Personal Data Breach ist nicht auf Exfiltration beschränkt. Sie kann unbefugten Zugriff, Veränderung, Verlust, Zerstörung oder Unverfügbarkeit personenbezogener Daten umfassen. EDPB-Guidance behandelt Ransomware ausdrücklich als Kontext, in dem Verfügbarkeit auch ohne bestätigte Exfiltration beeinträchtigt sein kann.

Primärquelle: EDPB — Leitlinien zu Datenschutzverletzungen

NOT CONFIRMED

≠

NO

 

UNKNOWN DATA IMPACT

≠

NO DATA IMPACT

 

NO CONFIRMED EXFILTRATION

≠

NO PERSONAL DATA BREACH

08

Jede wichtige Aussage braucht Provenance und Zeit

Feld

Claim

K-04 / 09:05

Customer data exfiltrated

K-09 / 21:15

Customer data exfiltrated

Feld

State

K-04 / 09:05

SUSPECTED

K-09 / 21:15

CONFIRMED

Feld

Evidence

K-04 / 09:05

Outbound Telemetry · Archive Creation

K-09 / 21:15

Proxy Correlation · Repository Access

Feld

Limitation / Change

K-04 / 09:05

Payload Content nicht bestimmt

K-09 / 21:15

Transmission ausreichend belegt

Der neue State ersetzt den alten nicht rückwirkend. Er folgt ihm.

09

Unterschiedliche Sources können widersprüchliche States erzeugen

  • 01Network Team — kein eindeutig beweisendes Egress-Volumen.
  • 02Forensics — Archive und Attack Sequence sprechen für Data Staging.
  • 03Data Owner — das betroffene Repository enthält vertrauliche Kundeninformationen.

DATA EXFILTRATION — CONFLICTING / UNDER ASSESSMENT

Ein Conflict State ist kein Versagen des Entscheidungsprozesses. Er ist Teil der Entscheidungsrealität.

III / EIN INCIDENT, MEHRERE ENTSCHEIDUNGEN

Gemeinsames Wissen kann mehrere Decisions mit unterschiedlichen Blockern und unterschiedlicher Finalität tragen

10

Der gemeinsame Incident Space ist nicht selbst die Entscheidung

Alle nachgelagerten Decisions greifen auf einen gemeinsamen, versionierten Incident Knowledge State zu. Derselbe Knowledge State kann Cyber / Crisis, NIS2 Reporting soweit anwendbar, GDPR / Personal Data, External Communication und Recovery / Return-to-Service Decision Spaces versorgen.

SHARED KNOWLEDGE

≠

SHARED FINALITY

Ein gemeinsamer, versionierter Knowledge State kann mehrere Decision Spaces mit unabhängigen Blockern und Finality States tragen. Neue Evidence aktualisiert den Knowledge State; nur betroffene Decisions müssen neu bewertet werden.

INCIDENT EVIDENCE

VERSIONED KNOWLEDGE STATE K-07

Shared Knowledge bedeutet nicht Shared Finality.

01 / CYBER / CRISIS

ACTIVATED

FINAL

SEAL / DECISION BOUND

02 / NIS2

SIGNIFICANCE RESOLVED

FINAL

SEAL / DECISION BOUND

03 / GDPR / PERSONAL DATA

ART. 33 UNDER ASSESSMENT

OPEN

04 / COMMUNICATION

PARTIALLY AVAILABLE

CLAIM-SPECIFIC

05 / RECOVERY

BLOCKED

OPEN

NEW EVIDENCE

BRIDGE / ADMISSIBLE TRANSITION

Provenance · Evidence Type · Timestamp · Scope · Conflict · Decision Impact · Authority · Version

KNOWLEDGE STATE K-08

Nur betroffene Decisions werden neu bewertet.

11

Internal Severity kann final sein, während Data Scope offen bleibt

Um 10:10 wird der Incident illustrativ auf Enterprise-Crisis-Level eskaliert. Bestätigte Ransomware, privilegierte Kompromittierung, mehrere betroffene Systeme und relevante Business Disruption können für diese Decision ausreichen, obwohl Data Exfiltration und Root Cause weiter offen sind.

ENTERPRISE CRISIS — ACTIVATED

Unvollständiges Wissen ist nicht automatisch ein Blocker. Ein unresolved State wird erst dann zum Blocker, wenn er für diese konkrete Entscheidung aufgelöst sein muss.

12

NIS2 besitzt einen eigenen Decision Space

Wo die zuständigen Funktionen die Anwendbarkeit der relevanten NIS2-Umsetzung festgestellt haben, lautet die Decision Question, ob der Incident den für diese Gesellschaft relevanten Significant-Incident-State erreicht hat.

Primärquelle: Richtlinie (EU) 2022/2555 — NIS2

Dimension

Applicability

Illustrativer State

BOUND / KNOWN

Dimension

Cyber Incident

Illustrativer State

CONFIRMED

Dimension

Malicious Activity

Illustrativer State

CONFIRMED

Dimension

Service Impact

Illustrativer State

CONFIRMED / EVOLVING

Dimension

Impact on Others

Illustrativer State

POSSIBLE

Dimension

Financial Impact

Illustrativer State

UNKNOWN

Dimension

Significance

Illustrativer State

UNDER ASSESSMENT

Dimension

Notification Authority

Illustrativer State

IDENTIFIED

SIGNIFICANCE ASSESSMENT — UNRESOLVED

13

Ein Reporting State kann vor Abschluss der Investigation final werden

Im illustrativen Szenario gelangen die zuständigen Legal-/Compliance-Funktionen um 12:15 zu einem ausreichenden Significant-Incident-State. Diese Uhrzeit ist eine illustrative interne Bewertung und keine rechtliche Feststellung durch Epistemis.

SIGNIFICANT-INCIDENT AWARENESS — 12:15

Art. 23 NIS2 knüpft die gestufte Meldung an die Kenntnisnahme eines erheblichen Sicherheitsvorfalls. Die Early Warning folgt grundsätzlich binnen 24 Stunden und die Incident Notification binnen 72 Stunden, während spätere Meldungen wesentlich mehr Detail enthalten können.

Primärquelle: Richtlinie (EU) 2022/2555 — NIS2

Eine Reporting Decision kann erforderlich werden, bevor Root Cause, vollständiger Scope oder vollständige Data Impact Analysis vorliegen.

14

NIS2 Early Warning und spätere Reports sind unterschiedliche Decision States

Stufe

Early Warning

Illustrative Informationsreife

Malicious Incident und Service Impact bekannt; vollständige Root Cause und Data Scope können offen bleiben.

Stufe

72-Stunden Incident Notification

Illustrative Informationsreife

Aktualisierte Severity, Impact, verfügbare Indicators und zusätzliche bestätigte Facts.

Stufe

Final / Progress Report

Illustrative Informationsreife

Vollständigerer Root-Cause-, Impact- und Mitigation-State.

EARLY WARNING STATE

≠

72-HOUR NOTIFICATION STATE

≠

FINAL REPORT STATE

15

Datenschutz erzeugt mehrere weitere Decision Spaces

Um 11:25 ist bekannt, dass der kompromittierte Account Zugriff auf ein Repository mit personenbezogenen Daten hatte, tatsächlicher unautorisierter Zugriff ist aber noch unter Assessment. Später, um 13:40 im illustrativen Szenario, bestätigt zusätzliche Evidence unautorisierten Zugriff auf personenbezogene Daten.

PERSONAL DATA BREACH — CONFIRMED

EDPB-Guidance beschreibt Awareness über einen angemessenen Grad an Gewissheit, dass ein Security Incident eingetreten ist, durch den personenbezogene Daten kompromittiert wurden. Eine kurze Erstuntersuchung kann diesem Zeitpunkt vorausgehen, während detailliertere Investigation danach weiterläuft.

Primärquelle: EDPB — Leitlinien zu Datenschutzverletzungen

16

Ein Incident besitzt nicht eine einzige Awareness Time

12:15 — NIS2 SIGNIFICANT-INCIDENT AWARENESS

≠

13:40 — PERSONAL DATA BREACH AWARENESS

ONE INCIDENT ≠ ONE AWARENESS TIME

ONE INCIDENT ≠ ONE CLASSIFICATION ≠ ONE REPORTING CLOCK

17

Personal Data Breach, Art.-33-Meldung und Betroffenenkommunikation sind unterschiedliche Decisions

Artikel 33 DSGVO verlangt grundsätzlich eine Meldung an die Aufsichtsbehörde ohne unangemessene Verzögerung und, soweit möglich, binnen 72 Stunden nach Awareness, außer der Breach führt voraussichtlich nicht zu einem Risiko für Rechte und Freiheiten. Artikel 34 besitzt eine eigene High-Risk-Schwelle für die Kommunikation an Betroffene.

Primärquelle: Verordnung (EU) 2016/679 — DSGVO

PERSONAL DATA BREACH?

↓

ARTICLE 33 — SUPERVISORY NOTIFICATION?

↓

ARTICLE 34 — DATA-SUBJECT COMMUNICATION?

18

Der Incident kann gleichzeitig finale und offene Decisions besitzen

Decision Space

Cyber Incident Confirmation

State

CONFIRMED

Finality

FINAL FOR THIS DECISION

Decision Space

Enterprise Crisis

State

ACTIVATED

Finality

FINAL FOR THIS DECISION

Decision Space

NIS2 Significance

State

RESOLVED

Finality

FINAL FOR THIS DECISION

Decision Space

NIS2 Early Warning

State

AVAILABLE / IN PREPARATION

Finality

PENDING ACTION

Decision Space

Personal Data Breach

State

CONFIRMED

Finality

FINAL FOR THIS DECISION

Decision Space

GDPR Art. 33

State

UNDER ASSESSMENT

Finality

OPEN

Decision Space

GDPR Art. 34

State

UNDER ASSESSMENT

Finality

OPEN

Decision Space

Customer Communication

State

PARTIALLY AVAILABLE

Finality

CLAIM-SPECIFIC

Decision Space

Data Exfiltration

State

SUSPECTED

Finality

OPEN

Decision Space

Recovery

State

BLOCKED

Finality

OPEN

Decision Space

Root Cause

State

UNKNOWN

Finality

OPEN

Finalität gehört zur Entscheidung – nicht zum Incident insgesamt.

IV / WENN NEUE EVIDENCE HINZUKOMMT

Neue Evidence kann aktuelle States verändern, ohne frühere Decision States rückwirkend umzuschreiben

19

Ein neuer Fact State erzeugt eine neue Knowledge-Version

Um 21:15 werden zusätzliche Proxy-/Network-Telemetry, Archive Timestamps, Repository Access, Session Information und Traffic Volume korreliert. Im illustrativen Fall reicht dies aus, um Data Exfiltration zu bestätigen.

Knowledge Version

K-04 / 09:05

State

EXFILTRATION — SUSPECTED

Evidence

Outbound Telemetry · Archive Creation

Knowledge Version

K-09 / 21:15

State

EXFILTRATION — CONFIRMED

Evidence

Proxy Correlation · Repository Access

K-09 überschreibt K-04 nicht. K-09 folgt auf K-04.

20

Reclassification ist nicht automatisch ein Widerspruch

Reclassification ist kein Widerspruch, wenn neue Evidence den State verändert.

Historische Integrität bedeutet nicht, eine frühere Einschätzung für immer festzuhalten. Sie bedeutet sichtbar zu erhalten, warum sich der State verändert hat.

21

Nur betroffene Decisions müssen neu bewertet werden

Decision Space

GDPR Risk Assessment

Mögliche Wirkung bestätigter Exfiltration

kann sich verändern

Decision Space

Customer Communication

Mögliche Wirkung bestätigter Exfiltration

kann sich verändern

Decision Space

Contractual Notifications

Mögliche Wirkung bestätigter Exfiltration

kann sich verändern

Decision Space

Späterer NIS2 Report Content

Mögliche Wirkung bestätigter Exfiltration

kann sich verändern

Decision Space

Enterprise Crisis Escalation

Mögliche Wirkung bestätigter Exfiltration

kann unverändert bleiben

Decision Space

Recovery Authority

Mögliche Wirkung bestätigter Exfiltration

kann unverändert bleiben

Neue Evidence bedeutet nicht, alles neu zu bewerten. Entscheidend ist, welche Decision Spaces den veränderten State konsumieren.

22

SIMULATION kann offene Decision States untersuchen

Für eine GDPR-Art.-33-Decision kann SIMULATION sichtbar machen, welche offenen Evidence-Klassen den relevanten Risk State noch nicht tragen: betroffene Datenkategorien, betroffene Personen, Sensitivität, Exposition, wahrscheinliche Folgen und Mitigations.

Epistemis zeigt die Struktur des offenen Decision State. Es trifft nicht die rechtliche Bewertung.

23

SIMULATION kann Conditional States untersuchen

Actual Knowledge State

DATA EXFILTRATION — SUSPECTED

SIMULATION Candidate

IF DATA EXFILTRATION — CONFIRMED

Der Conditional Change kann GDPR, Customer Communication, vertragliche Notifications und späteren NIS2 Report Content verändern, während andere Decisions unverändert bleiben.

24

Ein simuliertes Szenario ist keine Evidence

IF EXFILTRATION CONFIRMED

≠

EXFILTRATION CONFIRMED

Ein simulierter Conditional State ist keine Evidence.

25

BRIDGE kontrolliert neue reale Evidence

  • 01Provenance — woher stammt die Information?
  • 02Evidence Type — Fact, Inference, Hypothesis, Assumption oder Conflict?
  • 03Timestamp — wann stand sie tatsächlich zur Verfügung?
  • 04Scope — welche Systeme, Daten, Gesellschaften oder Services betrifft sie?
  • 05Conflict — widerspricht sie bestehender Evidence?
  • 06Decision Impact — welche Decision Spaces konsumieren den State?
  • 07Authority — welche zuständige Funktion darf den State übernehmen?
  • 08Version — welcher historische State bleibt erhalten?
Wie SIMULATION, BRIDGE und SEAL Exploration, neue Evidence und geregelte Finalität trennen

26

Neue Evidence darf den aktuellen State verändern, aber nicht die Vergangenheit

Neue Evidence darf den aktuellen Zustand verändern. Sie darf nicht den Knowledge State umschreiben, der eine frühere Entscheidung getragen hat.

V / AUTHORITY & KOMMUNIKATION

Unterschiedliche Authorities handeln auf unterschiedlichen States, und externe Kommunikation bleibt claim-spezifisch

27

Ein Cybervorfall besitzt mehrere Authority-Typen

Authority-Typ

Evidence Authority

Funktion

liefert belastbare technische Sources

Authority-Typ

Assessment Authority

Funktion

bewertet einen fachlichen State

Authority-Typ

Classification Authority

Funktion

setzt internen Severity- oder Crisis-State

Authority-Typ

Notification Authority

Funktion

autorisiert oder veranlasst externe Meldung

Authority-Typ

Recovery Authority

Funktion

autorisiert Return to Service

EVIDENCE AUTHORITY

≠

ASSESSMENT AUTHORITY

≠

CLASSIFICATION AUTHORITY

≠

NOTIFICATION AUTHORITY

≠

RECOVERY AUTHORITY

28

Derselbe Incident aktiviert unterschiedliche Verantwortlichkeiten

Funktion

SOC

Verantworteter State

Detection Evidence

Funktion

Incident Response / CSIRT

Verantworteter State

Investigation und technische Fact States

Funktion

Identity / Infrastructure Security

Verantworteter State

Identity- und Infrastructure-State

Funktion

Business / Service Owner

Verantworteter State

Business Impact

Funktion

Incident Commander

Verantworteter State

operative Koordination

Funktion

CISO / Security Leadership

Verantworteter State

Security Severity und Executive Escalation

Funktion

Legal / Regulatory Compliance

Verantworteter State

Regulatory Applicability und Reporting Assessment

Funktion

Privacy / DPO Function

Verantworteter State

Personal-Data-Breach- und Rights-Risk-State

Funktion

Crisis Authority

Verantworteter State

Enterprise Crisis

Funktion

Corporate Communications

Verantworteter State

externe Communication

Funktion

Notification Authority

Verantworteter State

externe Meldung

Funktion

Recovery Authority

Verantworteter State

Return to Service

Funktion

Internal Audit

Verantworteter State

spätere unabhängige Prüfung

29

External Communication braucht einen eigenen Evidence State

Claim

Wir untersuchen einen Cybervorfall

Communication State

CONFIRMED FOR COMMUNICATION

Claim

Bestimmte Services sind beeinträchtigt

Communication State

CONFIRMED FOR COMMUNICATION

Claim

Ransomware-Aktivität ist bestätigt

Communication State

CONFIRMED FOR COMMUNICATION

Claim

Data Impact wird untersucht

Communication State

SUPPORTABLE / QUALIFIED

Claim

Keine Kundendaten wurden betroffen

Communication State

NOT SUPPORTABLE

Claim

Data Exfiltration occurred

Communication State

SUSPECTED → LATER CONFIRMED

30

Communication Finality ist claim-specific

Communication Finality ist claim-specific.

Eine Communication Authority kann fehlende Evidence nicht ersetzen. Unterschiedliche materielle Aussagen derselben Mitteilung können unterschiedliche Evidence States besitzen.

31

Ein früher öffentlicher Satz kann später falsch erscheinen, obwohl der damalige Knowledge State anders war

Die Aussage „Es wurden keine Kundendaten betroffen“, während Data Impact UNKNOWN ist, wird vom damaligen State nicht getragen. Die Aussage „Wir untersuchen, ob Daten betroffen sind“ kann historisch korrekt bleiben, auch wenn spätere Forensik Exfiltration bestätigt.

32

Decision Outputs dürfen keine neuen Fakten erzeugen

NIS2 SIGNIFICANT = YES

≠

DATA EXFILTRATION = CONFIRMED

 

PERSONAL DATA BREACH = YES

≠

CUSTOMER CONTRACT NOTIFICATION = REQUIRED

Decision Outputs dürfen Knowledge konsumieren; sie dürfen keine unbelegten Facts erzeugen.

33

SEAL gehört an die Decision – nicht an den Incident als Ganzes

Gebundene Decision

Enterprise Crisis Activation

Knowledge Version

K-03

Gebundene Decision

NIS2 Early-Warning Decision

Knowledge Version

K-06

Gebundene Decision

GDPR Article 33 Decision

Knowledge Version

K-10

SEAL — SPECIFIC DECISION

≠

THE INCIDENT — FINAL

34

SEAL friert die Investigation nicht ein

Neue Facts können nach einer gebundenen Early-Warning-Decision entstehen. Sie erzeugen eine neue Knowledge Version und können neue oder aktualisierte Decisions auslösen, während der frühere Decision State erhalten bleibt.

VI / SPÄTERE PRÜFUNG

Spätere Prüfung muss frühere Knowledge States mit späteren Facts vergleichen, statt alles in eine finale Incident-Erzählung zu kollabieren

35

Der Final Report ist nicht der ursprüngliche Decision State

Drei Wochen später kann die Forensik Initial Access, Credential Theft, Privilege Escalation, Lateral Movement, Data Staging, Exfiltration, Ransomware Deployment und Root Cause rekonstruieren. Dieser Knowledge State ist wesentlich vollständiger als der State am ersten Vormittag.

Auch NIS2 sieht vor, dass spätere Reports eine detailliertere Incident-Beschreibung, Severity und Impact, wahrscheinliche Threat Type beziehungsweise Root Cause, Mitigation und gegebenenfalls Cross-Border Impact enthalten.

Primärquelle: Richtlinie (EU) 2022/2555 — NIS2

Der Final Report ist ein späterer Knowledge State. Er ist nicht die Information, die bei der Early Warning existierte.

36

Ein späterer Reviewer braucht mehr als die technische Timeline

  • 01Knowledge — was war zu diesem Zeitpunkt tatsächlich bekannt?
  • 02Unknown — welche wesentlichen Fragen waren noch offen?
  • 03Evidence — welche Source trug welche Aussage?
  • 04Confidence — war eine Aussage bestätigt, vermutet oder nur Hypothese?
  • 05Time — seit wann stand die relevante Evidence zur Verfügung?
  • 06Decision — welche Decision nutzte diesen Knowledge State?
  • 07Requirement — welche internen oder externen Requirements galten?
  • 08Authority — wer durfte die konkrete Decision treffen?
  • 09Conflict — welche widersprüchlichen Assessments bestanden?
  • 10Change — welche neuen Informationen änderten den State später?

37

Spätere Erkenntnisse dürfen nicht zum Bewertungsmaßstab früherer Decisions werden

Wenn Day-21-Forensik feststellt, dass Exfiltration um 06:48 begann, lautet die relevante Review-Frage nicht, warum die Organisation um 06:50 auf bestätigte Exfiltration reagiert hat. Sie lautet, wann der Organisation ausreichend belastbare Evidence über Exfiltration zur Verfügung stand.

Later facts must not rewrite earlier decisions.

38

Reclassification ist Teil eines nachvollziehbaren Incident State

Knowledge Version

K-04

State

DATA EXFILTRATION — SUSPECTED

Knowledge Version

K-09

State

DATA EXFILTRATION — CONFIRMED

Beide können korrekt sein, wenn sichtbar bleibt, welche Evidence jeden State trug und welche neue Evidence die Transition auslöste.

39

Incident-Management-Systeme und Decision States beantworten unterschiedliche Fragen

Incident Management

Event Timeline

Decision State

Knowledge Timeline

Incident Management

Alert

Decision State

Claim + Evidence

Incident Management

Severity

Decision State

Classification Basis

Incident Management

Owner

Decision State

Authority je Decision

Incident Management

Notes

Decision State

versionierter Knowledge State

Incident Management

Incident Status

Decision State

decision-specific Finality

Incident Management

Actions

Decision State

begründete Governance Decision

Incident Management

Closed

Decision State

historische Decision Chain

Incident-Management-Systeme halten Ereignisse und Maßnahmen fest. Ein Decision State bewahrt, was bekannt war, als Verantwortung übernommen wurde.

40

Ein gemeinsamer Knowledge State kann unterschiedliche spätere Leser versorgen

Leser

SOC / CSIRT

Zentrale Frage

Welche technische Evidence trägt den aktuellen State?

Leser

CISO

Zentrale Frage

Warum wurde welcher Severity-/Crisis-State gesetzt?

Leser

Legal / Compliance

Zentrale Frage

Welche Facts und Requirements trugen die Reporting Decision?

Leser

Privacy / DPO Function

Zentrale Frage

Wann wurde der Personal-Data-Breach-State ausreichend bestimmt?

Leser

Corporate Communications

Zentrale Frage

Welche Claims waren zu welchem Zeitpunkt belastbar?

Leser

Management

Zentrale Frage

Auf welcher Grundlage wurden Enterprise Decisions getroffen?

Leser

Internal Audit

Zentrale Frage

Wie entwickelte sich Knowledge → Decision → Reclassification?

Leser

Autorisierter externer Reviewer

Zentrale Frage

Welche historische Sicht belegt die damalige Decision?

Wie spätere institutionelle Leser einen früheren Decision State prüfen

41

Reale fachliche und rechtliche Authority bleibt außerhalb von Epistemis

  • 01Epistemis entscheidet nicht, ob ein Security Event tatsächlich ein Incident ist.
  • 02Epistemis bestimmt nicht, wie Ransomware technisch einzudämmen ist.
  • 03Epistemis setzt nicht die richtige interne Severity.
  • 04Epistemis bestimmt nicht, ob NIS2 auf eine konkrete Gesellschaft anwendbar ist oder wann eine gesetzliche Awareness-Schwelle rechtlich erreicht ist.
  • 05Epistemis entscheidet nicht, ob rechtlich eine Personal Data Breach vorliegt oder ob Art. 33 bzw. 34 DSGVO erfüllt sind.
  • 06Epistemis bestimmt nicht, welche Vertragsmeldungen ausgelöst werden oder welche externe Aussage rechtlich freigegeben werden darf.
  • 07Epistemis entscheidet nicht, wann ein System technisch sicher wieder produktiv gesetzt werden kann.

Epistemis bewahrt, welcher Knowledge State vorlag, welche Requirements angewandt wurden, welche Authority handelte und welche offenen oder finalen States zu diesem Zeitpunkt bestanden.

42

Warum dieser Case über klassisches Incident Logging hinausgeht

Ein Unternehmen kann bereits SIEM, EDR, SOAR, Ticketing, Incident Management, Forensic Tools, IAM, Crisis Management, Privacy Workflows, GRC, Audit Logs und Regulatory Reporting Tools betreiben. Epistemis ersetzt sie nicht.

Die Decision-State-Ebene verbindet technische Evidence, Knowledge States, Business Impact, Data Impact, Requirements, Unsicherheit, Authorities und parallele Decisions so, dass rekonstruierbar bleibt, welche Verantwortung auf welcher Grundlage übernommen wurde.

43

Der Epistemis-Mechanismus für einen laufenden Cybervorfall

  • 01Der Incident Space hält den gemeinsamen, versionierten Knowledge State.
  • 02Jeder gebundene Decision Space bestimmt selbst, welche Knowledge- und Requirement-States für seine Decision erforderlich sind.
  • 03SIMULATION untersucht offene Decisions oder Konsequenzen möglicher neuer States, ohne Hypothesen zu Facts zu machen.
  • 04BRIDGE prüft reale neue Evidence auf Provenance, Timestamp, Scope, Conflict, Authority und betroffene Decision Spaces.
  • 05SEAL bindet konkrete Decisions – niemals den gesamten Incident als vermeintlich finalen Zustand.

Ein Cybervorfall besitzt keine globale Finalität. Er besitzt einen Graph aus offenen, gebundenen, reklassifizierten und später erneut zu prüfenden Decision States.

QUELLEN / METHODE

Quellen- und Methodenhinweis

Reale regulatorische Grundlage

Die regulatorische Grundlage sind vor allem NIS2 Art. 23 für die gestufte Meldung erheblicher Sicherheitsvorfälle, DSGVO Art. 33 und 34 für Datenschutzverletzungen und Betroffenenkommunikation sowie EDPB-Guidance zu Awareness und ransomwarebezogenen Data Breaches. § 32 BSIG wird nur als deutsches Beispiel der NIS2-Umsetzung referenziert, nicht als universeller europäischer Prozess.

Primärquelle: Richtlinie (EU) 2022/2555 — NIS2Primärquelle: Verordnung (EU) 2016/679 — DSGVOPrimärquelle: EDPB — Leitlinien zu DatenschutzverletzungenPrimärquelle: Deutschland — BSIG § 32

Illustratives Szenario

European Enterprise Group, Unternehmensarchitektur, privilegierter Account, Ransomware-Attack-Chain, konkrete Uhrzeiten, technische Findings, Incident Scope, betroffene Daten, interne Rollen, NIS2- und GDPR-Decision-Zeitpunkte, Communication States und Recovery States sind illustrativ und beschreiben keinen realen Kunden oder Cybervorfall.

Epistemis-Modellierung

Incident Space, Knowledge State, Decision State, Decision Space, Blocker, SIMULATION, BRIDGE, SEAL, Knowledge Version und Evidence-Pack-Sichten sind Epistemis-Konzepte. Sie sind keine Terminologie aus NIS2, DSGVO oder EDPB-Guidance.

Welche Cyberentscheidung müsste Ihre Organisation später erklären können?

Ein Enterprise Pilot beginnt mit einer klar abgegrenzten Incident Decision und bestimmt, welche Evidence, Knowledge States, Requirements, Authorities, Blocker, Communication Claims und späteren Reader Views rekonstruierbar bleiben müssen.

Diesen Incident Decision Space im Enterprise Pilot besprechenWeitere Anwendungsfälle ansehen