Muss man alle IT-Schwachstellen als Datenpanne melden?

Beispiel: Java-Sicherheitslücke „Log4Shell“

Man muss nicht weit zurückdenken, um eine Sicherheitslücke zu finden, die die Datenschutzaufsichtsbehörden auf den Plan gerufen hat: die Schwachstelle „Log4Shell“ (siehe auch Warnstufe Rot: Log4Shell gefährdet Server, Dienste und Apps).

So erklärte zum Beispiel Michael Will, Präsident des BayLDA, also des Bayerischen Landesamtes für Datenschutzaufsicht: „Das Bedrohungspotential der Schwachstelle Log4Shell kann kaum ernst genug genommen werden. Verantwortliche müssen nun umgehend aktiv werden, um die eigenen Systeme zu prüfen und die Schwachstelle zu beseitigen.“ Zudem betonte der Präsident des BayLDA: „Verstöße gegen die Sicherheitsanforderungen der Datenschutz-Grundverordnung können von uns mit empfindlichen Geldbußen geahndet werden.“

Zusätzlich muss geklärt werden, ob eine Meldepflicht nach DSGVO vorliegt. Hierzu das BayLDA: (Bayerische) Verantwortliche müssen aufgrund der erhöhten Gefährdungslage zur Einhaltung datenschutzrechtlicher Verpflichtungen unverzüglich prüfen, ob deren IT-Systeme und Anwendungen von der Java-Sicherheitslücke Log4Shell betroffen sind. Ist bereits eine Sicherheitsverletzung eingetreten, zum Beispiel weil die Sicherheitslücke aktiv ausgenutzt wurde und IT-Systeme mit personenbezogenen Daten betroffen sind, besteht nach Art. 33 DSGVO für Verantwortliche regelmäßig eine Meldeverpflichtung bei der zuständigen Datenschutzaufsichtsbehörde.

Beispiel: Sicherheitslücken bei Microsoft Exchange-Servern

Eine weitere Schwachstelle hat in jüngerer Vergangenheit die Aufsichtsbehörden für den Datenschutz sehr beschäftigt, die Sicherheitslücken in Microsoft Exchange. Heinz Müller, der Landesbeauftragte für Datenschutz und Informationsfreiheit Mecklenburg-Vorpommern, stellte fest, dass viele Betreiber von betroffenen Exchange-Servern, ihren Pflichten vorbildlich nachgekommen sind: „Wir haben in vielen Meldungen und Beratungsgesprächen wahrgenommen, dass sich viele Verantwortliche ihrer Verpflichtung einer sicheren Verarbeitung von personenbezogenen Daten bewusst sind und demzufolge ihr bestmögliches getan haben, um die Sicherheit der Verarbeitung möglichst schnell wiederherzustellen. Bemerkenswert ist auch, dass viele Akteure sehr transparent mit der Datenpanne umgegangen sind und proaktiv die Betroffenen informiert haben, auch wenn noch nicht abschließend klar war, ob und welche Daten überhaupt abgeflossen sind.“

Offensichtlich haben hier Unternehmen Meldungen vorgenommen, obwohl sie noch nicht wussten, ob Daten abgeflossen waren und welche Datenkategorien betroffen gewesen sind. Da stellt sich die Frage: Muss das immer so sein?

Die Frage nach der Meldepflicht

Die Landesbeauftragte für Datenschutz und Informationsfreiheit der Freien Hansestadt Bremen (LfDI) hatte ebenfalls eine signifikante Anzahl entsprechender Meldungen zu Verletzungen des Schutzes personenbezogener Daten erhalten. Sie wies alle Betreiberinnen und Betreiber von Microsoft-Exchange-Server-Infrastrukturen darauf hin, dass – soweit noch nicht geschehen – umgehend Maßnahmen zum Schließen der Sicherheitslücken und zur Prüfung auf Kompromittierung der Systeme erfolgen mussten.

Zudem wies sie auf die Pflicht der Verantwortlichen (Betreiber) hin, nach Artikel 33 der Datenschutz-Grundverordnung (DSGVO) Verletzungen des Schutzes personenbezogener Daten zu melden. Dies gilt bereits dann, wenn eine Kompromittierung erfolgt ist – auch dann, wenn kein Abfluss personenbezogener Daten erfolgt ist oder noch nicht festgestellt werden konnte, so die Datenschutzaufsicht.

Das BayLDA erläuterte nochmals explizit, ab wann die Meldepflicht nach Art. 33 DSGVO bei der zuständigen Datenschutzaufsichtsbehörde besteht:

Betroffene öffentliche Stellen und private Unternehmen, die Risiken für die bei ihnen gespeicherten personenbezogenen Daten nicht belastbar ausschließen können, müssen unverzüglich ihrer Meldepflicht nach Art. 33 DSGVO nachkommen.

Im Fall der Sicherheitslücken bei Microsoft Exchange-Servern erklärte das BayLDA: „Das Vorhandensein der vom BSI genannten Webshells oder weiterer Schadsoftware auf dem eigenen Server ist in diesem Fall ein deutliches Indiz für eine bestehende Meldepflicht, da nicht nur die Vertraulichkeit der personenbezogenen Daten, sondern auch die Integrität sowie gegebenenfalls die Verfügbarkeit des für die Datenverarbeitung wichtigen Systems gefährdet sein kann.“

Hieraus kann man ableiten: Gibt es Anzeichen für eine technische Kompromittierung und können Risiken für die gespeicherten personenbezogenen Daten nicht belastbar ausgeschlossen werden, liegen „deutliche Hinweise“ für eine Meldepflicht nach DSGVO vor.

Ob ein Datenabfluss an unbefugte Dritte dabei bereits festgestellt wurde, ist somit nicht die zwingende Voraussetzung für die Meldepflicht. Das kann man leicht nachvollziehen: Nur weil man keinen unerlaubten Datenzugriff festgestellt hat, bedeutet dies nicht, dass man diesen ausschließen kann.

Gibt es Hinweise auf eine Attacke auf eine Schwachstelle und können Risiken für personenbezogene Daten nicht zuverlässig ausgeschlossen werden, sollten Unternehmen unbedingt an ihre Meldepflichten denken.

Um nochmals das BayLDA zu Wort kommen zu lassen: Eine Meldung nach Art. 33 DSGVO bei der zuständigen Datenschutzaufsichtsbehörde ist durchzuführen, sobald ein Risiko für betroffene Personen hinreichend wahrscheinlich ist. Davon ist bei einer festgestellten Kompromittierung auf Grund der bekannten Gefährdungslage auszugehen.

Man kann also sagen: Nicht jede Schwachstelle in der IT setzt automatisch eine Meldepflicht nach DSGVO in Kraft. Zum einen muss ein System betroffen sein, über das personenbezogene Daten verarbeitet werden oder im Zugriff sind. Zum anderen muss man sich immer die Gefährdungslage durch eine Schwachstelle und die Risiken für die Betroffenen ansehen.

Zusammenfassung

Gibt es eine Schwachstelle, aber eine Ausnutzung der Schwachstelle kann ausgeschlossen werden, muss keine Meldung erfolgen. Wurde eine Schwachstelle ausgenutzt, aber es sind keine personenbezogenen Daten betroffen, ist zumindest nach DSGVO keine Meldepflicht eingetreten.

Ist eine Schwachstelle vorhanden, wurde sie ausgenutzt und sind personenbezogene Daten betroffen, aber ein Risiko für die Betroffenen kann ausgeschlossen werden, ist erneut nicht von einer Meldepflicht auszugehen.

Gibt es eine Schwachstelle, die Ausnutzung kann nicht ausgeschlossen werden, und es können personenbezogene Daten dadurch betroffen werden, dann ist von einer Meldepflicht auszugehen, es sei denn, Risiken für Betroffene können ausgeschlossen werden. Das kann dann der Fall sein, wenn die abgeflossenen Daten sicher verschlüsselt waren.