Verfahren bei Datenlecks

1) Zweck und Anwendungsbereich

Ziel: Schadensminimierung, Erfüllung gesetzlicher Vorgaben und schnelle Wiederherstellung des Normalbetriebs bei bestätigter oder wahrscheinlicher Verletzung von personenbezogenen/Zahlungs-/Betriebsdaten.
Reichweite: Spieler und Mitarbeiter-PIIs, Zahlungsartefakte, Zugriffsprotokolle/Token, KYC/AML-Dokumente, Affiliate/Partner-Daten, vertrauliche Produkt- und Infrastruktur-Artefakte.

2) Definitionen und Kriterien für „Leckage“

Datenleck - Verletzung der Vertraulichkeit, Integrität oder Verfügbarkeit personenbezogener Daten (oder anderer geschützter Informationen) aufgrund eines Sicherheitsvorfalls oder eines Prozessfehlers.
Bestätigt gegen Verdacht: Alle Indikatoren (SIEM-Anomalien, Nachrichten von Anbietern/Benutzern, Paste-Sites) lösen das Verfahren vor der Widerlegung aus.

3) Klassifizierung des Schweregrads (Beispiel)

4) SLA und „Incident Bridge“

Initiation: Bei Medium + wird ein Kriegsraum (Chat/Call) angelegt, dem Incident Commander (IC) zugeordnet.
SLA: Niedrig - 24 h· Mittel - 4 h· Hoch - 1 h· Kritisch - 15 min.
Kadenzupdates: alle 30-60 Minuten (intern), alle 2-4 Stunden (externe Stakeholder).

5) RACI (vergrößert)

6) Reaktionsverfahren (Schritt für Schritt)

1. Identifizierung und primäre Validierung

Signal von SIEM/EDR/Anti-Betrug/Anbieter/Benutzer → Eintrag in das Incident-Register.
Sammlung von Mindestfakten: was/wann/wo/wie viel, betroffene Datentypen und Gerichtsbarkeiten.

2. Containment (Eindämmung)

Deaktivierung von anfälligen Endpoints/Fich, Geo-Segmenten, Zeitlimits, Einfrieren von Releases.
Schlüssel-/Token-Rotation, Abruf von Zugriffen, Sperrung von kompromittierten Konten.

3. Eradikation (Beseitigung)

Patch/Config-Fix, Reinigung schädlicher Artefakte, Neuzusammenstellung von Images, Überprüfung von Subprozessoren.

4. Recovery (Wiederherstellung)

Kanarische Verkehrseingabe, Überwachung von Regressionen, Durchgang von Integritätsschecks.

5. Forenzika und Folgenabschätzung

Berechnung des Volumens, der Empfindlichkeit, der Geographien, des Risikos für die Probanden; Bestätigung der betroffenen Einträge.

6. Benachrichtigungen und Mitteilungen

DSB/Legal legen die Pflicht und die Fristen für die Meldung fest; Erstellung von Texten; Versand an die Adressaten.

7. Post-Mortem und CAPA

Ursachenanalyse (5 Whys), Korrektur-/Vorsorgemaßnahmenplan mit Eigentümern und Fristen.

7) 72-Stunden-Fenster und rechtliche Adressaten (Richtlinien)

Data Supervision (DPA) - Benachrichtigen Sie spätestens 72 Stunden nach der Entdeckung eines wesentlichen Lecks, wenn ein Risiko für die Rechte/Freiheiten der Probanden nicht ausgeschlossen ist.
Nutzer - „ohne unnötige Verzögerung“ mit hohem Risiko (mit verständlichen Empfehlungen).
Gambling Regulator - unter Einfluss auf Spieler/Nachhaltigkeit/Berichterstattung.
Банки/PSP - Bei den Risiken der Zahlungen/komprometazii tokenow/verdächtig Transaktionen.
Partner/Anbieter - wenn gemeinsame Streams/Daten betroffen sind oder deren Wirkung erforderlich ist.

8) Forenzika und die „Beweisspeicherkette“

Volume/Log Snapshots, Export von Artefakten mit Hashing (SHA-256).
Arbeiten Sie nur mit Kopien/Schnappschüssen; Quellsysteme - nur lesen.
Aktionsprotokoll: Wer/wann/was hat es getan, verwendete Befehle/Werkzeuge.
Speicherung in WORM/Objektspeicher; eingeschränkter Zugriff, Audit.

9) Kommunikation (intern/extern)

Prinzipien: Fakten → Maßnahmen → Empfehlungen → das nächste Update.
Man kann nicht: PII veröffentlichen, ungeprüfte Hypothesen aufstellen, Termine ohne Kontrolle versprechen.

• Was wurde entdeckt?· Maßstab/Kategorien· Aktuelle Maßnahmen· Risiken· Nächste Schritte· Nächste Aktualisierung in HH: MM.

10) Interaktion mit Anbietern/Unterverarbeitern

Überprüfen Sie ihre Incident-Register, Zugriffsprotokolle, SLA-Benachrichtigungen, Liste der Unterprozessoren.
Berichte anfordern (pentest/forensica), Bestätigung der Löschung/Rückgabe der Daten erfassen.
Wenn die DPA nicht übereinstimmt - Eskalation und vorübergehende Isolation/Aussetzung der Integration.

11) Benachrichtigungsvorlagen (Fragmente)

11. 1 An die Aufsichtsbehörde (DPA)

Kurze Beschreibung des Ereignisses und des Zeitpunkts der Entdeckung, Kategorien/ungefähre Datenmenge, Gruppe von Probanden, Geographie, Auswirkungen und Risiken, ergriffene/geplante Maßnahmen, Kontakt des DSB, Anwendungen (Zeitleiste, Hash-Zusammenfassung).

11. 2 Benutzer

Was ist passiert ; welche Daten betroffen sein könnten; was wir getan haben; was Sie tun können (Passwortänderung, Transaktionskontrolle, Phishing-Tipps); wie man kontaktiert; Link zum FAQ/Support-Center.

11. 3 Partner/PSP/Regulierungsbehörde

Fakten und betroffene Schnittstellen; erwartete Handlungen des Partners; Fristen; Ansprechpartner.

12) Incident Register (Minimum Felder)

ID· Zeitpunkt der Entdeckung/Bestätigung· Schweregrad· Quelle· Systeme/Daten· Umfang/Kategorien· Geografien· Beteiligte Anbieter· Ergriffene Maßnahmen (nach Zeit)· Hinweise (an/wann)· Verantwortliche (RACI)· Artefakt-Referenzen· SARA/Termine· Status.

13) Metriken und Zielvorgaben

MTTD/MTTC/MTTR (Erkennung/Eindämmung/Wiederherstellung).
% der Benachrichtigungen in 72 Stunden - 100%.
Der Anteil der Vorfälle mit festgestellter Ursache ≥ 90%.
CAPAs werden ≥ 95% fristgerecht geschlossen.
Wiederholte Vorfälle aus einem Grund ≤ 5%.
Anteil der gemeldeten Vorfälle in SLA (Medium/High/Critical): 90/95/99%.

14) Checklisten

14. 1 Start (die ersten 60 Minuten)

• IC zugewiesen und Kriegsraum eröffnet
• Stabilisierende Maßnahmen (Blackouts/Limits/Schlüsselrotation)
• Sammlung von Mindestfakten und Screenshots/Protokollen
• Vom DSB/Legal benachrichtigt, Klasse preliminary definiert
• Einfrieren von Releases und Protokollen zur Protokollbereinigung

14. 2 Bis zu 24 Stunden

• Forenzika: Volumen/Kategorien/Geografien (Entwurf)
• Entscheidung über Notifizierungen, Vorbereitung von Texten
• Recovery-/Integritätsprüfungsplan
• Beweispaket in WORM, Zeitlinie der Ereignisse

14. 3 Bis zu 72 Stunden

• Versand von Benachrichtigungen an DPA/Regulatoren/PSP (falls erforderlich)
• Komm zu den Nutzern (bei hohem Risiko)
• Aktualisierter CAPA-Plan, Eigentümer und Zeitrahmen

15) Typische Szenarien und Maßnahmen

A) Export der Sapport-Chat-Datenbank in ein offenes Speichersegment

Maßnahmen: Zugang schließen, Downloads inventarisieren, Betroffene benachrichtigen, S3/ACL verstärken, DLP-Regeln für den Export.

B) Kompromittierung von API-Zugriffstoken

Maßnahmen: sofortige Rotation, Rückruf von Refresh-Token, Überprüfung des Anrufprotokolls, Re-Signatur von Webhooks, Segmentierung des Datenverkehrs.

C) Durchsickern von KYC-Scans durch den Anbieter

Maßnahmen: Abschottung der Integration, Bestätigung der Löschung, manuelle Überprüfung von High-Risk-Clients, DPA/Retention Revision.

D) Dump in der Öffentlichkeit veröffentlichen

Maßnahmen: Erfassung von Artefakten (Hashes), legaler Linkentzug (Takedown), Benachrichtigungen, Überwachung weiterer Publikationen.

16) Integration mit Compliance und Datenschutz

Verknüpfung mit DSGVO-Prozessen: DSAR, RoPA, DPIA/DTIA; Aktualisierung der Richtlinien und Cookies/CMPs bei Änderungen der Anbieter/Ziele.
Aufnahme des Vorfalls in die Risikomatrix und Überarbeitung der Schwellenwerte/Kontrollen.

17) CAPA und Post-Mortem (≤ 72 Stunden nach Stabilisierung)

Berichtsstruktur: Fakten/Zeitlinie· Impact· Grundursache· was hat funktioniert/nicht· CAPA-Liste (Eigentümer, Laufzeit, Erfolgskriterium)· Datum der Wirksamkeitsprüfung (nach 30-60 Tagen).

18) Roadmap Prozessreife

Monat 1: Aktualisieren Sie das Playbook, Kontakte, Vorlagen, WORM-Archiv, Benachrichtigungstest.
Monat 2: Tabletop-Übungen (PII-Leak/Anbieter/Token), SOAR-Playbooks.
Monat 3 +: vierteljährliche Retrospektiven, Vendor Audits, Bias-Tests von Anti-Fraud/Detection-Modellen, regelmäßige Revision von Schwellenwerten.

TL; DR

Bei einem Leck: schnell stabilisieren (Containment), genau bestätigen (Forensika), rechtzeitig benachrichtigen (DPA/User/Partner), transparent dokumentieren (Registry, Timeline, Evidenz) und die Ursache beheben (CAPA). Das Ergebnis ist weniger Schaden, Compliance und das wiedererlangte Vertrauen der Spieler und Partner.