Ein Grundsatz des Datenschutzes ist es, dass personenbezogene Daten irgendwann auch wieder gelöscht werden müssen.

Unternehmen sind daher grundsätzlich verpflichtet, die bei ihnen verarbeiteten personenbezogenen Daten nach Zweckwegfall bzw. nach Ablauf sich daran anschließender Aufbewahrungsfristen zu löschen (Grundsatz der Speicherbegrenzung, „Recht auf Vergessenwerden“).

Gerade bei Einsatz von Datenverarbeitungssystemen ist dies jedoch nicht immer so einfach, da man auf die Funktionen, die der Hersteller zur Löschung bereitstellt oder eben nicht bereitgestellt hat, angewiesen ist. Selbst wenn eine solche Löschfunktion vorhanden ist, bedeutet das noch nicht, dass die Daten dann auch gelöscht sind i.S.e. irreversiblen Entfernung der Daten vom Datenträger (Festplatte, Speicherchip etc.).

Unternehmen können sich auch nicht darauf berufen, dass die Löschung aufgrund technischer Gründe unmöglich oder aufgrund des Aufwands einer entsprechenden Nachrüstung unzumutbar ist. Gemäß § 35 BDSG-Neu kann die Pflicht zur Löschung zwar entfallen, wenn dies mit einem unverhältnismäßig hohen Aufwand verbunden ist. Dies gilt jedoch nur im Fall einer nicht-automatisierten Datenverarbeitung.

Daher dürfen Unternehmen nur solche Technik einsetzen, die eine datenschutzgerechte Löschung durch entsprechende Funktionalitäten erlaubt (Grundsatz von Privacy by Design). Die Pflicht zur Löschung und zur Einhaltung von Privacy by Design trifft eben denjenigen, der die Technik einsetzt und damit personenbezogene Daten verarbeitet.

Die Landesbeauftragte für Datenschutz in Schleswig-Holstein (ULD) hätte sich zwar „gewünscht, dass die Datenschutz-Grundverordnung auch die Hersteller unmittelbar zu eingebautem Datenschutz verpflichtet“, aber dies sei „immerhin für die kommende europäische e-Privacy-Verordnung so geplant“ (vgl. unter https://www.datenschutzzentrum.de/artikel/1208-Datenschutz-einbauen!-Appell-an-die-Hersteller-und-Betreiber-am-Safer-Internet-Day.html).

Man kann nur hoffen, dass Produkte, deren Einsatz Bußgelder auslösen können (Art. 83 Abs. 4 lit. a), Abs. 5 lit. a), b) DSGVO), sich zukünftig schwerer verkaufen lassen. Denn nur somit lässt sich derzeit überhaupt Druck auf Hersteller und Entwickler aufbauen, wenn sie den Markt der Europäischen Union auch weiterhin beliefern möchten.

S. Kieselmann
Beraterin für Datenschutz
Dipl.sc.pol.Univ.

Auch die Hardware der Beschäftigten sollte mit Bedacht und Verstand ausgewählt werden. Hacker können nun auch die Verbindung zwischen Tastatur und Computer hacken und somit eigene Befehle an den Computer senden. Mit solchen MouseJack-Angriffen können nicht nur Programme am Computer gestartet werden, sondern auch Scripte geschrieben und ausgeführt, sowie Dateien ins Internet hochgeladen werden.

Ziel der Hacker ist es, sensible Daten zu entwenden oder Schadsoftware auf Ihrem Computer zu installieren. Es sind aktuell beinahe alle gängigen Funktastaturen im 2,4-GHz-Band anfällig für einen solchen Angriff. Mit Hilfe von Updates kann auf dieses Risiko reagiert werden. Idealerweise sollten zukünftig nur noch Tastaturen angeschafft werden, die über Bluetooth oder das alt bewerte Kabel funktionieren. Bluetooth ist durch die oben beschriebenen Angriffe nicht gefährdet.

Der Angriff ist schnell und einfach durchzuführen. Benötigt wird hierfür nur ein Empfänger und eine Antenne, mit denen dann die Funksignale der Tastatur abgefangen und so die Adressen aktiver Mäuse und Tastaturen ermittelt werden können. Die Reichweite des Empfängers liegt bei bis zu 1.000 m im Freien und 50 m in geschlossenen Räumen.

Vor allem in sensiblen Bereichen wie beispielsweise der Personalabteilung sollte auf solche Funktastaturen verzichtet werden.

Dr. Bettina Kraft
Volljuristin, Senior Consultant für Datenschutz

Anfang Januar 2018 wurden drei erhebliche Schwachstellen in den meisten modernen Prozessoren veröffentlicht. Diese wurden von drei unterschiedlichen Forscherteams entdeckt (Google Project Zero, Cyberus Technology, Graz University of Technology) und sind unter den zwei Namen

• Meltdown (CVE-2017-5754 Rogue Data Cache Load) und
• Spectre (CVE-2017-5715 - Branch Target Injection und CVE-2017-5753 - Bounds Check Bypass)

bekannt geworden. Sie betreffen nicht nur Desktop- und Serverrechner, sondern auch Mobilgeräte. [1] [2]

Diese Schwachstellen ermöglichen es einem Angreifer potenziell den gesamten Arbeitsspeicher eines Systems auszulesen - inklusive beispielsweise Passwörtern, Krypto-Schlüsseln oder persönlichen und vertraulichen Daten.

Bei den drei Sicherheitslücken handelt es sich um Designprobleme in den Prozessoren. Daher sind sie praktisch für alle Betriebssysteme (Windows, MacOS, Linux, AIX, Android, iOS, etc.) relevant. Meltdown kann zwar durch Softwarepatches vollständig behoben werden, Spectre jedoch – zumindest mit Stand heute – nicht. Ein vollständiger Schutz vor Spectre ist durch die jetzigen Patches nicht gegeben, der Angriff wird nur erschwert, bzw. die Erfolgsquote reduziert.

Wording in Veröffentlichungen

Man liest sehr oft, dass durch aktuelle Patches ein Spectre-Angriff erschwert würde. Diese Aussage ist zwar richtig, man muss sie aber richtig lesen. Leider bleibt dann nicht mehr viel an Sicherheit davon übrig:

Ein einzelner Angriff zielt darauf ab, einen Datenblock aus dem CPU-Speicher auszulesen, der einem nicht gehört. Das dauert vielleicht einige Millisekunden. Der Erfolg eines einzelnen Angriffs ist nicht garantiert, man kann es aber immer wieder probieren, irgendwann klappt es.

Nach dem Patch sinkt die Chance, dass es klappt, was aber leider nicht mehr heisst, als dass ein Angreifer es halt ein paar mal mehr versuchen muss, bis es klappt.

Die Folge ist nur, dass man es nur schwer schaffen wird sich in kurzer Zeit (Sekunden oder Minuten) ein zusammenhängendes, vollständiges und zeitlich integres Speicherabbild des Hosts zusammenzubauen. In längerer Zeit bekommt man aber trotzdem alle möglichen Speicherfragmente zu sehen - und das kann reichen. Es ist ein wenig wie Fliegen fangen. Es ist schwer, aber irgendwann kriegt man sie schon.

Zur Darstellung der möglichen Auswirkungen haben wir verschiedene Szenarien unterschieden:

- Einzelplatz-PC bzw. Smartphones

Mit Hilfe einer der Schwachstellen kann ein Angreifer Zugriff auf Daten erhalten, auf die er sonst keinen Zugriff hätte. Hierzu muss er Code auf dem System ausführen dürfen ohne besondere Rechte dafür haben zu müssen, was im Grunde überall, z.B. durch JavaScript, oder durch eine präparierte App auf einem Smartphone, möglich ist. Dabei können Datenfragmente auch aus Speicherbereichen anderer Prozesse oder virtueller Maschinen ausgelesen werden und zu einem Gesamtbild zusammengesetzt werden. Aber auch schon einzelne Speicherfragmente können Informationen wie Passwörter, Verschlüsselungs-Keys, E-Mails oder dergleichen enthalten.

- Client-Server Architektur

Mit Hilfe von Meltdown & Spectre können nur Daten aus dem Speicher des physischen Servers ausgelesen werden, auf dem der Angriffscode ausgeführt wird. Somit besteht bei physisch dedizierten Systemen keine direkte Gefahr für Angriffe vom Client aus, solange kein Code vom Client aus auf dem Server ausgeführt werden kann. Dies ist zumindest bei Fileserver Anwendungen i.d.R. nicht der Fall. Anders sieht es aus, wenn man RDP oder Citrix (oder ssh oder anderen interaktiven) Zugriff auf einen Rechner hat.

- Virtualisierte Systeme

Bei virtualisierten Systemen muss zwischen voll-virtualisierten Systemen (z.B. VMware, Hyper-V) und para-virtualisierten (bei der Para-Virtualisierung steht dem Gastsystem lediglich ein API-Zugriff auf die Host-Hardware zur Verfügung, z.B. Xen) bzw. Betriebssystemvirtualisierung (hierbei teilen sich das Gastsystem und das Hostsystem den Kernel, z.B. Docker, Linux Container LXC) unterschieden werden.

Para-Virtualisierung und Betriebssytemvirtualisierung können sowohl durch Meltdown als auch durch Spectre angegriffen werden. Hierbei kann u.U. der gesamte Arbeitsspeicher des Hosts ausgelesen werden - und damit auch der aller virtuellen Maschinen.

Voll-virtualisierte Systeme sind für Meltdown nur dahingehend verwundbar, dass innerhalb eines virtuellen Systems Daten ausgelesen werden können, innerhalb von diesem aber wiederum aus dem gesamten dieser virtuellen Maschine zugeordneten Speicher - also auch der anderer Prozesse und Benutzer oder des Kernels.

Spectre kann theoretisch auch hier die Grenzen zwischen den virtuellen Systemen überwinden und von anderen Systemen und dem Host Daten auslesen. Google hat nach eigenen Angaben in einem PoC bereits gezeigt, dass bei einer virtuellen Maschine Daten aus dem Kernelspeicher des Hosts ausgelesen werden konnten. [2]

- Cloud

Für Cloud Anbieter, welche (Para-)Virtualisierung nutzen, gelten die gleichen Aussagen von oben für virtualisierte Systeme. Allerdings ist der Impact möglicherweise noch größer als innerhalb einer Institution: es können unter Umständen Daten von anderen Kunden ausgelesen werden. Wirklich wirksame Gegenmaßnahmen gibt es derzeit nicht.

Diesen Aspekt darf man sich getrost auf der Zunge zergehen lassen und das erste Aha-Erlebnis noch ein wenig mit Risiko- und Compliance-Aspekten nachwürzen.

Komplexität eines Angriffs

Die Schwachstellen können ausgenutzt werden, wenn ein Angreifer irgendwelchen Code auf einem System ausführen kann, ohne besondere Rechte. Dies ist aber immer der Fall (er benutzt ja Programme) und kann z.B. auch schon über den vorhandenen Webbrowser geschehen, z.B. durch JavaScript. Bei Meltdown sind nicht einmal genaue Kenntnisse des angegriffenen Prozesses notwendig, bei Spectre hingegen sind tiefgründige Kenntnisse über den eingesetzten Prozessor, dessen Branch Prediction Unit, sowie den anzugreifenden Prozess notwendig. Dieses Wissen ist derzeit nicht öffentlich verfügbar. Die vorgestellten Proof-of-Concepts wurden bisher nur unter Laborbedingungen durchgeführt. Aber eben nur "bisher".

Bis heute sind offenbar keine Exploits (Ausnutzen der Schwachstellen von einem Angreifer) in Umlauf. Da der Angriff jedoch keine Spuren hinterlässt, kann nicht mit Sicherheit gesagt werden, dass keine Angriffe stattfanden. Insbesondere durch das Bekanntwerden des Angriffs ist mit Sicherheit davon auszugehen, dass früher oder später neue Exploits entwickelt und verbreitet werden.

Das Szenario, dass nach und nach immer bessere Angriffswerkzeuge („Exploits“) öffentlich verfügbar sein werden und der Werkstudent oder die Sekretärin in ihrer Citrix-Sitzung den Serverspeicher des Virtualisierungs-Hosts per Skript in einer E-Mail auslesen können, ist nicht so sehr weit hergeholt. Aber auch Remote Angriffe per Web-Seite sind möglich.

Antivirus

Virenscanner werden vermutlich nur eingeschränkt - wenn überhaupt - in der Lage sein, Angriffe zu erkennen, da diese weitgehend dem normalen Verhalten von Programmen entsprechen. Klar es wird Heuristiken geben, aber auch klar, die kann man austricksen.

Datenschutzaspekte

Wie weit kann virtuellen oder Multiuser-Systemen überhaupt noch vertraut werden und wie teuer kann es unter der DSGVO werden, wenn man sich nicht ernsthaft mit der Lösung beschäftigt hat? Man kann die Situation durchaus so bewerten, dass ohne weitere Maßnahmen, die über bloßes Patchen hinausgehen, die Sicherheit der Datenverarbeitung nach Art. 32 DSGVO nicht mehr überall gewährleistet ist. Über den Art. 83 DSGVO kann man dann erahnen, wie teuer es werden könnte (nämlich bis zu theoretischen 10Mio. € oder 2% des weltweiten Vorjahresgesamtumsatzes des Unternehmens).

Andererseits wird kein Datenschutzbeauftragter seinen Mandanten raten können, die Datenverarbeitung vorübergehend auszusetzen, bis man alles umgebaut und die Daten nach Hardware sortiert getrennt verarbeiten kann.

Wir werden diese Frage der Einschätzung daher an die Aufsichtsbehörden für den Datenschutz richten und weiter berichten!

Fazit

Durch die Bemühungen der verschiedenen Soft- und Hardwarehersteller wurde in der Vergangenheit die Sicherheit stetig verbessert. Nun zeigen Meltdown und Spectre, dass sich die Risikolage von jetzt auf gleich ändern kann.

Meltdown und Spectre zeigen sehr grundlegende Schwachstellen auf, die auf Hardwaredesignproblemen beruhen. Wodurch, zumindest bei Spectre, das Patchen deutlich erschwert, wenn nicht gar unmöglich wird. Somit ist die eigentliche Herausforderung, das Risiko entsprechend (neu) zu bewerten und wie in einem Unternehmen alternative, kompensatorische Maßnahmen umgesetzt werden können. Spectre-Patches können u.E. derzeit nicht als wirksam angesehen werden.

Die Auswirkungen sind im Grunde so gewaltig, dass man gerne dazu tendiert sie nicht wahrhaben zu wollen. Bringt aber nix.

Aktuelle Empfehlungen

• Die Schwachstellen sind im Rahmen des regulären Schwachstellen Managements zu bewerten und zu behandeln, also im Rahmen des jeweiligen Verfahrensrisikos. Wichtig: Rosa Brille weg und Risiken realistisch einschätzen! Wie Sie handeln bleibt immer noch Ihnen überlassen, aber machen Sie sich nichts vor!
• Nach erfolgreichem Test sollten die vorhandenen Patches (Betriebssystem und Mikrocontroller) ausgerollt werden. Tests sind wichtig, da die Hersteller in der Eile auch schon nicht-funktionale Patches verteilt haben.
• Im Rahmen des Risikomanagementprozesses sollten die Schwachstellen bzw. Patches zumindest für absehbare Zeit, in kurzen Abständen, etwa wöchentlich, neu bewertet werden.
• Aktuell hilft wohl nur die hardwarebasierte Trennung von wirklich relevanten Daten. Wer bisher Medizindaten und die Parkplatzverwaltung auf derselben Hardware hatte, sollte umdenken!
• Vendor Management: fordern Sie von Ihrem Cloud Anbieter Aussagen ein, wie er gedenkt Ihre Daten vor anderen zu schützen! Hier wird es auch rechtlich spannend, denn was er tun muss und was nicht, und was dann davon ihr Problem bleibt oder seins, das hängt von Ihrem Vertrag ab.
• Wenn Sie personenbezogene oder hochsensible Daten bearbeiten, empfehlen wir einen noch strengeren Blick. Noch gibt es keine aufsichtsbehördliche Stellungnahme wie mit einer Situation umzugehen ist, in die man durchaus interpretieren kann, dass viele Verfahren auf absehbare Zeit nicht weiter betrieben werden dürften. Unter der Strafandrohung des BDSG war das nicht weiter schlimm. Die DSGVO wartet da mit ganz anderen Geschützen auf.

Autoren: Florian Franke, Holger Heimann, Christian Stehle

[1] https://meltdownattack.com/

[2] https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html

Die Verarbeitung personenbezogener Daten kann nur auf die Einwilligung der betroffenen Person gestützt werden (Art. 6 Abs. 1 lit. a), Art. 7 DSGVO), wenn diese wirksam erteilt worden ist:

• Die betroffene Person muss ihre Einwilligung ausdrücklich erklären, durch ihre Unterschrift oder zumindest durch eine unmissverständliche Handlung.
• Die betroffene Person muss vor Abgabe ihrer Einwilligung ausreichend über die geplante Datenverarbeitung informiert worden sein (-> Transparenz, Informationspflichten aus Art. 13 DSGVO).
• Die betroffene Person muss vor Abgabe ihrer Einwilligung über ihr Widerrufsrecht in Kenntnis gesetzt worden sein (Art. 7 Abs. 3 DSGVO).
• Die betroffene Person muss ihre Einwilligung freiwillig (d.h. ohne jeglichen Zwang) erteilt haben.
• Der Verantwortliche muss beweisen können, dass die Einwilligung vorliegt (-> schriftlich, elektronisch, Archivierung).

Gerne verweisen wir auf unseren Blogbeitrag vom 15.11.2016.

Da jedoch im wirtschaftlichen Abhängigkeitsverhältnis zwischen Beschäftigtem und Arbeitgeber gerade das Kriterium der Freiwilligkeit oftmals nur unzureichend erfüllt ist, trifft § 26 Abs. 2 BDSG-Neu zusätzliche Regelungen, unter welchen Umständen Beschäftigte in die Verarbeitung ihrer Daten durch den Arbeitgeber wirksam einwilligen können:

• Durch die Einwilligung muss der Beschäftigte einen rechtlichen oder wirtschaftlichen Vorteil erreichen oder zumindest müssen Arbeitgeber und Beschäftigter damit gleichgelagerte Interessen verfolgen.
• Dem Beschäftigten dürfen keine arbeitsrechtlichen Konsequenzen oder sonstigen Nachteile für sein bestehendes Arbeitsverhältnis drohen, wenn er seine Einwilligung nicht erteilt oder die Einwilligung widerruft.
• Die Einwilligung muss grundsätzlich in Schriftform erteilt werden.

S. Kieselmann
Beraterin für Datenschutz
Dipl.sc.pol.Univ.

Mit Art. 3 Abs. 2 DSGVO tritt das Marktortprinzip in Kraft. Damit gilt die Datenschutzgrundverordnung (DSGVO) zwingend auch für jedes außereuropäische Unternehmen, wenn es Waren und Dienstleistungen betroffenen Personen innerhalb der EU anbietet. Die Zahlung eines Entgelts spielt dabei keine Rolle. Daher fallen auch Anbieter Sozialer Netzwerke (= Plattformbetreiber) hierunter (vgl. unter https://www.lda.bayern.de/media/dsk_kpnr_7_marktortprinzip.pdf).

Bisher ist unklar, inwieweit neben den Plattformbetreibern auch Unternehmen und Behörden (= Inhalteanbieter), die sich auf diesen Plattformen präsentieren und hierüber Inhalte anbieten, als Verantwortliche i.S.v. Art. 4 Nr. 7 DSGVO hinsichtlich der damit einhergehenden Datenverarbeitung anzusehen sind.

Die deutschen Aufsichtsbehörden haben bisher zumindest für öffentliche Stellen eine "datenschutzrechtliche Mitverantwortung" angenommen (vgl. unter https://www.baden-wuerttemberg.datenschutz.de/wp-content/uploads/2017/11/2017.11.02._Richtlinie-zur-Nutzung-sozialer-Netzwerke-durch-%C3%B6ff.-Stellen.pdf#). Denn auch die Inhalteanbieter leisten „einen wesentlichen Beitrag zur Realisierung des Geschäftsmodels" der Plattformbetreiber (vgl. unter https://www.datenschutzzentrum.de/artikel/983-.html).

Das Bundesverwaltungsgericht legte am 25.02.2016 dem EuGH in einem Verfahren, bei dem die Aufsichtsbehörde in Schleswig-Holstein beteiligt ist, u.a. die Frage zur diesbezüglichen datenschutzrechtlichen Verantwortung vor (vgl. unter https://www.datenschutzzentrum.de/artikel/1013-.html).

Der Generalanwalt hat in seinen Schlussanträgen zu dieser Rechtssache am 24.10.2017 festgestellt (vgl. unter https://www.datenschutzzentrum.de/artikel/1171-EuGH-Generalanwalt-Keine-Verantwortungsluecken-im-Datenschutz-bei-dem-Betrieb-von-Facebook-Fanpages.html), dass auch ein Inhalteanbieter, der solche Plattformen Sozialer Netzwerke nutzt, sich dabei nicht einfach „seinen Verpflichtungen im Bereich des Schutzes personenbezogener Daten (…) entziehen“ darf. Dies solle auch dann gelten, wenn der Inhalteanbieter selbst „keinen Zugang zu den Daten hat“ und auch die „Geschäftsbedingungen im Vorhinein vom [Plattformbetreiber] vorbereitet werden und nicht verhandelbar sind“.

Folgt der EuGH dieser Einschätzung, dann werden sich die Inhalteanbieter die Datenverarbeitungen durch die Plattformbetreiber, die in den wenigsten Fällen datenschutzrechtlichen Vorgaben entsprechen (so hatte bspw. die französische Aufsichtsbehörde im Mai 2017 ein Bußgeld gegen Facebook verhängt, https://www.cnil.fr/en/facebook-sanctioned-several-breaches-french-data-protection-act), zurechnen lassen müssen.

Angesichts der Bußgelder, die sich durch die Datenschutzgrundverordnung (DSGVO) drastisch erhöhen, würden Unternehmen mit der Nutzung solcher Plattformen ein hohes Risiko eingehen, wenn sie mit dem Plattformbetreiber als „gemeinsam für die Verarbeitung Verantwortliche“ auftreten. Daher bliebe wohl am Ende nur die Möglichkeit, sich gegen die Nutzung solcher Plattformen zu entscheiden, sofern die Plattformbetreiber ihre Datenverarbeitungen nicht an gesetzliche Vorgaben anpassen.

S. Kieselmann
Beraterin für Datenschutz
Dipl.sc.pol.Univ.

Das anstehende Inkraft-Treten der DSGVO im Mai 2018 hat die Bedeutung des Datenschutzes als unternehmenskritische Thematik in den Vordergrund gerückt.

Insbesondere für Unternehmen aus der Software-Branche ergeben sich daraus zahlreiche neue Herausforderungen. Bestehende Software muss im Hinblick auf die datenschutzrechtlichen Anforderungen der DSGVO evaluiert und ggf. angepasst werden; Kunden verlangen Compliance in Bezug auf abgebildete Prozesse und insbesondere die Verarbeitung personenbezogener Daten in der Software. Und nicht zuletzt – Software, die keine gesetzeskonforme Datenverarbeitung ermöglicht ist mangelhaft.

Art. 25 DSGVO fordert weiterhin explizit Datenschutz durch Technikgestaltung (‚Privacy by Design‘) sowie datenschutzfreundliche Voreinstellungen (‚Privacy by Default‘).

All diese Anforderungen gilt es, bereits im Software-Entwicklungsprozess nachhaltig zu verankern, um sowohl Qualität sicher zu stellen als auch um teure Nachbesserungen zu vermeiden.

Wie eine solche Implementierung aussehen kann, wird exemplarisch anhand der 5 Phasen des agilen Projektzyklus dargestellt:

1. Schritt: Erkennen. Verantwortlich: Product Owner, Projekt-Manager

Datenschutzrelevanz erkennen, Indikatoren hierfür sind bspw.

• Personenbezogene Daten sind Bestandteil der User Story
• Personenbezogene Daten werden an Dritte übermittelt
• Big Data / Smart Data Bezug

2. Schritt: Beschreiben. Verantwortlich: Product Owner, Projekt-Manager, Datenschutzbeauftragter

Teil der User Story werden zwingend die datenschutzrechtlichen Anforderungen, bspw.

• Datenschutzfreundliche Voreinstellungen
• Datenverschlüsselung muss vorgesehen werden
• Festlegung von Speicherfristen
• Protokollierung von Zustimmungen
• Rechte- / Rollenkonzept
• Folgenabschätzung soweit erforderlich

3. Schritt: Umsetzen. Verantwortlich: Software-Developer

Die dem Stand der Technik entsprechende Umsetzung ist zu gewährleisten, bspw.

• Anerkannte Richtlinien zur sicheren Software-Entwicklung (bspw. OWASP) werden berücksichtigt
• Echtdaten müssen anonymisiert werden, bevor sie in Test- und Entwicklungssysteme gelangen
• Einsatz anerkannter Verschlüsselungsverfahren

4. Schritt: Abnehmen. Verantwortlich: Product Owner, Projekt-Manager

Teil des Akzeptanz-Prozesses ist auch die Prüfung, ob die datenschutzrechtlichen Anforderungen korrekt umgesetzt wurden. Zusätzlich ist zu prüfen, ob das Verzeichnis der Verarbeitungstätigkeiten ergänzt oder modifiziert werden muss.

5. Schritt: Betreiben. Verantwortlich: IT-Operations, Kunde

Soweit die Software selbst betrieben wird, ist insbesondere zu beachten:

• Sicherstellung von Verfügbarkeit und Belastbarkeit der Systeme
• Definition eines Desaster Recovery Prozesses
• Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der getroffenen technischen und organisatorischen Schutzmaßnahmen
• Definition Backup-Prozess

Eine Umsetzung dieser Vorgehensweise hat sich in der Praxis als zuverlässige Methodik bewährt, setzt allerdings voraus, dass bei den Projektbeteiligten bereits eine Sensibilisierung für die Themen Datenschutz und Datensicherheit vorhanden ist. Insofern bietet es sich an, den Prozess im Rahmen einer Awareness-Kampagne zu etablieren.

Stephan A. Klein
Rechtsanwalt, Senior Consultant Datenschutz

Derzeit wird im EU-Parlament diskutiert, ob in der ePrivacy-Verordnung der Datenschutz dadurch deutlich gestärkt werden soll, dass Voreinstellungen im Browser für Webseitenbetreiber, Tracking-Firmen und letztlich die digitale Werbeindustrie rechtsverbindlich sein sollen. D.h. eine Do-Not-Track-Einstellung im Browser müsste dann zwingend beachtet werden.

Um die Auswirkungen besseren Datenschutzes auf die digitale Werbewirtschaft besser einschätzen zu können, hat das Bundeswirtschaftsministerium eine Studie in Auftrag gegeben, die nun vorgestellt und veröffentlicht wurde unter http://www.wik.org/fileadmin/Studien/2017/2017_ePrivacy-BMW.pdf. Das WIK (Wissenschaftliches Institut für Infrastruktur und Kommunikationsdienste GmbH) schätzt, dass bei Inkrafttreten solcher Regelungen binnen kurzer Zeit mit einer Reduktion des gesamten digitalen Werbebudgets von einem Drittel zu rechnen sei. Dieser Kapitalentzug könne die europäische Digitalwirtschaft weiter von den USA abkoppeln, da dort Gelder aus der Online-Werbung zunehmend in die Entwicklung neuer Geschäftsmodelle und Technologien fließen würden. Gelder, die hierzulande dringend für Zukunftsthemen wie z.B. das autonome Fahren gebraucht würden.

Bemerkenswert ist allerdings, dass für die Studie lediglich Vertreter der Wirtschaft befragt wurden, unter anderem die Mediengruppe RTL, Facebook, AGOF und Zeit-Online. Entsprechend wurde die Studie bereits bemängelt, vor allem von der Bundesbeauftragten für Datenschutz. Sie meint, die Studie konzentriere sich nur auf die vermeintlich negativen Folgen, berücksichtige aber in keiner Weise die potenziellen Chancen, die sich für die Branche aufgrund der Änderungen ergeben könnten. Die entsprechende Pressemitteilung finden Sie unter https://www.bfdi.bund.de/DE/Infothek/Pressemitteilungen/2017/22_ePrivacy%20WIK-Studie.html.

Es wird sich zeigen, inwieweit Lobbyisten die geplanten Regelungen aufweichen können.

Dr. W. Steinmetz
Berater für Datenschutz

Wohnungsmangel ist v.a. in vielen großen Städten Realität. Immobilienmakler können daher unter einer Vielzahl von Interessenten auswählen, von denen sie eine Menge personenbezogener Daten anfordern (z.B. Namensangaben, Geburtsdatum, Kontaktdaten, Anschrift, Familienstand, Angaben zum bestehenden Arbeitsverhältnis), u.a. auch sensible Daten, wie Personalausweisdaten sowie Angaben zu Vermögensverhältnissen (z.B. Lohn-und Gehaltsnachweise, Schufa-Auskunft).

Der Datenschutzgrundsatz der Datenminimierung ist für die meisten Immobilienmakler dabei anscheinend kein Thema. So hat das Bayerische Landesamt für Datenschutzaufsicht in einer Prüfaktion bei 86 Immobilienmaklern, veranlasst durch die anhaltenden Beschwerden betroffener Personen, festgestellt, dass „bei fast allen geprüften Maklern (…) erheblicher Handlungsbedarf bezüglich des Umfangs der erhobenen personenbezogenen Daten“ besteht (siehe Tätigkeitsbericht 2015/2016, S. 22, abrufbar unter https://www.lda.bayern.de/media/baylda_report_07.pdf).

Über die Kontakt- und Selbstauskunftsformulare müssen die Interessenten oftmals ihre Daten in vollem Umfang preisgeben, bevor konkrete vertragliche Verhandlungen überhaupt stattfinden – nach dem Motto, wer sich nicht transparent macht, bekommt schon gar keinen Besichtigungstermin. Insbesondere die Anforderung von Personalausweiskopien wird hierbei von den Aufsichtsbehörden bemängelt, zumal eine automatisierte Speicherung der Ausweisdaten bereits nach dem PAuswG unzulässig ist. In Kombination mit Defiziten bei der Datensicherheit und Datenlöschung drohen der Immobilien-Branche empfindliche Geldbußen ab dem 25.05.2018, wenn die Datenschutzgrundverordnung (DSGVO) verbindlich wird. Daher sollten auch Immobilienmakler die verbleibende Zeit nutzen, ihre Prozesse zur Datenerhebung und -verarbeitung an datenschutzrechtliche und datensicherheitstechnische Vorgaben anzupassen.

S. Kieselmann
Beraterin für Datenschutz
Dipl.sc.pol.Univ.

Auch in der Datenschutzgrundverordnung (DSGVO) ist die Pflicht zur Benennung eines Datenschutzbeauftragten für nicht-öffentliche Stellen in Art. 37 Abs. 1 lit. b) und c) DSGVO für folgende Fälle vorgesehen:

• Die Kerntätigkeit des Verantwortlichen oder des Auftragsverarbeiters besteht in der Durchführung von Verarbeitungsvorgängen, welche aufgrund ihrer Art, ihres Umfangs und/oder ihrer Zwecke eine umfangreiche regelmäßige und systematische Überwachung von betroffenen Personen erforderlich machen.
• Die Kerntätigkeit des Verantwortlichen oder des Auftragsverarbeiters besteht in der umfangreichen Verarbeitung besonderer Kategorien personenbezogener Daten i.S.v. Art. 9 Abs. 1 DSGVO oder personenbezogener Daten über strafrechtliche Verurteilungen und Straftaten gemäß Art. 10 DSGVO.

Allerdings sieht Art. 37 Abs. 4, S.1, 2. HS DSGVO eine Öffnungsklausel vor. Danach kann der nationale Gesetzgeber weitere Tatbestände vorsehen, die zu einer Bestellpflicht führen: „In anderen als den in Absatz 1 genannten Fällen können der Verantwortliche oder der Auftragsverarbeiter (…) einen Datenschutzbeauftragten benennen; falls dies nach dem Recht (…) der Mitgliedstaaten vorgeschrieben ist, müssen sie einen solchen benennen.“

Dies hat der deutsche Gesetzgeber getan, und zwar für nicht-öffentliche Stellen in § 38 BDSG-Neu. Ergänzend zu Art. 37 Abs. 1 lit. b) und c) DSGVO gilt gemäß § 38 Abs. 1 BDSG-Neu eine Bestellpflicht für folgende Fälle:

• Der Verantwortliche oder Auftragsverarbeiter beschäftigt in der Regel mindestens 10 Personen ständig mit der automatisierten Verarbeitung personenbezogener Daten (§ 38 Abs. 1 S. 1 BDSG-Neu).
• Der Verantwortliche oder Auftragsverarbeiter nimmt Verarbeitungen personenbezogener Daten vor, die einer Datenschutz-Folgenabschätzung i.S.v. Art. 35 DSGVO unterliegen (§ 38 Abs. 1 S. 2 BDSG-Neu); dabei ist es unerheblich, wie viele Personen mit der Datenverarbeitung beschäftigt sind.
• Der Verantwortliche oder Auftragsverarbeiter verarbeitet personenbezogene Daten geschäftsmäßig zum Zweck der Übermittlung, der anonymisierten Übermittlung oder für Zwecke der Markt- oder Meinungsforschung (§ 38 Abs. 1 S. 2 BDSG-Neu); hier spielt die Anzahl der Personen, die mit der Datenverarbeitung beschäftigt sind, ebenfalls keine Rolle.

Der Verstoß gegen die Pflichten aus Art. 37 DSGVO ist gemäß Art. 83 Abs. 4 lit. a) DSGVO bußgeldbewehrt.

S. Kieselmann
Beraterin für Datenschutz
Dipl.sc.pol.Univ.

Beim Aufbau einer geeigneten Infrastruktur zum IT Governance, Risk & Compliance Management (IT GRC Management) sollten folgende Schritte durchgeführt werden:

Aktivitäten in der Plan-Phase:

1. Einbindung der zu beteiligenden Stellen ins Projekt:
   1. IT-Sicherheitsbeauftragter zur Projektsteuerung (dieser ist i.d.R. der Eigner der aufzubauenden IT GRC Infrastruktur)
   2. Datenschutzbeauftragter im Rahmen der durchzuführenden Datenschutz-Folgenabschätzung nach der EU-Datenschutzgrundverordnung, da im Zuge eines IT GRC Managements stets personenbezogene Profilingdaten verarbeitet werden
   3. Betriebsrat bzw. Personalrat im Rahmen betrieblicher Mitbestimmung, da im Zuge eines IT GRC Managements i.d.R. auch Verhaltenskontrollen unter Zuhilfenahme von technischen Einrichtungen durchgeführt werden
   4. Rechtsabteilung zur Bestimmung weiterer rechtlicher Anforderungen, die beim Aufbau der IT GRC Infrastruktur zu beachten sind (z.B. zur Revisionsfestigkeit von Protokollen und der Einhaltung bestehender Aufbewahrungs- und Löschungspflichten)
2. Festlegung der einzuhaltenden Sicherheitsziele, die u.U. (z.B. aufgrund gesetzlicher Vorgaben) auch über die Gewährleistung der Verfügbarkeit, Integrität und Vertraulichkeit hinausgehen können, um z.B. die Authentizität (zusätzlich nach dem IT-Sicherheitsgesetz), die Nichtabstreitbarkeit von Aktionen (zusätzlich nach Basel II/III) oder die Belastbarkeit (zusätzlich nach der EU-Datenschutzgrundverordnung) nachweisen zu können – hier liefern internationale Standards wie z.B. die ISO/IEC 27001 eine strukturierte Vorgehensweise
3. Bestimmung der zu schützenden Information Assets (darunter sind sowohl Informationen – inkl. personenbezogener Daten – als auch Prozessbeschreibungen – inkl. notwendiger Compliance-Prozesse – zu verstehen) und deren Kritikalität sowie Wertigkeit – dabei ist der Schutzbedarf ausschlaggebend und leiten sich daraus insbesondere datenschutzrechtliche Anforderungen bzw. für kritische Infrastrukturen auch Anforderungen aus dem IT-Sicherheitsgesetz ab
4. Bestimmung der zu schützenden Supporting Assets (wie Hardware, Software, Netzwerkkomponenten, Personal, Gebäude, Räume und organisatorische Strukturen und der jeweiligen Abhängigkeiten der Assets untereinander). Deren Schutzbedarf leitet sich aus den Primary Assets ab, die durch diese Supporting Assets unterstützt werden.

Aktivitäten in der Do-Phase:

1. Anwendung der festgelegten Sicherheitsziele auf die Gestaltung und Verwendung der Information Assets – dies erfordert eine umfangreiche Modellierung und geschieht zweckmäßigerweise unter Beachtung internationaler Standards
2. Zusammentragung relevanter organisatorischer Anweisungen und deren (i.d.R. checklistenartige) Abbildung im Rahmen des einzusetzenden IT GRC Tools – ein entsprechender Transfer papierner Regeln und technischer Parametereinstellungen in entsprechende Tools erfordert i.d.R. nicht unerhebliche Anpassungsarbeiten
3. Zusammentragung technischer Basisdaten (möglichst automatisiert!) ins IT GRC Tool – dabei ist darauf zu achten, dass die eingesetzten Tools erst mal eine einheitliche "Sprache" sprechen müssen, um überhaupt vergleichbare Ergebnisse liefern zu können.

Aktivitäten in der Check-Phase:

1. Durchführung ergänzender Audits und automatisierter Tests. Um die Wirksamkeit der umgesetzten Maßnahmen innerhalb des IT GRC Tools bewerten zu können, sind ergänzende, i.d.R. semi-automatisierbare Prüfungen durchzuführen. Deren Ergebnisse sind ins IT GRC Tool einzuspeisen. Zusammen mit den automatisierten Prüfungen (durch Abgleich technischer Basisdaten mit Vorgaben aus dem umzusetzenden Regelwerk) dient dies als Beleg für die Wirksamkeit des verwendeten Rahmenwerks und damit der Haftungsentlastung.
2. Bewertung der Ergebnisse unter Zuhilfenahme bereitgestellter Metriken (Key Risk / Goal / Performance Indicators) des IT GRC Tools – unter dem besonderen Fokus auf eine ganzheitliche Sicht. Hierbei wird insbesondere dargestellt, welchen Einfluss die aktuelle Ist-Lage auf die Primary Assets hat.

Aktivitäten in der Act-Phase:

1. Report der Bewertung, Behebung festgestellter Mängel und Monitoring der Langzeitentwicklung – die eingesetzte Infrastruktur sollte hierzu möglichst zeitnahe Berichte "auf Knopfdruck" liefern. Diese müssen sowohl managementtauglich sein (Überblick zur Steuerung) als auch dem technischen Personal eine klaren Hinweis zur Mängelbeseitigung bzw. Administration liefern.
2. Anpassung der bestehenden IT GRC Infrastruktur und ggf. geeignete Modifikation von deren Konfiguration – im Rahmen der kontinuierlichen Fortentwicklung

Bernhard C. Witt
Dipl.-Inf., Senior Consultant für Datenschutz und Informationssicherheit
bcwitt@it-sec.de