Reaktion auf Sicherheitsvorfälle

Was ist Reaktion auf Sicherheitsvorfälle?

Nicht jeder Sicherheitsvorfall ist eine Datenschutzverletzung, aber jede Datenschutzverletzung beginnt als eine, und hier gilt es, sie schnell voneinander zu unterscheiden. Sie übernehmen das Kommando über eine aktive Exfiltration, koordinieren die IT-Sicherheit, wollen Online-Systeme für die Forensik, gegen die Privatsphäre, die wollen jetzt Eindämmung. Sie stufen den Schweregrad ein, stellen fest, ob auf personenbezogene Daten zugegriffen wurde, schätzen ab, wie viele Personen betroffen sind und beurteilen die Gefährdung ihrer Rechte. Wenn dies zutrifft, öffnen Sie die Meldung gemäß Artikel 33, während die Untersuchung noch läuft, und verpflichten sich zu schrittweisen Aktualisierungen.

Was Sie lernen in Reaktion auf Sicherheitsvorfälle

• Einen Sicherheitsvorfall triagieren, um festzustellen, ob auf personenbezogene Daten zugegriffen wurde oder ob sie exfiltriert oder kompromittiert wurden
• Parallele Arbeitsabläufe für die Eindämmung durch die IT-Sicherheit und die regulatorischen Pflichten des Datenschutzteams koordinieren
• Den Entscheidungsbaum zur Klassifizierung von Datenschutzverletzungen anwenden, um Schweregrad, Umfang und Meldepflichten zu bewerten
• Der Aufsichtsbehörde zunächst unvollständige Informationen melden und schrittweise Nachmeldungen zusagen
• Einen bereichsübergreifenden Incident-Response-Workflow entwickeln, der sowohl den Anforderungen der forensischen Untersuchung als auch des Datenschutzes gerecht wird

Reaktion auf Sicherheitsvorfälle — Trainingsschritte

1. Einführung

   In der heutigen Schulung lernen Sie, DSGVO-konform auf Vorfälle zu reagieren: Sie bewerten Sicherheitsereignisse, prüfen die Meldepflichten bei Datenschutzverletzungen und leiten die richtigen Verfahren ein, wenn personenbezogene Daten betroffen sein könnten.

2. Schichtbeginn

   Alice beginnt ihre Morgenschicht im Security Operations Center (SOC). Das Dashboard zeigt ein normales Aktivitätsniveau: einige Routinewarnungen, die das Nachtteam bereits gesichtet hat. SecureNet Financial wickelt Zahlungen für Hunderte von Unternehmenskunden ab. Das SOC überwacht rund um die Uhr unbefugte Zugriffe, Datenexfiltration, Richtlinienverstöße und andere Sicherheitsereignisse.

3. Warnung mit hohem Schweregrad

   Plötzlich erscheint auf dem Dashboard eine Warnung mit hohem Schweregrad. Das SIEM hat ungewöhnliche Anmeldeversuche erkannt: Auf mehrere fehlgeschlagene Versuche folgte eine erfolgreiche Anmeldung von einer ausländischen IP-Adresse. Die Warnung weist darauf hin, dass das Konto einem Systemadministrator mit erweiterten Berechtigungen gehört. Dabei könnte es sich um einen erfolgreichen Brute-Force-Angriff handeln, durch den die Zugangsdaten kompromittiert wurden.

4. Anmeldewarnung analysieren

   Die Details der Warnung enthalten beunruhigende Informationen: Konto : sysadmin_jsmith (Systemadministrator) Quell-IP : 185.220.101.45 (Osteuropa) Fehlversuche : 47 innerhalb von 3 Stunden Erfolgreiche Anmeldung : 06:47 Uhr Ortszeit Sitzungsdauer : 2 Stunden 13 Minuten Der rechtmäßige Kontoinhaber John Smith ist derzeit in Spanien im Urlaub, die Anmeldung erfolgte jedoch aus einem ganz anderen Land.

5. Zweite Warnung

   Während Alice die Anmeldewarnung prüft, erscheint eine zweite Warnung mit mittlerem Schweregrad. Das Data-Loss-Prevention-System (DLP) hat eine umfangreiche Datenexportanfrage gemeldet. Jemand hat das kompromittierte Systemadministratorkonto verwendet, um Kundendatensätze aus der Produktionsdatenbank zu exportieren. Der Export war abgeschlossen, bevor die automatisierten Systeme ihn blockieren konnten.

6. Der Umfang der Datenschutzverletzung

   Die Datenexportwarnung zeigt das Ausmaß des möglichen Schadens: Exportierte Datensätze : 50.000 Kundendatensätze Datenarten : Vollständige Namen, E-Mail-Adressen, Telefonnummern, Finanzkontonummern, Transaktionsverlauf Exportziel : Externer FTP-Server (IP: 185.220.101.89) Zeitpunkt des Exports : 07:15 Uhr Ortszeit Dies ist nicht länger nur ein Sicherheitsereignis: Personenbezogene Daten wurden auf einen externen Server exfiltriert, der von unbekannten Dritten kontrolliert wird.

7. Warnungen bestätigen

   Alice muss beide Warnungen bestätigen, um kenntlich zu machen, dass sie aktiv untersucht werden. Dadurch entsteht ein Audit-Trail, der zeigt, wann das SOC von der möglichen Datenschutzverletzung Kenntnis erlangt hat. Nach der DSGVO gilt eine Datenschutzverletzung dem Unternehmen als bekannt, sobald das SOC einen Vorfall mit personenbezogenen Daten feststellt – nicht erst nach Abschluss der Untersuchung.

8. Datenexportwarnung bestätigen

   Die Warnung vor unbefugtem Zugriff wurde als bestätigt markiert. Jetzt muss Alice auch die Datenexportwarnung bestätigen. Nach der Bestätigung beider Warnungen belegt ein eindeutiger Zeitstempel, wann SecureNet Financial von der möglichen Datenschutzverletzung Kenntnis erlangt hat.

9. Compliance-Status prüfen

   Bevor Alice den Vorfall eskaliert, prüft sie im Compliance-Dashboard die aktuelle Sicherheitslage der Organisation. Anhand dieses Kontexts lässt sich ermitteln, welche Kontrollen möglicherweise versagt haben. Die bestehenden Compliance-Lücken können erklären, wie es zu der Datenschutzverletzung kam und welche Gegenmaßnahmen Vorrang haben sollten.

10. Schwachstelle ermitteln

    Das Compliance-Dashboard zeigt ein kritisches Problem: Einwilligungsverwaltung : Konform DSAR-Reaktionszeit : Konform Datenverschlüsselung : Konform MFA-Durchsetzung : Warnung – bei 23 % der Administratorkonten ist MFA nicht aktiviert Datenaufbewahrung : Konform Das kompromittierte Systemadministratorkonto gehörte zu den 23 % ohne aktivierte Multi-Faktor-Authentifizierung. Aufgrund dieser Sicherheitslücke konnte der Angreifer allein mit gestohlenen Zugangsdaten auf das Konto zugreifen.