DSGVO nimmt professionelle Anwender in Haftungspflicht Qualitätssicherung und Gütesiegel für Software

Autor / Redakteur: Joachim Jakobs / Stephan Augsten

Die Qualität von Software sinkt – und zwar mit atemberaubender Geschwindigkeit. Diese Aussage gründet dabei nicht auf dem subjektiven Empfinden eines vermeintlich böswilligen Autors, sondern ist Ergebnis amtlicher Statistik.

Anbieter zum Thema

Die Qualität einer Software lässt sich anhand verschiedener Kriterien bemessen und dürfte angesichts der DSGVO künftig eine größere Rolle spielen.
Die Qualität einer Software lässt sich anhand verschiedener Kriterien bemessen und dürfte angesichts der DSGVO künftig eine größere Rolle spielen.
(Bild gemeinfrei: Tero Vesalainen - Pixabay.com)

Die Statistik lügt nicht: Das National Institute of Standards and Technology (NIST) – eine Behörde des US-Handelsministeriums – sammelt Schwachstellen. Die daraus entstandene Datenbank reicht bis ins Jahr 1997 zurück und ist über die NIST-Webseite öffentlich zugänglich.

Die Lücken werden aber nicht einfach nur gesammelt, sondern zusätzlich bewertet. Hier in aller Kürze die Kriterien:

  • 1. Die ‚Severity Score Range‘ beschäftigt sich mit der „Kritikalität“ einer Lücke – besteht beim Ausnutzen der Lücke Lebensgefahr oder ist „nur“ die Privatsphäre der Betroffenen bedroht?
  • 2. Beim ‚Attack Vector (AV)‘ geht es um die Frage, wie die Lücke ausgenutzt werden kann – etwa übers Netz oder nur „vor Ort“?
  • 3. Die ‚Attack Complexity (AC)‘ beschreibt das notwendige Wissen, um die Lücke ausnutzen zu können: Muss der Angreifer nur irgendwelche Knöpfe in irgendeinem Baukasten drücken, den er zuvor irgendwo im Dunklen Netz gefunden hat? Oder muss er zunächst eigene, aufwendige Untersuchungen anstellen?
  • 4. Über welche ‚Rechte‘ muss der Angreifer im System verfügen, um erfolgreich zu sein?
  • 5. Ist für den Angriff eine Interaktion notwendig? Oder kann der Angriff ausschließlich automatisiert durchgeführt werden?

Im Jahr 2017 gab es 1927 kritische Lücken – das sind jene Verwundbarkeiten, die mit einer Kritikalität von 9 bis 10 bewertet wurden und gleichzeitig eine geringe Angriffskomplexität aufwiesen. Zum Vergleich: 2016 waren es 1049 und noch ein Jahr früher 22 gewesen. Zugegebenermaßen hat sich auch die Zahl der Schwachstellen insgesamt von jeweils rund 6.500 in 2015 und 2016 auf gut 14.600 im Jahr 2017 erhöht. Rückschlüsse auf aufmerksamere Prüfer, bessere Tests oder die Zahl der erfassten Produkte lässt die Datenbank nicht zu.

Wer ist schuld?

Nicht selten werden bei der Suche nach einem Schuldigen die Entwickler genannt. „150 Milliarden Euro Schaden wegen schlechter Software-Qualität in Europa ... pro Jahr!“, „Schlechter Code macht Banken unsicher“ oder „Schwache Softwareentwicklung größtes Cyberrisiko“. So lauten die Vorwürfe von Qualitätsprüfern und Medien.

Gordon Mühl, früher Chief Technical Officer (CTO) für Security bei SAP erläuterte 2015 dazu: „In der Regel müssen Entwickler termingerecht liefern. Diese Situation bringt einen Entwickler in die Bredouille: „Implementiere ich noch das Security Feature oder bin ich fertig?“ Schon vor acht Jahren sollen 60 Prozent der Apps bei Softwaretests durchgefallen sein.

In Wirklichkeit ist es für die Entwickler selbst ein Graus, schlechten Code zu veröffentlichen bzw. veröffentlichen zu müssen: „Apples Software Qualität geht permanent zurück – insbesondere in den letzten zwei Jahren“, schrieb ein Nutzer namens osmenda im Apple Developer Forum im Dezember 2017. 20.000 Leser dieses Blogbeitrags und 65 Leserzuschriften später hieß es im Februar 2018, dass Apple die Veröffentlichung neuer Funktionen verzögere, um den Entwicklern mehr Zeit zu geben.

Software-Qualität ist kein Kraufkriterium – bisher

Die Sicherheit ist für das Consortium for IT Software Quality (CISQ) ein Qualitätsmerkmal von Software – neben Zuverlässigkeit, Effizienz und Wartbarkeit. Die Bedienbarkeit oder Usability jedenfalls ist nicht enthalten. Sie gehört aber zu den wichtigsten Kriterien der Käufer von Enterprise-Ressource-Planning-Software; vor fünf Jahren waren einer Studie zufolge die Kaufkriterien von ERP-Erstkäufern:

  • 1. Preis der Software
  • 2. Implementierungsfreundlichkeit
  • 3. Anwenderfreundlichkeit
  • 4. Funktionalität
  • 5. Anpassungsfähigkeit ans Unternehmen
  • 6. Kompatibilität mit vorhandener Hardware
  • 7. Wachstumspotential
  • 8. Unterstützung durch den Anbieter
  • 9. Qualität der Dokumentation
  • 10. Erfolgsbilanz der Leistung des Entwicklers

Das CISQ und die Unternehmenskunden haben offenbar völlig unterschiedliche Vorstellungen von „Qualität“. Bis 2017 hat sich daran nichts geändert – da hat sich die Narses Beratungsgesellschaft in Bad Vilbel mit den Prioritäten der Kunden im Verlagsgewerbe beschäftigt. Das für die Kunden vernichtende Ergebnis: 74 Prozent der Teilnehmer halten die Bedienbarkeit für „sehr wichtig“, 26 Prozent haben mit „wichtig“ geantwortet. Erst auf Platz 4 ist die Geschwindigkeit des Löcherstopfens gelandet.

Die DSGVO stellt alles auf den Kopf

Jetzt haben wir 2018 und ab Mai gilt die Datenschutzgrundverordnung. Die Nutzer müssen ihre Prioritäten regelrecht auf den Kopf stellen: Verantwortlich im Sinne der DSGVO ist nämlich nicht der Entwickler der Software, sondern der, der personenbezogene Daten mit dieser Software verarbeitet.

Die Bundesbeauftragte für den Datenschutz (BfDI) formuliert die Rechtsfolge so: „Den Nachweis (d. Einhaltens der DSGVO, Anm. d. Autors) führen muss allerdings derjenige, der für die Datenverarbeitung verantwortlich ist. In der Regel ist das nicht der Hersteller einer proprietären Software, sondern (gewerbliche) Nutzer dieser […] In jedem Fall muss der Verantwortliche die genannte Dokumentation und damit den datenschutzrechtlichen Nachweis auch für alle Datenverarbeitungsvorgänge mittels der proprietären Software vorhalten […] Der für die Datenverarbeitung Verantwortliche muss beim Einsatz proprietärer Software also dafür sorgen, dass er vom Software-Hersteller diese Informationen erhält.“

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Softwareentwicklung und DevOps

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Qualitätssicherung für Software

Der Deutsche Städte- und Gemeindebund behauptet: „Bei der Beschaffung und dem Einsatz von Software sind Städte und Gemeinden bestrebt, nur zertifizierte Produkte mit höchsten Standards einzusetzen. Dies trifft insbesondere auf Software, die zur Verarbeitung von Daten eingesetzt wird zu.“

Potenzieller Kaufanreiz ist eine Qualitätssicherung, auch „Software Quality Assurance“ genannt. In einem mehrwöchigen Kurs an der École de technologie supérieure (ÉTS) in Kanada können Sie erlernen, was es damit auf sich hat: 13 dreistündige Vorlesungen über „Qualitätsvoraussetzungen“, „Software Überprüfungen“ und das „Risikomanagement“ werden durch praktische Übungen zur Qualitätssicherung im Labor ergänzt.

Wichtig sind für die Hochschule Normen – etwa die ISO/IEC/IEEE 15289, ein Standard zur Beschreibung von Software oder die ISO/IEC 25000. Entwickler können ihre Qualitätsprüfung jedoch auch extern vergeben – beispielsweise an das Bundesamt für Sicherheit in der Informationstechnik (BSI).

Gütesiegel für Software

Qualitätskriterien für Software in der Übersicht.
Qualitätskriterien für Software in der Übersicht.
(Bild: Sabine Radomski, Hochschule für Telekommunikation Leipzig)

Was aber macht ein Unternehmer, dessen Software übers Internet oder über Ladengeschäfte verkauft wird, um seine Interessenten von der Qualität seiner Software zu überzeugen? An einem Gütesiegel für geprüfte Sicherheit arbeitet Sabine Radomski, Professorin für Verteilte Systeme und Software-Engineering an der Hochschule für Telekommunikation Leipzig (HfTL) zusammen mit Aleksandra Sowa von der Gesellschaft für Informatik (GI).

In dem Wort Gütesiegel steckt Zweierlei: „Güte“ und „Siegel“: Die Qualität der Anwendung soll zunächst darauf geprüft werden, ob sie ausreichend „gut“ ist, also den Kriterien des Gütesiegels entspricht. Die Kriterien, nach denen geprüft wird, saugt sich Radomski dabei nicht aus den Fingern, sie stützt sich vielmehr auf die ISO 25000. Zu diesen Kriterien gehören:

  • 1. die Functional Suitability – sie bescheinigt, dass die Software tatsächlich das – korrekt und angemessen – tut, was die Entwickler in der Dokumentation behaupten.
  • 2. die Performance Efficiency – sie bestätigt, dass die tatsächliche Leistung und Geschwindigkeit sowie die Systembelastung der Anwendung mit den Behauptungen der Dokumentation übereinstimmt.
  • 3. die Compatibility prüft den Grad an Interaktionsfähigkeit der Anwendung mit anderen Produkten, Systemen oder Komponenten der Hardware auf der die Anwendung installiert ist.
  • 4. die Usability beschäftigt sich mit der Frage ob bestimmte Anwender in der Lage sind, bestimmte Ziele effektiv, effizient und zufriedenstellend in einem spezifizierten Anwendungszusammenhang zu erreichen.
  • 5. die Reliability spiegelt den Grad, mit dem spezifizierte Funktionen unter bestimmten Bedingungen in einem bestimmten Zeitraum zuverlässig ausgeführt werden. Neben der Zuverlässigkeit spielen hier auch die Systemverfügbarkeit, die Fehlertoleranz und die Wiederherstellbarkeit (nach einem etwaigen Systemabsturz) eine Rolle.
  • 6. die Security – sie garantiert den rollenspezifischen Zugang der Berechtigten zu Informationen und Daten – und schließt den Zugang Unberechtigter aus. Weitere Forderungen nach Vertraulichkeit, Integrität, Nachweisbarkeit, Rechenschaftspflicht und Authentizität präzisieren dieses Kriterium.
  • 7. die Maintainability – sie stellt sicher, dass die Anwendung effektiv und effizient „gewartet“ werden kann: Fehler müssen behoben, Funktionen verändert und neue Funktionen hinzugefügt werden können ohne Fehler zu verursachen. Dazu ist ein modularer Aufbau wiederverwendbarer Komponenten notwendig. Die Konsequenzen der Veränderungen für das Gesamtverhalten sollen einschätzbar sein. Testkriterien sollen zur Verfügung gestellt werden, um damit zu prüfen, ob diese Kriterien erfüllt werden.
  • 8. die Portability – sie zeigt, wie effektiv und effizient Systeme, Produkte oder Komponenten von einer Umgebung in eine andere transferiert werden können. Dabei spielen die Anpassungsfähigkeit, die Installierbarkeit und die Ersetzbarkeit eine Rolle.

Nach der Prüfung der „Güte“ kommt das Siegel obendrauf: Dafür wird für die zu prüfende Software eine Prüfsumme – ein sogenannter Hashwert errechnet und in die geprüfte Software integriert – Radomski erläutert: „Eine Veränderung der Software nach der Versiegelung ist nur mit hohem Aufwand möglich.“

Im Handel soll das Siegel „auch auf der Verpackung sichtbar sein und es kann bzw. soll auch eine Liste der zertifizierten Software im Netz geben, um den Kunden die Auswahl zu vereinfachen“, schreibt die Professorin. Eine Verletzung des Siegels werde beim Installieren sichtbar – dort werde der Hashwert geprüft und eine Fehlermeldung ausgespuckt, wenn er nicht stimmt.

Anspruch und Wirklichkeit

Kurzfristig ist das jedoch keine Lösung: Die Abstimmung mit Partnern wie dem Bundesamt für Sicherheit in der Informationstechnik (BSI), dem Bitkom und der Telekom, die Entwicklung entsprechend widerstandsfähiger Algorithmen und die Einführung im Markt soll noch Jahre dauern.

Da die mutmaßlichen Großkoalitionäre nicht nur vereinbart haben „die kreativen Potenziale in Deutschland mobilisieren und die Chancen der Digitalisierung nutzen“ sondern auch „ein europaweit gültiges IT-Sicherheits-Gütesiegel etablieren“ wollen, besteht die Hoffnung, dass Radomski den erforderlichen Rückenwind für ihre Arbeit erhält.

Damit sind die guten Absichten der Parteien aber noch nicht erschöpft; die Großkoalitionäre wollen „das Produkthaftungsrecht anpassen, Mindeststandards vorschreiben und die Einführung einer gewährleistungsähnlichen Herstellerhaftung prüfen“. Die nach DSGVO Verantwortlichen werden ihnen dankbar dafür sein.

Was aber können Sie als professionell Verantwortlicher jetzt tun, wenn sie von den Entwicklern proprietärer Software nicht die Unterstützung erhalten, die sie benötigen, um ihrer Rechenschaftspflicht zu genügen? Sie können jegliche Verarbeitung personenbezogener Daten in die Cloud verschieben; dann haftet der Auftragsverarbeiter wenigstens mit.

Eine andere Möglichkeit ist mit dem Begriff der erwähnten „proprietären Software“ verknüpft, die oben genannt wurde. Der Gegensatz dazu heißt „Freie Software“ – also Software, die Ihnen per Lizenz die Freiheit lässt, die Software nach Gutdünken zu nutzen. Anhand des Quellcodes ließe sich dann zumindest prinzipiell zumindest eine DSGVO-feste Dokumentation erstellen.

(ID:45178459)