Softwaresicherheit ist wie Schönheit
Geprüfte Sicherheit – Gütesiegel oder Zertifikate
Edsger W. Dijkstra, aus den Niederlanden stammender Computerwissenschaftler, der an der Entwicklung der ersten Computersprachen und Compiler, Betriebssysteme und Programmiermethoden mitwirkte, war derjenige, den man als "Intellektuellen" unter den Ingenieuren und technisch orientierten Vertretern der damals relativ neuen Disziplin, der Computer Science, bezeichnen würde. Computerwissenschaft ist – wie der Name verrät – eine Wissenschaft. Das war nicht immer selbstverständlich. In den 1950er-Jahren haben Pioniere der Kybernetik dafür gekämpft, diese sehr praxisbezogene Disziplin in den Olymp der Wissenschaften aufzunehmen – und Dijkstra schuf viele der theoretischen Grundlagen hierfür. Mit Erfolg: In den 60er Jahren wurden in den USA die ersten Studiengänge für Computer Science etabliert [1].
Dijkstra war überzeugt davon, dass nicht nur Effektivität und Funktionalität, sondern vor allem Eleganz und Schönheit notwendig seien, um die Meisterschaft – die Überlegenheit – der Computerwissenschaft zu erreichen:
"… 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’." [2]
Effizienz und Funktionalität waren wichtig, Methoden und das Fachwerk ebenfalls. Doch es waren nach Dijkstras Auffassung Schönheit und Eleganz, die helfen sollten, das Chaos und die Komplexität der Informatik und Mathematik zu beherrschen. Dijkstra widmete sich deswegen u. a. der Erforschung und Entwicklung formaler Sprachen bzw. dem Problem der sogenannten formalen Verifikation. Für sein Werk erhielt er im Jahr 1972 den Turing Award – die höchste Auszeichnung, die einem Computerwissenschaftler erhalten kann (es sei an dieser Stelle daran erinnert, dass weder in der Disziplin der Mathematik noch der Informatik der Nobelpreis vergeben wird).
Vom Bug zur Schwachstelle
Mehr als vierzig Jahre danach, im Jahr 2015, wurde das "Red Team" – eine Gruppe von Hackern – von DARPA (Defence Advanced Research Projects Agency) beauftragt, die Sicherheit des sogenannten Little Bird – einer unbemannten Hubschrauber-Minidrohne – zu prüfen und zu testen [3]. Als die Hacker binnen kürzester Zeit in die Systeme der Drohne eingedrungen waren und ihre Steuerung übernommen hatten, musste sich DARPA etwas Neues einfallen lassen. Sie programmierte die Drohne neu. Die neue Software – nicht alle Details wurden enthüllt – setzte sich aus aufeinander aufbauenden Blöcken zusammen. Für die Ausführung eines Blocks war Verifikation notwendig, i. e. eine Bestätigung, dass der logisch vorgelagerte Block ausgeführt wurde. Mit u. a. dem Ergebnis, dass jemand mit Zugriffsrechten auf einen Block nicht automatisch für die Ausführung eines anderen Softwareblocks autorisiert war. Konfrontiert mit der so programmierten Little Bird war "Red Team" nicht mehr erfolgreich. Es war den Hackern zwar gelungen, in die einzelnen Bereiche einzudringen (bspw. den Zugriff auf die Webkamera zu erlangen), sie konnten aber von dort aus nicht auf die anderen Systeme oder die Steuerung zugreifen.
Das Internet ist für Softwarefehler das, was die Flugtouristik für infektiöse Krankheiten ist.
Formale Programmverifikation – so die korrekte Fachbezeichnung dieser Methode – war eines der Felder der Computerwissenschaften, auf dem auch Edsger Dijkstra forschte. In den 1980er- und 1990er-Jahren geriet die Forschung auf diesem Gebiet allerdings ins Stocken. Das Konzept der formalen Verifikation wurde nicht weiterentwickelt, denn es handelte sich nach Auffassung von Experten um die Suche nach einer arbeitsintensiven Lösung für ein nicht existierendes Problem. Konkret: Wenn ein Computer ab und zu aufgrund von Programmierfehlern abstürzte, dann kostete es höchstens Zeit, um den Rechner neu zu starten, eventuell ging also ein wenig Arbeit dadurch verloren. Kein Problem demnach, für das sich weitere Forschungsgelder gelohnt hätten.
Dann kam das Internet. Und machte mit den Softwarefehlern das, was die Flugtouristik mit der Verbreitung infektiöser Krankheiten tat: Wenn Computer und Geräte miteinander verbunden wurden, konnte ein bisher tolerierbarer Programmierfehler zu einer Kaskade von Sicherheitsvorfällen bzw. Sicherheitsproblemen führen. Oder zu einer flächendeckenden Netz-Katastrophe. Mit Internet, Digitalisierung, Internet of Things und Industrie 4.0 wurde (bzw. wird noch) jeder Fehler in der Software von heute zu einer potenziellen Schwachstelle von morgen, durch die Angreifer in die Systeme eindringen können.
Virulente Un-Sicherheit
Wie Kapersky Lab in einer aktuelle Studie heraus fand, betrugen die durchschnittlichen Kosten, die ein Unternehmen mit mehr als 1.500 Beschäftigten im Jahr 2015 pro Cyberattacke ausgegeben hatte, 551.000 US-Dollar. Und dies sind nur die direkten Kosten (Kosten für Mitarbeiter und externe Firmen bzw. IT-Forensik, Anwälte und Berater, Kosten für Geschäftsausfälle und entgangene Geschäfte) eines Sicherheitsvorfalls. Die indirekten Kosten belaufen sich auf weitere 69.000 US-Dollar für zusätzliches Personal, Erneuerung der Infrastruktur und Implementierung von Sicherheitsmaßnahmen.
Dabei nutzen die meisten Angreifer, so das Ergebnis der Studie, die naheliegenden Mittel wie Schadsoftware, Phishing-Mail oder Social Engineering, bei dem interne Mitarbeiter unbeabsichtigt Daten oder Informationen herausgeben, oder Schwachstellen und Fehler in der Software, um in die unternehmensinternen Systeme einzudringen. Dies waren laut Kaspersky Lab im Jahr 2015 die häufigsten Ursachen für Datensicherheitsvorfälle in Unternehmen [4]. Software Bugs avancierten so zur vierthäufigsten Ursache. Die Angreifer nutzen bspw. Schwachstellen in den Webapplikationen oder unsichere Webseiten als Eingangstor für verschiedene Arten von Attacken: beginnend mit dem einfachen Abfangen einer E-Mail bis hin zu anspruchsvollen APT-Attacken. Einmal in die Systeme gelangt, können sie weitaus größeren Schaden anrichten ‒ und oft über längere Zeiträume unentdeckt bleiben.
Die jüngsten Internetausfälle zeigen, dass Sicherheitsvorfälle nicht nur monetäre, sondern auch ernsthafte gesellschaftliche Folgen haben können.
Dabei sind die Sicherheitsvorfälle, die durch Software- und Programmierfehler verursacht werden, zwar sehr häufig, doch zugleich auch diejenigen mit dem niedrigsten monetären Impact. Was möglicherweise einer der Gründe für das geringe Interesse der Techunternehmen sein dürfte, sichere und qualitativ hochwertige Software zu produzieren. Der größte monetäre Schaden entstand Unternehmen im Jahr 2015 durch Sicherheitsvorfälle, die entweder durch Störungen bei den Lieferanten bzw. Outsourcing-Unternehmen ausgelöst wurden, Betrug durch interne Mitarbeiter zur Ursache hatten oder infolge von Cyberspionage zustande kamen.
Doch die jüngsten Internetausfälle in den USA und in Deutschland – wie auch bekannte Angriffe auf die kritischen Infrastrukturen (bspw. mithilfe des Wurms Stuxnet) – zeigen, dass Sicherheitsvorfälle nicht nur monetäre Folgen für die Wirtschaft, sondern zunehmend auch ernsthafte gesellschaftliche Folgen haben können [5]. So erheben sich aus der Politik, den Regierungskreisen – aber auch u. a. aus dem Chaos Computer Club oder der Gesellschaft für Informatik – Stimmen, die eine (nachweislich) bessere Qualität und Sicherheit der Software – und der IT-Systeme insgesamt – fordern. "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 des Bundesministeriums des Innern (BMI) [6]. Die eingesetzte Software muss – trotz steigender Komplexität und Intransparenz – professionellen Angriffen standhalten. Die Herstellung ist ein zumeist komplexer Vorgang, an dem mehrere Akteure beteiligt sind, und das Ergebnis ist einmalig. Die Übertragung von bewährten Prüfkriterien auf die Softwareprüfung scheint keinen hinreichenden Schutz vor den innewohnenden Risiken zu gewährleisten.
Geprüfte Sicherheit
Gefördert wird deswegen 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" , so das BMI [6]. Dabei müssen solche Kriterien nicht einmal neu erfunden werden, bestätigen Prof. Sabine Wieland und Prof. Andreas Hartmann von der Hochschule für Telekommunikation Leipzig (HfTL). Vielmehr gibt es zahlreiche Standards, Regelwerke und Normen darüber, wie qualitativ hochwertige und sichere Software zu entwickeln ist. Eine sinnvolle und adaptiv anpassbare Zusammensetzung der Prüfkriterien ist erstrebenswert.
Traditionell wird bei Bewertung der Softwarequalität der Standard ISO/IEC 9126 – Software engineering – Product quality – hinzugezogen. Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz, Wartbarkeit und Portabilität sind die Hauptmerkmale für die Softwarequalität, wobei die Sicherheit nur als einer der Indikatoren der Funktionalität gilt. Der neuere Standard bzw. ISO/IEC 25010 – Systems and software engineering– Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models – systematisiert ebenfalls die Bewertung von Softwarequalität, wobei er Gestaltungsfreiheiten bezüglich der festzulegenden Merkmale und Indikatoren für die Softwarequalität einräumt.
Sabine Wieland und Andreas Hartmann formulierten in Form von zehn Geboten die Kriterien und Anforderungen, mit deren Hilfe sichere und resiliente Systeme durch eine bessere Softwarequalität erreicht werden können [7]. Die wesentlichen Merkmale für die Bewertung sind dabei: Nachhaltigkeit (nicht nur von der Bundeskanzlerin von Facebook, Google und Co. gefordert [8]), Transparenz sowie Sicherheit. Sie bilden die Grundlage des Siegels "geprüfte Sicherheit", das die beiden Professoren entwickelt haben. Die Einführung eines solchen Gütesiegels für Informationssicherheit erstrebt laut Cyber-Sicherheitsstrategie 2016 auch die Bundesregierung: "Wirksame und bedarfsgerechte Zertifikate und Gütesiegel sind ein wichtiges Instrument für die Verbreitung von Cyber-Sicherheitsstandards", heißt es dort [6]. Aus der Studie von PwC Strategy& geht hervor, dass das IT-Sicherheits-Gütesiegel des BMI "mittelfristig nicht verpflichtend sein soll" [9].
Heterogene Prozesse
Eine wichtige Forderung an ein Softwarezertifikat ist, dass die Softwarequalität nicht erst und nicht nur am fertigen Produkt bewertet wird. Es sollte zwischen dem Herstellungsprozess und dem Softwareprodukt differenziert – und beide Aspekte gleichermaßen bei der Prüfung und Bewertung berücksichtigt werden. "Die Sache beginnt am Beginn", betonte auf der "Informatik 2016" der Gesellschaft für Informatik Prof. Dr Heinrich Mayr von der Universität Klagenfurt. Und meinte damit die ersten Phasen des Entwicklungsprozesses, insbesondere 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 bzw. ISO/IEC 25000 richten. Die nachweisliche, dokumentierte – und a posteriori prüfbare – Einhaltung der (noch zu systematisierenden) Prozesse der Security- und Privacy-by-Design wäre in diesem Zusammenhang denkbar. Security-by-Design ist dabei ein Bestandteil der Cyber-Sicherheitsstrategie 2016 und Forderung an die Hersteller zugleich. Die verbindliche Anforderung an Privacy-by-Design, die aus der EU-Datenschutzgrundverordnung (EU-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 denkbar, unter der Voraussetzung, 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-/Produktions-)Prozesse aus der aktuellen Regulierung nachweislich geprüft und bestätigt wird.
Interessant in diesem Zusammenhang sind die Ergebnisse der Studie zum "Gütesiegel zur Kennzeichnung von IT-Sicherheit", die im Auftrag des Bundesinnenministeriums vom PwC Strategy& durchgeführt und in der "Interessen und Anforderungen relevanter Hersteller ermittelt und Eckpunkte für die Konzeption erarbeitet" [9] wurden. Dort wurden im Abschlussbericht 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;
- Sicherheitsfunktionalitäten (z. B. Zwei-Faktor-Authentifizierung) – würden zwar 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" [9].
Nach Auffassung befragter Hersteller wäre die Bewertung prozessualer Kriterien "kompliziert umzusetzen, da Unternehmensprozesse oft intransparent sind und Prüfaufwand hoch ist". Im Hinblick auf das Obligo, die DSGVO zum 25. Mai 2018 auch in Deutschland umzusetzen, dürfte sich gegebenenfalls bzgl. der Prüfbarkeit und Nachvollziehbarkeit der (Entwicklungs-/Produktions-)Prozesse eine zunehmende Konformität bzw. höhere Qualität erreichen lassen, insbesondere da viele die Hersteller zugleich auch ISO-27001-zertifiziert sind, was zumindest eine einheitliche Umsetzung von Security Controls in der Organisation voraussetzt.
Der unvollkommene Beweis
Der zweite Aspekt des Gütesiegels ist die Betrachtung (und Prüfung) der Software als ein fertiges Produkt. Die Offenlegung bzw. das Transparentmachen des Quellcodes durch die Hersteller von proprietärer Software, um es von unabhängigen Prüfern bewerten zu lassen, ist nur eine der denkbaren Optionen. Auch eine A-posteriori-Modul- oder -IT-Systemprüfung käme infrage, bspw. im Rahmen von Pentrationstests, wie sie von Sebastian Schreiber als Methode der Revision [10] oder, gemeinsam mit Dr. Erlijn van Genuchten, als Prüfungsansatz für die IoT-Geräte systematisiert wurde [11]. Für die Aussagekraft eines Zertifikats oder Gütesiegels für IT-Sicherheit sind beide Aspekte von Relevanz. Penetrationstests sind eine wesentliche – und zunehmend verbreitete –, dennoch alleine nicht hinreichende Methode der Prüfung von Softwarequalität und -sicherheit. Sie bieten unvollkommene Beweise, sind dennoch unentbehrlich dort, wo der Entwicklungsprozess – wie der Quellcode selbst – im Verborgenen bleibt. Sie sollten deswegen um Kriterien für Software-Engineering, insbesondere für die Softwarequalität und -sicherheit, sinnvoll ergänzt werden, um aussagekräftige Ergebnisse zu gewährleisten. Ausgedrückt mit den Worten von 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 show the confidence level of a program significantly is to give o convincing proof of its correctness". [12]
- Knuth, D., 1972: George Forsythe and the Development of Computer Science. In: Communications of the ACM Vol 15 No 8 (1972)
- Feijen, W.H.J, van Gasteren, A. J. M., Gries, D, Misra, J., 1990: Beauty is our Business. A Birthday Salute to Edsger W. Dijkstra. Springer Verlag, S. xiv
- Vgl. Hernett, K., 2016: Computer Scientists Close In on Perfect, Hacker-Proof Code. In: Wired 23.9.2016
- Kaspersky Lab, 2015: Demage Control: The Cost of Security Breaches. IT-Security Risks Special Report Series
- Meinungsbarometer, 2016: Experten erwarten massive Hackerattacken. Was gegen Angriffe aus dem Internet der Dinge getan werden müsste. Interview mit A. Sowa und B. Krsic vom 15.12.2016
- BMI, 2016: Cyber-Sicherheitsstrategie für Deutschland 2016. BMI, Berlin (November 2016), S. 17
- Hartmann, A., Wieland, S., 2017: Zehn Gebote der Softwaresicherheit. In: IT-Prüfung, Sicherheitsaudit und Datenschutzmodell: Neue Ansätze für die IT-Revision, (A. Sowa, Hrsg.). Wiesbaden: Springer
- Reinbold, F., 2016: Warum Merkel an die Algorithmen will. In: Spiegel Online, 26.10.2016
- PwC Strategy&, 2017: Konzeption eines IT-Sicherheits-Gütesiegels. Management Summary, 25.4.2017
- Schreiber, S., 2015: Der Penetrationstest als Instrument der Internen Revision. In: IT-Revision, IT-Audit und IT-Compliance. Neue Ansätze für die IT-Prüfung (Sowa, A., Duscha, P. und Schreiber, S.). Wiesbaden: Springer Verlag
- Genuchten, E., Schreiber, S., 2017: Der IoT-Penetrationstest. In: IT-Prüfung, Sicherheitsaudit und Datenschutzmodell: Neue Ansätze für die IT-Revision, (A. Sowa,, Hrsg.). Wiesbaden: Springer
- Buxton, J. N., Randell, B., 1970: Software Engineering Techniques. Report on a conference sponsored by the NATO Science Committee, Rome, Italy, 27–31 October 1969, April 1970
