„Beauty is our business“ : Software-Metriken als Grundlage für Gütesiegel zu Sicherheit und Qualität

Von Aleksandra Sowa, Bonn

Die vierthäufigste Ursache für Datensicherheitsvorfälle in Unternehmen sind einer Studie von Kapersky Lab zufolge Fehler in Software [1]. Dabei sind Sicherheitsvorfälle, die durch Software- und Programmierfehler verursacht werden, zwar sehr häufig, doch zugleich auch diejenigen mit den niedrigsten monetären Auswirkungen. Möglicherweise ist das einer der Gründe für das geringe Interesse vieler Anbieter, sichere und qualitativ hochwertige Software zu produzieren?

Doch spätestens die Denial-of-Service-(DoS)-Attacken auf Internet-of-Things-(IoT)-Geräte und darauf folgenden Internetausfälle in den USA und in Deutschland sowie Angriffe auf kritische Infrastrukturen (bspw. mit Stuxnet) haben gezeigt, dass Sicherheitsvorfälle nicht nur unmittelbare monetäre Folgen für die direkt betroffene Organisation, sondern zunehmend auch ernsthafte gesellschaftliche Folgen haben können.

Schlecht programmierte Software, Bugs in Anwendungsprogrammen und Betriebssystemen, also letztlich die über Jahre dem Diktat der Kosteneinsparungen und Auslagerungen unterworfene Qualität von Software- und Hardware gehören zu den von Wirtschaft wie Wissenschaft gleichermaßen vernachlässigten Risiken.

Lange Zeit dominierte die Sichtweise: Wenn ein Computer ab und zu aufgrund von Programmierfehlern abstürzt, dann kostet es höchstens Zeit, um ihn neu zu starten, eventuell geht noch ein wenig Arbeit dadurch verloren. Ob formale Verifikation oder formales Beweisen von Softwarefunktionen und -qualität: Es handelte sich nach Auffassung vieler Experten um die Suche nach einer arbeitsintensiven Lösung für nichtexistierende Probleme.

Dann kam die allgegenwärtige Vernetzung mit dem Internet und bedeutete für Softwarefehler das, was die alltägliche Flugtouristik zur Verbreitung infektiöser Krankheiten beitrug: Ein zuvor tolerierbarer Fehler konnte nun zu einer Kaskade von Sicherheitsvorfällen und Problemen führen – oder zu einem flächendeckenden Netzausfall. Mit Internet, Digitalisierung, IoT und „Industrie 4.0“ ist jeder Fehler in der Software von heute eine potenzielle Schwachstelle von morgen, durch die Angreifer in Systeme eindringen können.

Umdenken erforderlich

So erheben sich mittlerweile aus Politik und Fachwelt (u. a. aus dem Chaos Computer Club und der Gesellschaft für Informatik) Stimmen, die eine nachweislich bessere Qualität und Sicherheit von Software, IT-Systemen und -Services fordern. Und dabei geht es auch um die Sichtbarkeit dieser Sicherheit für den Nutzer: Egal ob dieser eine juristische oder natürliche Person ist, er sollte die Möglichkeit haben, auf den ersten Blick zu erkennen, was er erwirbt – wiederum unabhängig davon, ob er das nun kauft, leiht, zeitbeschränkt ausprobiert, kostenlos nutzt et cetera.

„Die Anwender sollen künftig auf Basis eines einheitlichen Gütesiegels bei der Kaufentscheidung für neue IT-Produkte bei der Inanspruchnahme entsprechender Dienstleistungen leicht und schnell feststellen können, welches Angebot sicher ausgestaltet ist und hierdurch zum Schutz der Daten beiträgt“, heißt es in der Cyber-Sicherheitsstrategie 2016 [2] des Bundesministeriums des Innern (BMI). Die eingesetzte Software muss – trotz steigender Komplexität und Intransparenz – professionellen Angriffen standhalten.

Gefordert wird ein Softwaregütesiegel, das seine Prüfkriterien transparent und verständlich offenlegt: „Die Bundesregierung wirbt daher insbesondere bei Herstellern von Standardtechnologien für eine erhöhte Testierbereitschaft und wird ein Basis-Zertifizierungsverfahren für sichere IT-Verbraucherprodukte einführen, dessen Kriterien durch das BSI festgelegt werden“, heißt es weiter im Werk des BMI.

Dabei müssen solche Kriterien nicht einmal neu erfunden werden: Vielmehr gibt es längst Standards, Regelwerke und Normen, wie qualitativ hochwertige und sichere Software zu entwickeln ist. Eine sinnvolle und adaptiv anpassbare Zusammensetzung solcher Prüfkriterien ist erstrebenswert – ebenso eine Erweiterung des Gütesiegel-Konzepts über eine bloße A-posteriori-Black-Box-Prüfung durch Penetrationstests hinaus.

Penetrationstests sind eine notwendige, aber eben nicht hinreichende Methode zur Prüfung von Softwarequalität und -sicherheit. Sie bieten unvollkommene Beweise und sind dennoch dort unentbehrlich, wo der Entwicklungsprozess und womöglich der Quellcode selbst im Verborgenen bleiben (vgl. [3]). Sie sollten deswegen um Kriterien für Software-Engineering, allem voran zur Softwarequalität und -sicherheit, sinnvoll ergänzt werden, um verlässliche Aussagen zu gewährleisten, wie man sie beispielsweise zur Erteilung eines Gütesiegels benötigt.

Oder nochmals in den Worten des niederländischen Informatikers der ersten Stunde, Edsger Dijkstra: „Today a usual method is to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence. The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness.“ [4]

Qualität von Anfang an

Softwarequalität sollte nicht erst und nicht nur am fertigen Produkt bewertet werden. Man sollte vielmehr zwischen dem Herstellungsprozess und dem Softwareprodukt differenzieren und beide Aspekte gleichermaßen bei der Prüfung und Bewertung berücksichtigen.

„Die Sache beginnt am Beginn“, betonte auf der „Informatik 2016“ der Gesellschaft für Informatik (https:// gi.de/) Prof. Dr. Heinrich Mayr von der Universität Klagenfurt – und meinte damit die ersten Phasen des Entwicklungsprozesses, besonders auch schon die Pflichtenhefte, die eine Spezifikation für noch zu erstellende Software und Systeme enthalten.

Eine Umsetzung könnte sich an den Vorgaben der Normenfamilie ISO/IEC 9000 oder ISO/IEC 25000 ausrichten. Eine nachweislich dokumentierte Einhaltung der (noch zu systematisierenden) Prozesse von Security- und Privacy-by-Design wäre in diesem Zusammenhang ebenfalls denkbar.

Software-Metriken

Zur Bewertung (und Prüfung) einer Software als fertigen Produkts ist natürlich die Offenlegung des Quellcodes zur Bewertung durch unabhängige Prüfer eine denkbare Option. Als methodischer Ansatz bieten sich in diesem Zusammenhang Software-Metriken an. Metriken beschreiben das Phänomen, zu dessen Bewertung sie eingesetzt werden, vollumfänglich – anders als Key-Performance- (KPIs) oder KeyGoal-Indicators (KGIs). Dies ist der Methodik ihrer Definition geschuldet: dem Goal-Question-Paradigma, GQP (s. Abb. 1).

Software-Metriken haben deshalb im Bereich der Steuerung von Softwareentwicklungsprozessen einen hohen Stellenwert – zunehmend auch als Instrument der Kontrolle und Prüfung. Sie verkörpern die Forderung von Tom DeMarco aus dem Jahr 1982: „Was man nicht messen kann, das kann man nicht kontrollieren.“ [5]

Gemäß IEEE-Standard 1061 wird eine Software-Metrik als eine Funktion definiert, die eine Softwareeinheit in einem Zahlenwert abbildet. Dieser berechnete Wert ist interpretierbar als der Erfüllungsgrad oder als eine Qualitätseigenschaft der Softwareeinheit. Software-Metriken sind Werte und Zahlen, die bestimmten, im GQP-Prozess definierten Eigenschaften der Software zugeordnet werden können – etwa Sicherheit und Qualität im Kontext des angesprochenen Gütesiegels.

Software-Metriken unterscheiden zwischen Prozessmetriken, die sich auf den Entwicklungsprozess beziehen, und Produktmetriken, die Software als Produkt betrachten (vgl. Abb. 2). Die Produktmetriken wiederum unterteilen sich in dynamische – auf Performance bezogene – Metriken, wie Belastungs-, Leistungsfähigkeit, Stabilität oder Zuverlässigkeit – und statische Metriken, die auf das „Werk“ Software bezogen sind, beispielsweise Größen-, Komplexitäts- und Architekturmetriken.

Anwendungsbeispiel

Wie solche Metriken im Kontext eines Security-Gütesiegels sinnvoll eingesetzt werden können, zeigt das Beispiel „technische Schulden“: Durch Steigerung der Produktivität innerhalb der Softwareentwicklung wird die Qualität vernachlässigt (bes. durch Outsourcing, Offshore-Entwicklung, Quick&Dirty Coding, Vernachlässigung von Entwicklungsrichtlinien, Security-Requirements, datenschutzrechtlicher und sicherheitstechnischer Freigaben etc.). So steigen die mittel- und langfristigen Kosten und nicht zuletzt die Entwicklungszeit, da oft (zumindest) Fragmente der Software neu geschrieben werden müssen. Andernfalls droht die Software bei der Konfrontation mit der Realität – und dem Endnutzer – zu scheitern.

Dieses Phänomen wird mit dem Sammelbegriff der „technischen Schulden“ beschrieben. Die Strategie „try out and excuse later“ mündet für die Hersteller in hohen Refaktorierungskosten, während auf den Nutzer die Last der Installation und Nutzung unsicherer und oft instabiler Software oder Apps abgewälzt wird, wenn auch nur für eine begrenzte Zeit. Beide Seiten haben demnach ein Interesse daran, dass die technischen Schulden bei der Entwicklung einer Software niedrig bleiben.

Metriken, die relevant sind, um technische Schulden zu beziffern, lassen sich mit dem GQP ermitteln. Im Rahmen einer Abschlussarbeit [6] an der Hochschule für Telekommunikation in Leipzig (HfTL) wurden einige Software-Metriken ermittelt und teilweise die für ihre Berechnung notwendigen Messungen (Measures) identifiziert sowie praktisch erprobt (Abb. 3).

Die Bewertung von technischen Schulden, die ein sehr komplexes Ziel in der Gesamtzielsetzung eines Security-Gütesiegels darstellt, kann der Arbeit zufolge aufgrund weniger Messungen erfolgen, die der Hersteller den Prüfern zur Verfügung stellen sollte (LLoC, CLoC etc. – siehe Abb. 3). Der Vorteil dieser Herangehensweise ist, dass eine Offenlegung des Quellcodes für die Prüfung und Erteilung des Gütesiegels nicht notwendig ist – es erfordert dann lediglich die Herausgabe bestimmter, vordefinierter Messungen und die Verpflichtung der Hersteller, eine Prüfung der Software samt Quellcode durch sachverständige Dritte (Revisoren, Auditoren) zuzulassen. Optimalerweise erfolgt dies sanktionsbewährt, um die Motivation für die Hersteller zu erhöhen, wahrheitsgemäße Angaben zu machen.

Fazit

„Security by Design“ ist ein Bestandteil der Cyber-Sicherheitsstrategie 2016 und Forderung an die Hersteller zugleich. Die verbindliche Anforderung von „Privacy by Design“, die aus der EU-Datenschutzgrundverordnung (DSGVO) resultiert, wird derzeit ebenfalls – voraussichtlich in Form eines Zertifikats – auf EU-Ebene konkretisiert und systematisiert. Eine Verknüpfung bestehender (und geplanter) Zertifizierungen zu einem „Softwarezertifikat“ wäre unter der Voraussetzung denkbar, dass mit den Security- und Privacy-by-Design-Zertifikaten nicht nur die Ordnungsmäßigkeit, sondern auch die Wirksamkeit der Umsetzung von Vorgaben an die (Entwicklungs- und Produktions-) Prozesse aus der aktuellen Regulierung nachweislich geprüft und bestätigt wird.

Interessant sind in diesem Zusammenhang die Ergebnisse der Studie zum „Gütesiegel zur Kennzeichnung von IT-Sicherheit“, die im Auftrag des Bundesinnenministeriums von PwC durchgeführt wurde und in der „Interessen und Anforderungen relevanter Hersteller ermittelt und Eckpunkte für die Konzeption erarbeitet“ worden sind [7]. Im Abschlussbericht [8] werden denkbare Arten von Kriterien für die Vergabe des Gütesiegels aufgeführt:

• Technische Kriterien (z. B. Code-Inspection) wurden wegen Komplexität als nicht trivial abbildbar und mit hoher Expertise für die Überprüfung bewertet.
• Sicherheitsfunktionen (z. B. Zwei-Faktor-Authentifizierung) würden zwar einen geringeren Prüfaufwand bedeuten, reichen jedoch alleine als Kriterium zur Bewertung von Sicherheit nicht aus.
• Prozessuale Kriterien (z. B. Patch-Management oder Penetrationstest) könnten langfristig zu „einem besseren Qualitätsmanagement und somit zu einer erhöhten Sicherheit führen“.

Nach Auffassung befragter Hersteller wäre die Bewertung prozessualer Kriterien „kompliziert umzusetzen, da Unternehmensprozesse oft intransparent sind und der Prüfaufwand hoch ist“. Im Hinblick auf die Pflicht zur Umsetzung der DSGVO dürfte sich gegebenenfalls bezüglich der Prüfbarkeit und Nachvollziehbarkeit von Entwicklungs- und Produktions-Prozessen eine zunehmende Konformität beziehungsweise höhere Qualität erreichen lassen – zumal viele Hersteller zugleich auch ISO 27001-zertifiziert sind, was zumindest eine einheitliche Umsetzung von Security-Controls in der Organisation voraussetzt.

Noch mal von vorn?!

Bisweilen – verstärkt nach dem Bekanntwerden erfolgreicher Angriffe auf die technische Infrastruktur der deutschen Regierung – werden Stimmen laut, die eine „Tabula-rasa-Lösung“ für Software und IT-Systeme fordern: Man solle doch Zeile für Zeile alles neu und vor allem richtig (sicher, sorgfältig und sauber) programmieren.

Dies ruft die eingangs zitierten Worte von Edsger Dijkstra in Erinnerung: „… and when we recognize the battle against chaos, mess, and unmastered complexity as one of the computing science’s major callings, we must admit that ‚Beauty is our Business‘.“ [9] und weckt Hoffnungen, doch noch irgendwann eine gegen Angriffe resistente Software entwickeln zu können.

Effizienz und Funktionalität sind wichtig, Produktivität ebenfalls. Doch nicht weniger wichtig sind die hierzu eingesetzten Methoden und eine gute Ausbildung der Informatiker! Es waren nach Dijkstras Auffassung Schönheit und Eleganz, die helfen sollten, das Chaos und die Komplexität der Informatik und Mathematik zu beherrschen. Damit diese Ansätze auch bei neuer Software nicht schnell aus dem Fokus verschwinden, wird es notwendig sein, einen Satz relevanter Kontrollen und Metriken zu definieren, die dafür sorgen, dass im Endergebnis sichere und qualitativ hochwertige Software entsteht.

Viele sind des beständigen Flickens und der Patches überdrüssig. Vermutlich wäre es tatsächlich einfacher, alles zu löschen und irgendwo ganz von vorn anzufangen – auf dem Mars beispielsweise, wo das Wetter zu dieser Jahreszeit, wie es heißt, ganz angenehm sein soll …

Dr. Aleksandra Sowa ist zertifizierte Datenschutzbeauftragte, Datenschutzauditorin und IT-Compliance-Manager. Sie ist Publizistin, Gastdozentin und Autorin mehrerer Fachbücher zu Datenschutz und Compliance und Sprecherin des AK „Sicher in der Digitalisierung“ in der Gesellschaft für Informatik e. V. (GI).

Literatur

[1] Kaspersky Lab, Damage Control: The Cost Of Security Breaches, IT Security Risks Special Report Series, 2015,
http://media.kaspersky.com/pdf/it-risks-survey-reportcost-of-security-breaches.pdf
[2] Bundesministerium des Innern, Cyber-Sicherheitsstrategie für Deutschland 2016, November 2016, www.bmi.bund.de/cybersicherheitsstrategie/
[3] Sebastian Schreiber, Der Penetrationstest als Instrument der internen Revision, in: A. Sowa, P. Duscha, S. Schreiber, IT-Revision, IT-Audit und IT-Compliance, Neue Ansätze für die IT-Prüfung, Springer, November 2015, ISBN 978-3-658-02808-4
[4] Edsger W. Dijkstra, The Humble Programmer, Commununications of the ACM 15/10, Oktober 1972, S. 859, online auf https://dl.acm.org/citation.cfm?id=361591 und www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html
[5] Tom DeMarco, Controlling Software Projects: Management, Measurement, and Estimates, Yourdon Press, November 1982, ISBN 978-0-13-171711-4
[6] Marco Bauer, Ermittlung von technischen Schulden unter Verwendung von Metriken in einem agilen Software-Entwicklungsprojekt eines Provisionsabrechnungssystems, Bachelorarbeit, Hochschule für Telekommunikation Leipzig, 2015
[7] PricewaterhouseCoopers (PwC) strategy&, Konzeption eines IT-Sicherheits-Gütesiegels, April 2017, ManagementSummary,
www.bmi.bund.de/SharedDocs/downloads/DE/veroeffentlichungen/2017/it-guetesiegel-summary.pdf?__blob=publicationFile
[8] PricewaterhouseCoopers (PwC) strategy&, Konzeption eines IT-Sicherheits-Gütesiegels, April 2017, Abschlussbericht, www.bmi.bund.de/SharedDocs/downloads/DE/veroeffentlichungen/2017/it-guetesiegel.pdf?__blob=publicationFile
[9] Edsger W. Dijkstra, Some beautiful arguments using mathematical induction, Acta Informatica 13/1, Januar 1980, S. 1, online auf www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD697.html
[10] W. H. J. Feijen, A. J. M. van Gasteren, D. Gries (Hrsg.), Beauty is our Business: A Birthday Salute to Edsger W. Dijkstra, Springer, April 1990, ISBN 978-1-4612-8792-6