Umgang mit Sicherheitsvorfällen

Häufig geht im täglichen Datenschutz- und Datensicherheits-Geschäft ein Bereich ein wenig unter, der einen wesentlichen Einfluss auf das wirklich erreichte Sicherheits- und Datenschutzniveau hat: der Umgang mit Sicherheits- und Datenschutzvorfällen.

In der Praxis fehlt es leider an mustergültigen, öffentlich einsehbaren Vorfällen, an denen man lernen und seine eigene Organisation trimmen kann. Aktuell gibt es ein gutes Beispiel, an dem man einiges lernen kann:

Am 17. November 2012 hat der FreeBSD Security Officer einen Sicherheitsvorfall veröffentlicht: http://www.freebsd.org/news/2012-compromise.html

FreeBSD ist ein freies Unix, dass von einer Vielzahl von Entwicklern weiterentwickelt wird. Hierzu werden zentrale Systeme zur Quellcodeverwaltung und zur Koordinierung der Entwicklungsarbeit betrieben. Zwei von diesen Systemen sind kompromittiert worden.

Die genaueren Umstände der Sicherheitslücke kann man im Report nachlesen. Anhand des guten Reports kann man einige wesentliche Erfolgsfaktoren herausarbeiten, die man beachten sollte, wenn man als Sicherheits- oder Datenschutzbeauftragter einen Sicherheitsvorfall bearbeiten muss.

Vorab: Der Baustein 1.8 "Behandlung von Sicherheitsvorfällen" der IT-Grundschutz-Kataloge des Bundesamts für Sicherheit in der Informationstechnologie (BSI) ist eine gute Ausgangsbasis.

Kein Fingerpointing, keine Zuweisung von Schuld: Natürlich hat irgendjemand einen Fehler gemacht, wenn es einen Vorfall gab. Sich primär auf die Schuld-Frage zu konzentrieren behindert jedoch ein erfolgreiches Sicherheits- und Datenschutzmanagement. Wenn die "schuldige Person" ordentlich "eins auf den Deckel" bekommt, man evtl. sogar das Verhalten noch innerhalb der Organisation "an den Pranger" stellt dann erreicht man genau eins: Eine Kultur des Vertuschens und "unter-den-Teppich-kehrens". Natürlich ist es wichtig, die Ursachen des Vorfalls so klar und deutlich wie möglich herauszuarbeiten. Aber nicht auf Kosten der betroffenen Mitarbeiterinnen und Mitarbeiter. Das korrekte Melden und saubere Bearbeiten eines Vorfalls muss honoriert und nicht bestraft werden.

Kultur der kontinuierlichen Verbesserung: Vorfälle sind ein wichtiger Indikator, wo es technische und häufiger: organisatorische Mängel gibt. Ziel der Bearbeitung des Vorfalls ist die Mängelbehebung. Hier ist es wichtig, dass man bei jedem Vorfall prüft, ob es ein Einzelfall ist oder ob dahinter ein grundsätzlicheres Problem besteht. Als Sicherheits- oder Datenschutzbeauftragter, aber auch als Vorgesetzter muss man diese Kultur des Hinterfragens und Analysierens unterstützen. Natürlich ist es wichtig, die Lücke schnell zu schließen und weitere, schadhafte Auswirkungen eines Vorfalls zu begrenzen. Das Ergreifen von Sofortmaßnahmen ist aber nur der erste Schritt. Wirkliche Tiefenwirkung erreicht man erst durch eine umfassende Analyse.

Aufklärung so detailliert wie möglich: Für die Bewertung und das Ergreifen von wirksamen Sofortmaßnahmen ist es wichtig, den Sicherheitsvorfall so genau wie möglich zu analysieren. Es ist wichtig, alle Ereignisse möglichst genau zeitlich einzuordnen. Erst mit einer zeitlichen Komponente findet man Abhängigkeiten und auch mögliche Drittwirkungen auf andere Systeme und Komponenten. Gerade die "Zeitfindung" führt bei Sicherheitsvorfällen zu einer ersten, entscheidenden Abgrenzung und ist eine gute Ausgangsbasis für die Bewertung möglicher Auswirkungen.

Abgrenzung, Abgrenzung, Abgrenzung: Zur Bewertung eines Sicherheits- oder Datenschutzvorfalls muss man ein Modell über die möglichen Auswirkungen des Vorfalls erarbeiten. Diese Modellbildung funktioniert nur, wenn man die Grenzen des Vorfalls und seiner möglichen Auswirkungen klar umreissen kann. Erst durch das Festlegen auf möglicherweise betroffene Komponenten, Systeme, Daten, Personen... kann man die weiteren Schritte zur Mängelbehebung und Information planen. Die Kernfrage hierbei ist nicht, welche Systeme möglicherweise betroffen sind, sondern vielmehr, für welche Systeme man nachweisen kann, dass sie nicht betroffen sind.

Wiederholbare Installation- und Konfiguration von Systemen: Ist für ein System nicht nachweisbar, ob es von einem Sicherheitsvorfall betroffen ist oder nicht, muss das System neu aufgesetzt werden. Dies ist umso schmerzhafter, je weniger Dokumentation vorhanden ist und je mehr händische Arbeit notwendig ist. Organisationen, die ihre Systeme als "dokumentationsfreie Manufaktur" betreiben, tun sich hiermit erfahrungsgemäß sehr schwer. Für Organisationen, die verlässliche Build- und Restore-Prozesse haben, ist die Neu-Installation und Neu-Konfiguration von Systemen nur lästig, aber nicht existenziell bedrohend. Aus der Erfahrung mehrerer Sicherheitsvorfälle: Es ist einfacher neu aufzusetzen als zu flicken.

Fokus auf Maßnahmenenpfehlung: Die korrekte Aufarbeitung des Vorfalls ist wichtig, keine Frage. Wichtiger ist jedoch, konkrete Handlungsempfehlungen auszusprechen. Je konkreter, desto besser. Das gilt insbesondere für die Fälle, wo es eine Plicht zur Information der Betroffenen gibt (vgl. z.B. § 42a BDSG oder § 27a LDSG Schleswig-Holstein

Und abschließend noch eine Klarstellung zu einem häufigen Mythos: Die Anzahl der Vorfälle ist keine geeignete Kennzahl für ein Managementsystem. Weder die absolute Anzahl, noch die Tendenz ("10% weniger Vorfälle als im Vorjahr") sagt etwas über das Niveau und das Funktionieren des Datenschutz- oder Sicherheitsmanagements aus. Wenn man dringend Kennzahlen hierzu braucht, sollte man diese eher auf die Qualität der Sicherheitsvorfälle beziehen, z.B. die durchschnittliche Anzahl der betroffenen Systeme, ob personenbezogene Daten von Kunden betroffen waren,....

Die bisherige Erfahrung zeigt, dass die Qualität im Umgang mit Sicherheits- und Datenschutzvorfällen ein guter Indikator dafür ist, wie gut das Datenschutz-. und Sicherheitsmanagement einer Organisation funktioniert.


Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Noch keine Kommentare

Kommentar schreiben

Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

Was ist drei plus vier? (Bitte einfach die Zahl sieben eintragen :-)