Datenschutz : Produzieren Sie sichere HR-Software?
27.000 neue Schwachstellen in Softwareprodukten jeglicher Art hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) vom 01.06.2022 bis zum 30.06.2023 gezählt.1 Schwachstellen bedeuten, dass in den betroffenen Produkten der Schutz vor Angriffen umgangen werden kann. Hersteller sind aufgefordert, neue fehlerbereinigte Versionen bereitzustellen und Anwender sollten diese schnellstmöglich installieren. Soweit so alltäglich.
Die Entwicklung einer fehlerfreien Software ist – außer bei trivialer Software – nicht möglich. Auf der anderen Seite kann eine Schwachstelle bedeuten, dass personenbezogene Daten von Unbefugten ausgelesen oder zerstört werden. In der Folge können Unternehmen und Menschen konkrete Schäden erleiden. Das gilt insbesondere auch für HR-Software. (1)
Das Datenschutzrecht regelt nicht das Inverkehrbringen von Softwareprodukten, sodass die Herstellung und der Verkauf von Software mit Schwachstellen keinen Datenschutzverstoß darstellen. Die Nutzung einer solchen Software zur Verarbeitung personenbezogener Daten unterliegt wiederum dem Datenschutzrecht. Hier ist insbesondere an die Artikel 25 (2) und 32 (3) Datenschutz-Grundverordnung
(DS-GVO) zu denken. Hersteller, die ihre Software als Software-as-a-Service anbieten, sind über Artikel 32 DS-GVO zu einem risikoangemessenen Design und einer risikoangemessenen Implementierung der Software verpflichtet.
Schwachstellen gehen regelmäßig auf menschliche Design- oder Implementierungsfehler zurück. Sie sind also nicht naturgegeben oder unvermeidbar. Zur Vermeidung tragen sowohl ein auf Sicherheit ausgerichteter Entwicklungsprozess wie auch eine auf sichere Softwareentwicklung ausgerichtete Weiterbildung der Softwareentwickler bei.
Softwareentwicklungsprozess und Sicherheit
Aus Sicht von Anwendern ist der Funktionsumfang einer Software ein wesentliches – wenn nicht das entscheidende – Kaufargument. Deshalb liegt es wirtschaftlich nahe, sich in der Softwareentwicklung auf die Funktionalität zu konzentrieren. Sicherheit ist keine Funktion. Die Sicherheit einer Software lässt sich kaum beschreiben oder vom Nutzer feststellen. Im Grunde entsteht Sicherheit durch das Zusammenspiel verschiedener Softwarefunktionen, die Art und Weise der Programmierung und das Design der Software.
Das BSI beschreibt in seinem Grundschutzbaustein CON.8 Software- Entwicklung (4) grundlegende Anforderungen an einen auf sichere Software ausgerichteten Softwareentwicklungsprozess. Ein Teil der Anforderungen deckt etablierte Themen ab, wie z. B. die Auswahl einer geeigneten Entwicklungsumgebung, die Dokumentation der Software, Patch-Management und Testen.
Die Anforderungen CON.8.A21 und CON.8.A22 zeigen einen Perspektivenwechsel auf. Neben der Frage, welche Funktionen die Software haben soll, tritt die Frage, welchen Bedrohungen die Software während des Betriebs ausgesetzt ist. CON.8.A21 verlangt, erwartete Bedrohungen zu identifizieren und diese hinsichtlich ihrer Eintrittswahrscheinlichkeiten und Auswirkungen zu bewerten. Eine Software, die aus dem Internet erreichbar ist, ist anderen Bedrohungen ausgesetzt als eine Software, die auf einem isolierten PC betrieben wird.
Das Ergebnis von CON.8.A21 fließt in das Design und die Architektur der Software ein (CON.8.A22). Konkret sollen ein Design und eine Architektur gewählt werden, die die Eintrittswahrscheinlichkeit der identifizierten Bedrohungen reduzieren oder die Auswirkungen begrenzen. Wie wichtig das Design für die Sicherheit ist, sieht man daran, dass ein unsicheres Design auf Platz 4 der 10 bedeutendsten Sicherheitsrisiken steht. (5) Weist ein Design Schwachstellen auf, lassen sich diese später kaum oder nur mit hohem Aufwand schließen.
Weitere Anforderungen konkretisieren den sicherheitsorientierten Entwicklungsprozess weiter. So beschreibt die Anforderung CON.8.A5, welche Grundregeln bei einem Systemdesign und letztlich auch bei der Implementierung beachtet werden müssen. Zu den Grundregeln gehört beispielsweise, dass grundsätzlich alle Eingabedaten vor der Weiterverarbeitung zu prüfen und zu validieren sind.
Das klingt einfach und selbstverständlich. Die Herausforderung liegt in der Umsetzung, d. h. dass jeder Entwickler wirklich bei jeder Eingabe durch den Nutzer und bei jeder Datenübernahme aus Schnittstellen die Eingabedaten vollständig prüft und validiert. Ein Vergessen führt zu einer Schwachstelle in der Software.
Ein Mittel, um vergessene Prüfungen oder andere Abweichungen von den Grundregeln zu finden, sind Softwaretests. Diese sollten sich nicht nur auf die Funktionalität konzentrieren, sondern auch Sicherheitsaspekte wie z. B. die Einhaltung der Grundregeln abdecken. Die Anforderung CON.8.A7 beschreibt die entsprechenden Vorgaben.
Um Zeit und Arbeit zu sparen sowie Fehler zu vermeiden, werden Softwareteile (Bibliotheken) von Drittanbietern, wozu auch Open Source zählt, in die eigenen Produkte eingebunden. Diese Bibliotheken bringen ihre eigenen Schwachstellen mit, die die Sicherheit der eigenen Software reduzieren.
Das Sicherheitsunternehmen Veracode stellte in einer Untersuchung fest, dass mehr als die Hälfte der untersuchten Bibliotheken von weniger als zehn Personen betreut werden oder seit mehr als einem Jahr nicht aktualisiert wurden. Viele Bibliotheken werden ehrenamtlich entwickelt, d. h. es besteht kein Rechtsanspruch auf eine Fehlerbehebung.
Der Fall „xz-Hintertür“ zeigt das Risiko exemplarisch auf. (6) SSH ist ein weitverbreitetes Programm für Fernzugriffe auf Server. Es gehört zu den grundlegenden Werkzeugen für den IT-Betrieb. Dieses Programm ist auf Sicherheit optimiert. Es nutzt u. a. eine Bibliothek zur Datenkompression. Diese Bibliothek wird von einem Menschen als Hobby entwickelt, der unter einem Burn-out leidet. Ein freundlicher Mensch bot seine Hilfe an. Zwei Jahre unterstützte der Helfer den Entwickler, bis dieser ihm so weit vertraute, dass er ihm erlaubte, neue Programmversionen zu erstellen. Diese Chance nutzte der Helfer, um Schadcode einzubauen. Wäre dieser nicht zufällig zeitnah entdeckt worden, hätte der Helfer vermutlich Zugriff auf 20 Millionen Server weltweit erhalten.
Weiterbildung ist Trumpf
Das Aufsetzen eines sicherheitsorientierten Entwicklungsprozesses verlangt entsprechend qualifiziertes Personal. Den Entwicklungsprozess zu etablieren, ist ein erster Schritt. Ein Softwareentwicklungsprozess
ersetzt nicht das Know-how von Softwareentwicklern. Der Prozess definiert Standards, Verantwortlichkeiten und Abläufe. Die Umsetzung im Programmcode obliegt den Softwareentwicklern. Da Softwareentwicklung eine kreative Leistung wie das Schreiben von Romanen ist, hat ein Entwickler einen großen Gestaltungsspielraum, um die gestellte Aufgabe umzusetzen. Er kann den Gestaltungsspielraum für eine sichere oder unsichere Lösung nutzen.
Fortbildungen sind zentral, um Entwickler für sichere Lösungen zu sensibilisieren und ihnen gleichzeitig das Rüstzeug zum Schreiben von sicheren Lösungen an die Hand zu geben. Um das Sicherheitsniveau der eigenen Software schnell zu heben, bietet sich eine Orientierung an den häufigsten Fehlern an.
Die OWASP Foundation pflegt eine Liste der zehn weltweit kritischsten Sicherheitsrisiken für Web Anwendungen, die sogenannte OWASP Top Ten. (7) Diese Liste bietet sich als Orientierung zur Auswahl von Schulungsinhalten an.
Fazit
Hersteller, die ihre Produkte als Software-as-a-Service anbieten, sind nach Art. 32 Abs. 1 DS-GVO verpflichtet, ihre Produkte entlang des Stands der Technik unter Berücksichtigung der Kosten und der Risiken für die betroffenen Personen auszugestalten. Das BSI zeigt in seinem Grundschutzbaustein CON.8 Software-Entwicklung auf, wie ein sicherheitsorientierter Entwicklungsprozess ausgestaltet werden sollte. Der Qualifikation der Entwickler kommt dabei eine besondere Bedeutung zu; nicht nur, um den Prozess aufzusetzen, sondern insbesondere auch in der täglichen Arbeit. Regelmäßige Fortbildungen über sichere Softwareentwicklung bleiben unverzichtbar.
Literatur
(1) BSI (2024): Die Lage der IT-Sicherheit in Deutschland 2023, URL: www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Lageberichte/Lagebericht2023.pdf?__blob=publicationFile&v=8
(2) Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen
(3) Sicherheit der Verarbeitung
(5) OWASP Foundation: OWASP Top Ten, URL: https://owasp.org/www-project-top-ten/
(6) Ausführlich geschildert in Heise (2024): Die xz-Hintertür: Das verborgene Oster-Drama der IT, 02.04.2024, URL: heise.de/-9673038
(7) OWASP: OWASP Top Ten, URL: https://owasp.org/www-project-top-ten/