Open-Source-Sicherheit und die EU-DSGVO Sicherheitslücken gehören geschlossen
20. September 2017
Betrachtet man die EU-DSGVO aus der Perspektive der Anwendungssicherheit, spielt der Artikel 32 „Sicherheit der Verarbeitung“ eine ausschlaggebende Rolle. Dieser besagt, dass beide – sowohl der derjenige der die personenbezogenen Daten hält als auch derjenige der diese verarbeitet „geeignete technische und organisatorische Maßnahmen“ treffen müssen, „um ein dem Risiko angemessenes Schutzniveau zu gewährleisten“. Hier kann der Faktor Open Source eine wichtige Rolle spielen, denn bekannte Lücken müssen unbedingt gestopft werden.
Gültigkeitsbereich
Die vom Europäischen Parlament verabschiedete EU-Datenschutzgrundverordnung (EU-DSGVO) verfügt, dass alle Unternehmen, die personenbezogene Daten europäischer Bürger verarbeiten und vorhalten, diese Informationen schützen und den Schutz der Daten nachweisen müssen. „Personenbezogene Daten“ können sowohl ein Name, ein Foto, eine E-Mail-Adresse oder auch Kontodaten, aber auch Posts in sozialen Netzwerken, medizinische Informationen und die IP-Adresse des Computers sein.
Die Neuregelung gilt für jede Organisation, die persönliche Informationen eines EU-Bürgers speichert oder verarbeitet, und zwar unabhängig davon, wo diese ihren Sitz hat oder wo die Daten verarbeitet werden. So müssen sämtliche Unternehmen, die europäische Daten verarbeiten, vorhalten oder besitzen, die gesetzlichen Bestimmungen einhalten – dies gilt auch für diejenigen aus den USA oder Großbritannien – trotz Brexit.
Sobald die Verordnung anwendbar wird, drohen empfindliche Strafen bei Nichteinhaltung. Bei Verstößen gegen die EU-DSGVO können Unternehmen mit Geldbußen in Höhe von bis zu 4 Prozent ihres jährlichen weltweiten Umsatzes oder bis zu 20 Millionen Euro belegt werden, je nachdem welcher Wert höher ist.
Betrachtet man die EU-DSGVO aus der Perspektive der Anwendungssicherheit, spielt der Artikel 32 „Sicherheit der Verarbeitung“ eine ausschlaggebende Rolle. Dieser besagt, dass beide – sowohl der derjenige der die personenbezogenen Daten hält als auch derjenige der diese verarbeitet „geeignete technische und organisatorische Maßnahmen“ treffen müssen, „um ein dem Risiko angemessenes Schutzniveau zu gewährleisten“. Dazu gehört auch, Verfahren zur regelmäßigen Bewertung und Prüfung ihrer Sicherheitspraktiken zu etablieren.
Standards
Ähnlich wie die PCI-Standards, die für Kreditkarten gelten, und die US-Bestimmungen, die im Gesundheits- und Kernenergie-Sektor Anwendung finden, verpflichtet die EU-DSGVO Organisationen dazu, sich der IT-Sicherheits-Schwachstellen bewusst zu sein und einen Plan auszuarbeiten, um diese anzugehen. Anders gesagt, sie sollten eine Risikobewertung durchführen, um die Bereiche zu identifizieren, in denen persönliche Daten öffentlich werden könnten und einen prüffähigen Prozess dokumentieren, um mit diesem Risiko fertig zu werden – sprich, einen Risiko-Management-Plan entwickeln.
Die allgemeinen Anforderungen der EU-DSGVO sind vergleichbar. Es geht um Konzepte zur Verhinderung, Beurteilung und Überprüfung; einschließlich einer Schwachstellen-Analyse, bei der die aktuellen Sicherheitsprozesse begutachtet werden, um festzustellen, wo Änderungsbedarf besteht, um den neuen Anforderungen gerecht zu werden. Kurz um: Risiko-Bewertung und Risiko-Management.
Bisher sahen Unternehmen die Vorgaben hinsichtlich Software-Updates üblicherweise nur dann als verpflichtend, wenn sie vom Anbieter darauf hingewiesen wurden, dass eine Schwachstelle besteht und ein Patch verfügbar ist. Obwohl dies zutrifft, erstreckt sich diese Verpflichtung nicht nur auf kommerzielle Software, die im Unternehmen läuft. Die Regelungen gelten auch für Individual-Software, also Anwendungen, die intern oder extern für das Unternehmen entwickelt wurden. Dies wird viele Organisationen vor eine Herausforderung stellen.
Die steigende Übernahme von Open-Source-Code in Applikationen, die von Unternehmen entwickelt werden, hat es erschwert, in Bezug auf die entstehenden Sicherheitsrisiken up-to-date zu bleiben. In der Open-Source-Community gibt kein System, das Unternehmen alarmiert, wenn Schwachstelle proaktiv zu beobachten, ob es Updates zu Schwachstellen gibt und die veröffentlichten Patches einzuspielen. Dies ist ein wesentlicher Bestandteil des Risikobewertungs- und -management-Programms eines Unternehmens, das sich bemüht, die EU-DSGVO sowie HIPAA, PCI, NERC-CIP oder andere regulatorische Standards zu erfüllen.
„Sicherheit, die dem Risiko angemessen ist“ gilt dabei als der Schlüsselsatz. Viele Organisationen schenken den zusätzlichen Sicherheitslücken, die durch anfällige Open-Source-Komponenten entstehen, nicht ausreichend Beachtung – und sind sich möglicherweise nicht einmal der Existenz dieser Gefahr bewusst. Doch heutzutage ist Open Source zentraler Bestandteil in der Software-Entwicklung und der Einsatz von Open Source zieht sich durch sämtliche Branchen. Von den über 1000 Applikationen, die in der jüngsten Open Source Security and Risk Analysis (OSSRA) von Black Duck untersucht wurden, beinhalteten 96 Prozent Open Source, wobei nahezu 70 Prozent dieser Anwendungen Schwachstellen in den verwendeten Open-Source-Komponenten hatten.
Open SSL, Heartbleed und EU-DSGVO
OpenSSL zählte zu den verbreitetsten hochriskanten Komponenten, die in der Analyse von Black Duck gefunden wurden. Als Open-Source-Projekt und Bestandteil hunderttausender Applikationen, die zur Sicherung der Kommunikation über Computernetzwerke benötigt werden, findet OpenSSL weite Verbreitung in vielen Industriezweigen. Über 66 Prozent der Webseiten nutzen OpenSSL, genauso wie tausende E-Mail-Server von Unternehmen (SMTP, POP und IMAP), Chat Server (XMPP Protokoll), Virtual Private Networks (SSL VPNs), Netzwerkanwendungen und eine Vielzahl Client-seitiger Software.
Anfang des Jahres 2017 waren immer noch über 200.000 Systeme anfällig für Heartbleed, einer kritischen Sicherheitslücke von OpenSSL, die vermeintlich sichere Kommunikation offenlegen kann. Sogar heute noch integrieren viele Firmen OpenSSL-Versionen, die die kritische Heartbleed-Schwachstelle enthalten – und das Jahre nachdem die Sicherheitslücke bekannt gemacht wurde und OpenSSL-Versionen mit entsprechenden Sicherheits-Patches verfügbar sind. Lediglich hinsichtlich Heartbleed nachzubessern, reicht jedoch nicht aus, um das Thema Sicherheit in den Griff zu bekommen. Seit Heartbleed haben Experten über 90 weitere Schwachstellen in OpenSSL gemeldet. Die kontinuierliche Beobachtung neuer Risiken muss zum Bestandteil jedes Risikobewertungsprogramms werden.
Würde ein Versäumnis, Sicherheitsvorkehrungen gegen eine vor Jahren offengelegte und breit publizierten Schwachstelle zu treffen, einer Verletzung der Anforderung für angemessene Sicherheit gleichkommen, wenn durch einen Angriff, der diese Schwachstelle ausnutzt, personenbezogene Daten gestohlen würden? Anfang Juni dieses Jahres verhängte das UK Information Commissioner’s Office (ICO) eine Geldstrafe in Höhe von 100.000 Pfund gegen eine öffentlichen Stelle, weil diese es versäumt hatte, eine Sicherheitslücke ihrer Webseite zu schließen, die im Zusammenhang mit ihrer Nutzung von Open-Source-Software stand. Die Schwachstelle? Heartbleed in OpenSSL. Über diese Schwachstelle konnte ein Hacker auf sensible personenbezogene Daten von 30 bis 40 ehemaligen und derzeitigen Mitarbeitern dieser Stelle zugreifen.
Würde Unwissenheit hinsichtlich der Schwachstelle in der Open-Source-Komponente davor schützen? Im Fall einer wohlbekannten Schwachstelle wie Heartbleed ziemlich sicher nicht. Obwohl IT-Mitarbeiter der öffentlichen Stelle die Notwendigkeit eines Software-Updates sahen, kam der veröffentlichte Patch für die Software nie zur Anwendung. Das Patchen wurde zu einem Zeitpunkt „übersehen“, als diese Stelle gerade dabei war, ihre IT an einen Drittanbieter auszulagern; ein 100.000-Pfund-Versäumnis. Wäre die DSGVO bereits anwendbar gewesen, hätte das Bußgeld möglichweise weitaus höher sein können.
Mit der richtigen Herangehensweise und rechtzeitiger Planung können Unternehmen die Notwendigkeit, die Vorgaben der Datenschutzgrundverordnung einzuhalten, als Chance nutzen, um sich zu differenzieren und neue Geschäftsmöglichkeiten zu eröffnen. Darüber hinaus werden viele Unternehmen von ihren Handelspartnern die vollständige Einhaltung der EU-DSGVO als Voraussetzung für künftige Geschäfte sehen. Diese Anforderungen werden typischerweise Bestandteil des Ausschreibungsprozesses und/oder Datenschutz– und Sicherheits-Audits sein. Die Nichteinhaltung könnte zu signifikanten Geschäftseinbußen führen im Vergleich zu Wettbewerbern, die EU-DSGVO-Compliance nachweisen können.
Will ein Unternehmen die Datenschutzgrundverordnung einhalten, muss das genutzte Software-Ökosystem überprüft sowie Open-Source-Identifizierung und -Management in sein EU-DSGVO-Sicherheitsprogramm integrieren werden. Außerdem muss individuell angepasster Quellcode auf Schwachstellen untersucht und sicherstellt werden, dass die eigene oder von Handelspartnern verwendeten Open-Source-Elemente keine versteckten Sicherheitsschwachstellen einschleppen.
Mike Pittenger
ist Vice President Security Strategy bei Black Duck Software.
