Basiswissen
Sichere Software
Sachar Paulus ist Professor für Wirtschaftsinformatik, insbesondere Unternehmenssicherheit und Risikomanagement, an der Fachhochschule Brandenburg, Inhaber der Unternehmensberatung für Sicherheit »paulus.consult« und Senior Analyst bei KuppingerCole. Von 2000 bis 2008 war er bei SAP in verschiedenen Leitungsfunktionen zu Sicherheit tätig, u. a. als Leiter der Konzernsicherheit und Leiter der Produktsicherheit, und vertrat SAP als Vorstandsmitglied in den beiden Vereinen »Deutschland Sicher im Netz« und »Tele-TrusT«. Weiter war er Mitglied der ständigen Interessenvertretung der ENISA (Europäische Netzwerk- und Informationssicherheits-agentur) und des Forschungsbeirats »RISEPTIS« für Vertrauen und Sicherheit im Future Internet der Europäischen Kommission. Er engagiert sich für sichere Softwareentwicklung und ist Gründer und Präsident des ISSECO e.V.
Aus- und Weiterbildung zum ISSECO Certified
Professional for Secure Software Engineering
Sachar Paulus
sachar.paulus@paulus-consult.de
Lektorat: Christa Preisendanz
Copy-Editing: Ursula Zimpfer, Herrenberg
Herstellung: Nadine Thiele
Umschlaggestaltung: Helmut Kraus, www.exclam.de
Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;
detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
ISBN:
Buch 978-3-89864-726-7
PDF 978-3-86491-052-4
ePub 978-3-86491-053-1
1. Auflage 20011
Copyright © 2011 dpunkt.verlag GmbH
Ringstraße 19 B
69115 Heidelberg
Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.
Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-,
marken- oder patentrechtlichem Schutz unterliegen.
Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.
5 4 3 2 1 0
Sicherheit ist gegenwärtig in aller Munde. Ganz gleich, ob es um die Finanzkrise, Erdbeben und Tsunamis, Kernkraftwerke oder Spielekonsolen geht: Sicherheit wird aufgrund der Komplexität unserer Gesellschaft immer wichtiger.
Softwaresicherheit, damit meine ich die Fähigkeit, Software herzustellen, die sowohl Angriffen standhält als auch keine Schäden in ihrer Umwelt verursachen kann, wird in ihrer Bedeutung stark unterschätzt. Es gibt wohl keinen Kompetenzbereich, der einerseits in so vielen Branchen und Technologien erforderlich ist, gleichzeitig aber so stiefmütterlich behandelt wird.
Dabei gilt dies für alle, die in den Herstellungsprozess von Software involviert sind, und zwar unabhängig davon, ob die Software als eigenes Produkt verkauft wird, eine eingegrenzte Hardwarefunktion unterstützt (wie z.B. im Automotive-Bereich), Webanwendungen am Laufen hält oder komplexe technische Anlagen steuert. Betroffen sind alle Stakeholder: solche, die Anforderungen stellen, jene, die entwickeln, diejenigen, die testen, und wiederum die, die Software betreiben und einsetzen. Auch die Größe spielt keine Rolle: Kein Einmannbetrieb kann sich aus der Verantwortung für Softwaresicherheit damit herausreden, sein Unternehmen sei zu klein. Genauso spielt das Business-Modell keine Rolle. Ob »as a Service«, als Produkt oder als Dienstleistung: Immer und überall muss auf Sicherheit während des Produktionsprozesses geachtet werden, damit in unserer stark integrierten und zusammenwachsenden Welt Softwareanwendungen nicht Quelle von Gefahren und Verunsicherung werden.
Damit wird dieses Feld »the next big thing«, davon bin ich überzeugt. Genau wie vor 20 Jahren, als das Thema »Softwarequalität« niemanden wirklich interessiert hat, aber zwingend notwendig war, um Software professionell betreibbar zu machen, und damit grundlegend für gewaltige Innovationen wurde, interessieren sich heute viele Anwender für Sicherheit – aber nicht für die dafür erforderlichen Aktivitäten und Skills im Bereich der Softwaresicherheit. Denn so wie man Kernkraft nicht sicher gestalten kann, ohne die physikalischen Prozesse zu kennen, so kann man Softwareprodukte nicht nachträglich sicher machen, sondern muss bereits im Herstellungsprozess Vorsorge treffen.
Daher begrüße ich die mutigen Streiter und Vorausdenker von ISSECO, die mit ihrem CPSSE-Zertifikat zum richtigen Zeitpunkt auf den Markt gekommen sind. Der »Certified Professional for Secure Software Engineering« war das erste Personenzertifikat zu Softwaresicherheit und ist das einzige in Europa. Der CPSSE kann auch als Baustein für den Quality Assurance Management Professional (QAMP) verwendet werden. Die Anzahl der Zertifizierungen wächst stetig, und durch das vorliegende Buch, dessen bin ich mir sicher, wird die Anzahl der Zertifikate noch einmal stark steigen. Denn die Zielgruppe sind nicht nur Entwickler, sondern eben alle, die mit Softwareentwicklung zu tun haben und wissen sollten, was an Sicherheit für ihre Software erforderlich ist und wie dies umgesetzt werden kann – auf Kunden- wie auf Herstellerseite oder als Berater.
Ich wünsche dem Buch »Basiswissen Sichere Software« und dem Zertifikat »CPSSE« für die Zukunft viel Erfolg.
Stephan Goericke
Director iSQI GmbH
IT-Management wird eine immer komplexere Aufgabe. Durch die zunehmende Vereinfachung der Informationstechnologie und den Druck, auch im Unternehmen Dienste anzubieten, die die Mitarbeiter aus dem privaten Bereich kennen, stellen sich immer mehr Anforderungen an den Leiter einer IT-Organisation, der sowohl einen effizienten, kostenoptimierten Betrieb gewährleisten will als auch seine Kunden, also die Geschäftsbereiche, zufriedenstellen möchte.
Ein besonders komplexes Aufgabengebiet stellt dabei die IT-Sicherheit dar. Auf der einen Seite sollen die IT-Dienste möglichst leicht und komfortabel verwendbar sein, auf der anderen Seite muss die IT-Leitung Verfügbarkeit, Vertraulichkeit und Integrität der zu verarbeitenden Daten sicherstellen – und wird auch dafür verantwortlich gemacht. Dies ist nicht zuletzt deswegen so aufwendig, weil viele Softwarehersteller und Diensteanbieter im Hinblick auf Sicherheit die Anforderungen der Kunden nicht genügend beachten, und dies oft nur mit teuren Zusatzlösungen oder viel individuellem Aufwand wettgemacht werden kann.
Auftraggeber müssen künftig immer mehr Einfluss auf die Gestaltung der Angebote nehmen – ob als Software, als Dienst oder als mobile »App«. Dies gilt insbesondere für IT-Architekturen, die mit dem Stichwort »Cloud« verbunden sind, ob nun in einer Private, Public oder Hybrid Cloud. Hier ist ein geeigneter Prozess der Anforderungsdefinition schon beim Kunden erforderlich, entsprechende Maßnahmen für die Ermittlung von möglichen Bedrohungen durch Hacker und Spione und andere Sicherheitsanforderungen, wie etwa die Integration in ein Identitätsmanagementkonzept, sind ebenfalls notwendig für eine schlüssige IT-Sicherheitsarchitektur.
Zudem ist es von Vorteil, wenn man als Kunde auch versteht, welche Anforderungen an den Prozess der Entwicklung an Softwarehersteller gestellt werden müssen, damit auch sichere Software erzeugt werden kann. Erst durch das Verständnis dafür, warum das Schützen von Software so schwierig ist und was man tun kann, ist auch der sichere Einsatz von Software und von internetbasierten Diensten nachhaltig möglich.
Aus diesem Grund freue ich mich sehr, wenn eine Initiative wie ISSECO sich um die Qualifizierung für Aspekte der Softwaresicherheit bemüht und ein renommierter Experte wie Prof. Paulus sich die Zeit nimmt, ein Lehrbuch zu sicherer Softwareentwicklung zu schreiben. Denn nur wenn man das Übel an der Wurzel packt, sprich: betroffene Zielgruppen im Entwicklungsprozess über die Risiken ihrer Arbeit aufklärt und ihnen Wege aufzeigt, wie sie diese im Sinne ihrer Kunden beheben können, wird sich die Situation nachhaltig verbessern. Dies gilt auch für die Anwenderunternehmen, die lernen müssen, die »richtigen« Anforderungen an die Lieferanten zu stellen.
Zusammen mit Experten können unsere IT-Mitarbeiter nun durch das vorliegende Buch und die passenden Schulungen und Zertifikate diese Herausforderung annehmen.
Ich wünsche diesem Projekt viel Erfolg!
Jörg Brinkmann
CIO Bilfinger Berger SE
Es hat eine Weile gedauert, bis dieses Buch zustande gekommen ist. Zwar ist die ISSECO-CPSSE1-Zertifizierung noch relativ jung – es gibt sie seit Herbst 2009 –, aber die Idee, ein deutsches Lehrbuch zum Thema zu schreiben, hatte ich schon seit längerer Zeit.
Das Feld der Themen, die für sichere Softwareentwicklung relevant sind, ist zudem relativ breit, und eine Auswahl und Zusammenstellung für ein »Basiswissen« ist nicht trivial. Daher war die Anfrage des dpunkt.verlags, zur Zertifizierung ein Buch zu schreiben, der Auslöser, endlich dieses Projekt zu beginnen, und die Ausrichtung am Syllabus des ISSECO CPSSE ist eine willkommene Orientierung gewesen. Die Inhalte der Schulungen habe ich an der einen oder anderen Stelle um aktuelle Informationen ergänzt und erläuternde Hintergrundinformationen hinzugefügt. Damit sollte das Buch auch für die nächste Version des Syllabus »passen«, also als Prüfungsvorbereitung für die Zertifizierung dienen können.
Ich möchte mich bei den folgenden Personen bedanken, ohne die dieses Buch nicht entstanden wäre: bei den Kollegen von ISSECO, und zwar bei allen, die beim Syllabus und der Entwicklung der ersten Schulungsunterlagen mitgeholfen haben, im Speziellen bei Petra Barzin und Peter Trommler. Beide haben auch dankenswerterweise als Korrekturleser bereitgestanden. Weiterhin möchte ich mich bei iSQI2 und natürlich speziell bei Stephan Goericke bedanken, ohne die es ISSECO nicht geben würde. iSQI hat die Gründung des Vereins tatkräftig unterstützt und bildet ein stabiles organisatorisches Rückgrat für den Verein. Auch die Damen von dpunkt, namentlich insbesondere Christa Preisendanz, verdienen meinen Dank, sie haben immer wieder Feedback gegeben und sind letztlich dafür verantwortlich, dass das Buch auch in die Reihe »Basiswissen« passt.
Schließlich möchte ich mich bei meiner Familie bedanken, meiner Frau Diana und meinen beiden Kindern Mika und Gina, die mir in den letzten Monaten verziehen haben, dass ich mich nicht so um sie gekümmert habe, wie ich es hätte machen sollen, speziell da wir in dieser Zeit wieder Nachwuchs bekommen haben. Der kleinen Lola wünsche ich alles Gute für ihr Lebensabenteuer.
Ich hoffe, dass Sie das Buch nicht nur als Lehrgrundlage gut verwenden können, sondern auch ein wenig Spaß beim Lesen haben und dass Sie vielleicht ein klein bisschen von der Faszination erhaschen können, ein Softwareprodukt gleichzeitig elegant und sicher zu machen.
Sachar Paulus
Neckargemünd, im Mai 2011
1 Einleitung
1.1 Ziele dieses Buches
1.2 Inhalte dieses Buches
1.3 ISSECO und die CPSSE-Zertifizierung
2 Die Sicht des Kunden
2.1 Ben und sein Projektteam
2.2 Verschiedene Interessengruppen – verschiedene Interessen
2.3 Warum erwarten Kunden sichere Software?
2.4 Was genau erwarten Kunden eigentlich?
2.5 Werte, Bedrohungen und Risiken
2.6 Von Erwartungen zu technischen Anforderungen
2.7 Helfen Sie dem Kunden, dann helfen Sie sich selbst!
2.8 Ben spricht noch einmal mit dem Kunden
3 Die Sicht des Angreifers
3.1 Jewgeni
3.2 Was sind Hacker?
3.3 Wie geht ein Hacker vor?
3.4 Jewgeni hat eine Idee
4 Methodologien für sichere Software
4.1 Bens Entwicklungsmethodik
4.2 Sichere Software im Überblick
4.3 Softwareentwicklungsmethoden
4.4 Maßnahmen zur Verbesserung der Sicherheit
4.5 Existierende Modelle
4.6 Ben denkt über Sicherheit nach
5 Sicherheitsanforderungen
5.1 Bens Sicherheitsanforderungen
5.2 Was sind Anforderungen?
5.3 Wie identifiziert man Sicherheitsanforderungen?
5.4 Wichtige Sicherheitsanforderungen
5.5 Bens neue Anforderungsliste
6 Bedrohungsmodellierung
6.1 Bens Bedrohungsmodellierung
6.2 Der Nutzen einer Bedrohungsmodellierung
6.3 Die Phasen der Bedrohungsmodellierung
6.4 Bens zweiter Versuch
7 Sicherer Softwareentwurf
7.1 Bens Softwareentwurf für Sicherheit
7.2 Sicherer Softwareentwurf und sichere Softwarearchitekturen
7.3 Secure Design Patterns
7.4 Secure Design Principles
7.5 Review der Sicherheitsarchitektur
7.6 Ben war auf einer Konferenz
8 Sicheres Programmieren
8.1 Bens Tricks zum sicheren Programmieren
8.2 Es gibt keine Tricks
8.3 Welche Schwachstellen sind am kritischsten?
8.4 Wiederkehrende Muster von Schwachstellen
8.5 Techniken für sicheres Programmieren
8.6 Die wichtigsten Schwachstellen und Gegenmaßnahmen
8.7 Werkzeuge zur sicheren Programmierung
8.8 Klaus’ Empfehlungen für die sichere Programmierung
9 Software auf Sicherheit testen
9.1 Bens Sicherheitstest
9.2 Sicherheit und Softwaretests
9.3 Hacking-Techniken als Sicherheitstests
9.4 Sicherheitsspezifische Testmuster
9.5 Sicherheitskritische Testbereiche
9.6 Codereview
9.7 Sicherheitstestberichte schreiben
9.8 Der Sicherheitstest vom QMB
10 Sichere Auslieferung und Einrichtung
10.1 Bens Installationsanleitung
10.2 Sicherheit im IT-Betrieb
10.3 Phasen der Softwareeinrichtung
10.4 Pauls Korrekturen der Installation
11 Umgang mit Schwachstellen
11.1 Bens Security Response
11.2 Sicherheit im normalen Supportprozess
11.3 Offenlegungsstrategien für Schwachstellen
11.4 Erfolgreich über Schwachstellen reden
11.5 Standards für Schwachstellenbeschreibungen
11.6 Entwicklung einer Security Response Policy
11.7 Ben und die IT-Presse
12 Metriken für Sicherheit
12.1 Bens Messgrößen
12.2 Warum überhaupt Metriken für Sicherheit?
12.3 Softwaremetriken
12.4 Arten von Metriken
12.5 Qualitätskriterien für Metriken
12.6 Existierende Metriken für Sicherheit
12.7 Entwicklung von Metriken für Sicherheit
13 Codeschutz
13.1 Ben und seine eigene IT-Sicherheit
13.2 Gründe, den Code zu schützen
13.3 Technische Risiken während der Entwicklungsphase
13.4 Grundsätzliche Schutzmechanismen
13.5 Besondere Anforderungen durch Export und Politik
13.6 Technische Lösungen für den Schutz von Code
13.7 Lizenzschutz
13.8 Was hätte Ben unternehmen können?
14 Testfragen
Abkürzungen
Glossar
Literatur
Index
Sichere Software ist Software, die gegen absichtliche Angriffe auf die Software geschützt ist. Jeder im Softwareentwicklungsprozess sollte an dieser Eigenschaft einer Software interessiert sein, da Software leider selten »automatisch« sicher ist. Da Sicherheit durch die Abwesenheit von erfolgreichen Angriffen gegeben ist, muss die Software jedem möglichen Angriff standhalten können. Dieses Buch richtet sich an Softwareentwicklungsverantwortliche und Qualitätsverantwortliche, die Sicherheit im Entwicklungsprozess verankern wollen, aber auch an Sicherheitsexperten, die sich der Thematik »wie mache ich Software sicher?« widmen wollen.
IT-Systeme sind nur sicher, wenn alle Elemente, die zum IT-System gehören, sicher sind. Der in der Vergangenheit übliche Gedanke, dass die Sicherheit von der Infrastruktur und dem Perimeter erbracht werden kann (also Firewalls, Antivirus-Software, Betriebssystemsicherheit), ist nicht mehr richtig. Eigentlich war der Gedanke noch nie richtig, aber da die wertvollen Informationen in den Anwendungen hinter hohen (virtuellen) Wänden lagen und dort meist ungeschützt, bestand das Ziel darin, Löcher in der Infrastruktur zu finden, so wie es im Mittelalter das Ziel war, Zugang in ein Burg zu bekommen, denn innerhalb der Mauern war der Schatz meist nicht gut gesichert.
Aus zwei Gründen ist dieser Vergleich nicht mehr verwendbar: Zum einen werden immer mehr Anwendungen aus der Burg herausgeholt bzw. sprechen mit Kunden jenseits der Burgmauern und zum anderen sind die Löcher in den Burgmauern weitestgehend gestopft und es ist einfacher für Angreifer, direkt die Anwendungen anzugreifen. Moderne IT ist eher mit einer Stadt zu vergleichen als mit einer mittelalterlichen Burg.
Abb. 1–1 So nehmen heute noch die meisten IT-Sicherheit wahr – eine dicke Mauer mit wenigen Durchgängen (Quelle: www.copyrightfreephotos.com).
Abb. 1–2 Und so sollte Sicherheit in der heutigen Welt aussehen – sehr individuell, massentauglich und auf das jeweilige Risiko abgestimmt (Quelle: www.copyrightfreephotos.com).
Daher ist es nicht nur wichtig, sichere Infrastrukturkomponenten zu bauen, sondern alle Softwareelemente eines IT-Systems müssen sicher sein. Sicher heißt, dass sie nicht durch Angriffe auf Daten in ihrer Funktionalität verändert werden können, Daten kopiert, manipuliert oder gelöscht werden können oder ihre Verfügbarkeit eingeschränkt werden kann. Die Informationen sollen stets verfügbar, integer und vertraulich verarbeitet werden. Das heißt, egal, ob Sie Softwareprodukte entwickeln, softwarebasierte Steuerungen für Anlagen bauen oder Webanwendungen konfigurieren, Ihre Software ist jetzt das Ziel der Hacker und nicht nur das Ziel, sondern – wenn Sie schlechte, sprich: unsichere Software bauen – auch das Werkzeug, unfreiwillig. Die meisten Angriffe auf Daten sind heutzutage auf unsichere Software und Systeme zurückzuführen, Systeme, die eine Schwachstelle haben, die von Angreifern ausgenutzt werden kann – und ausgenutzt wird.
Dieses Buch hat zum Ziel, zu vermitteln, wie man sichere Software entwickeln kann. Dabei werden alle wichtigen Bereiche der Softwareentwicklung besprochen und aufgezeigt, was für Sicherheit getan werden kann – und muss.
Die Mehrzahl der Angriffe auf Daten finden heute über das Internet statt unter Verwendung von komplexen Werkzeugen wie trojanischen Pferden, Botnetzen, Rootkits usw. Auch wenn wir sehen werden, dass das Bild in dieser Deutlichkeit nicht ganz richtig ist: Heute kann ein Hacker im Prinzip vom heimischen Sofa aus (fast) alle IT-Systeme dieser Welt angreifen. Und sind diese nicht gut geschützt bzw. nicht sicher in sich selbst, dann auch erfolgreich.
Abb. 1–3 Aus der polizeilichen Kriminalstatistik 2010 (Quelle: www.bka.de/pks/pks2010/download/pks2010_imk_kurzbericht.pdf, S. 15)
Neben dem reinen finanziellen Schaden, den ein Hacker anrichten kann, ist in der Konsequenz auch oft das Image des Herstellers wie auch des Kunden, der die Systeme betreibt und bei dem Daten gestohlen oder manipuliert werden konnten, in Mitleidenschaft gezogen. Zudem werden – man geht von einer deutlich höheren Dunkelziffer aus – die meisten Angriffe vermutlich gar nicht entdeckt: Wissensvorsprung wandert zum Konkurrenten, Industriegeheimnisse zur fremden Macht, IT-Systeme werden zur langsamen Sabotage genutzt. Die Liste ist lang.
Aber warum schützen uns die Sicherheitsprodukte nicht vor diesen Angriffen? Sind denn die Investitionen in Antivirus-Software und Firewalls, in Verschlüsselung und Data Leakage Prevention nicht genau dafür da, dies zu verhindern? Ein einfacher Vergleich: Nur weil ein Auto einen Sicherheitsgurt hat, muss die Bremse nicht zuverlässig funktionieren. Im Web ist das ähnlich. Anwendungen müssen sich selbst schützen, die genannten Sicherheitsprodukte schützen zwar jeweils bestimmte Technologien gegen bestimmte Angriffe, aber auch nur diese Technologien gegen genau diese Angriffe. Es gibt ja auch keinen Impfstoff gegen alle Krankheiten dieser Welt. Und wenn gestern das Wichtigste war, sich gegen Cholera zu schützen, dann kommt heute die Hauptbedrohung vielleicht von Grippenviren. Am besten ist ein gut funktionierendes Immunsystem. Auch dann kann man Infektionen nicht vollständig vermeiden, aber meist lebt man damit deutlich länger – und besser.
Der erste Schritt zu einem guten Immunsystem ist, Einfallstore zu schließen, und Angriffsflächen zu verkleinern. Und in der aktuellen Zeit – Technologie verändert sich ja zunehmend schneller – sind die meisten IT-Technologien HTTP-basiert und Zugriffe auf Daten sollten von überall ohne Hürden erfolgen können. Gegen Angriffe auf Anwendungsebene können Firewalls, die dazu da sind, unerlaubte Zugriffe auf Netzwerkebene abzuweisen, und Antivirus-Software, die bösartige E-Mail-Anhänge erkennen soll, eben nichts tun. Da sind andere Techniken gefragt. Doch am besten schützt die Software sich selbst.
Wenn ein gutes Immunsystem so wichtig und so sinnvoll ist, warum gibt es das nicht bei Software? Was läuft schief bei den meisten Softwareentwicklungen, dass eben der Eigenschutz der Software gegen Angriffe nicht funktioniert? Hierfür gibt es eine Reihe von Gründen.
Softwarehersteller, wie auch viele Kunden, reden nicht gerne über Sicherheitsprobleme oder Schwachstellen, denn sie fürchten Imageprobleme und Reputationsverlust mehr als den möglicherweise entstehenden Schaden. Darüber nicht zu reden ist eigentlich widersinnig, denn natürlich gibt es eine Bedrohung, und kein Produkt der Welt ist perfekt, also sollte man sich genau damit auseinandersetzen, um Größe zu demonstrieren. Studien von Krisen, in denen Unternehmen unterschiedlich offenes Krisenmanagement betrieben haben, zeigen, dass die Unternehmen, die proaktiv mit einer Krise umgegangen sind (z. B. eine Airline nach einem Flugzeugabsturz), in der Wahrnehmung und sogar in der börslichen Bewertung besser geworden sind. Ein Grund, warum dennoch die Auseinandersetzung mit dem Thema IT-Sicherheit vermieden wird, ist möglicherweise, dass man damit zugeben müsste, dass man die IT nun doch nicht vollständig beherrscht und insbesondere Unternehmenslenker sich auf etwas verlassen, das sie gar nicht verstehen.
Viele Entscheider schätzen die mit IT-Sicherheit verbundenen Risiken falsch ein. Das ist systemimmanent, denn der Job von Entscheidern besteht gerade darin, Chancen zu nutzen und dafür Risiken einzugehen. Ihnen ist aus diesem Grund vermutlich durchaus bewusst, dass im IT-Bereich Sicherheitsrisiken bestehen, aber diese werden – aus Mangel an Einsicht und Verständnis – chronisch falsch eingeschätzt. Wurde gestern noch Onlinebanking im Ausland nur mit Passwort durchgeführt, bis unbekannte Buchungen auf den Kontoauszügen auftauchten, so werden heute Cloud-Lösungen vermieden, obwohl die Sicherheitsmechanismen genau dafür vielleicht exzellent ausgelegt sind. Werden aber die Sicherheitsrisiken deutlich überschätzt, dann investiert man nicht in Schutzmaßnahmen, sondern vermeidet das Risiko lieber gleich komplett.
Auf einer etwas technischeren Ebene äußert sich das so, dass in der Regel, d. h. immer noch für die allermeisten Softwareprodukte und -Lösungen, die Sicherheitsanforderungen gar nicht bekannt sind. Man verlässt sich auf die Infrastruktur (die Burgmauer) oder weiß vielleicht gar nicht, welche schützenswerten Informationen von der Software verarbeitet werden. Dann kann man daraus natürlich auch keine Anforderungen an die Sicherheitsfunktionalität ableiten und noch weniger an die Sicherheitseigenschaften des zu entwickelnden Produktes. Aus Sicherheitssicht gleichen die meisten Entwicklungsprojekte einem Blindflug durch die Berge: Mit Gottvertrauen hofft man, dass schon nichts passieren wird, ohne die Gefahrensituation genau zu kennen.
Schließlich stehen fast alle Softwareentwicklungsprojekte unter einem hohen Kosten- und Zeitdruck und dann zählt natürlich fast ausschließlich die Funktionalität, die dem Kunden Mehrwert bietet. Qualitätsaspekte, insbesondere Sicherheitsaspekte, spielen dann oft eine untergeordnete Rolle und werden im Zweifel einfach fallen gelassen.
Sicherheit muss sich also gegen eine ganze Reihe von Vorbehalten wehren, bevor sie ernst genommen wird? In den meisten Fällen ist dem so. Sicherheit kommt bei den meisten ganz am Schluss der Qualitätsaspekte, deutlich nach Performance und Usability.
Vielleicht können Sie dies aber in Ihrer Organisation Zug um Zug ändern. Denn wenn man nicht in Sicherheit investiert, dann hat das natürlich Konsequenzen. Diese sollten Sie nicht nur Ihrem Chef deutlich machen, sondern auch – und gerade – dem Kunden, damit der Kunde sein Risiko abschätzen kann und nicht von negativen Erfahrungen mit Ihrer Software überrascht wird.
Unsichere Software führt zu höherem Wartungsaufwand. Unsichere Software muss häufiger gepatcht werden, Korrekturen des Herstellers müssen vor dem Einspielen üblicherweise getestet werden, dies wiederum führt zu einem verspäteten Patchen mit weiteren Sicherheitsrisiken, die dann durch zusätzliche Sicherheitsprodukte wieder begrenzt werden müssen, und so weiter. Der höhere Wartungsaufwand entsteht nicht nur beim Kunden, sondern natürlich auch beim Hersteller, der für Sicherheitskorrekturen in der Regel vom Kunden nicht entlohnt wird, sondern dies im Rahmen seiner Wartungsvereinbarung erwartet. Dafür wiederum sind mehr Mitarbeiter erforderlich, die speziell geschult werden müssen ... Die Kostenspirale entsteht bei der ersten entdeckten Schwachstelle in der Software. Vorher ist dafür keine Aufmerksamkeit vorhanden, doch dann wird – je nach Kritikalität der verarbeiteten Daten – sehr schnell reagiert und entsprechend gehandelt.
Unsichere Software führt zu Imageschaden.
Sowohl Firmen, die unsichere Software einsetzen, als auch die Hersteller von unsicherer Software müssen ständig damit leben, in der Presse »auseinandergenommen« zu werden. Die Presse stürzt sich mit Vorliebe auf Sicherheitsprobleme, denn sie zeigt die – vermeintliche – Unfähigkeit, mit Risiken umgehen zu können, was immer eine »gute« Nachricht wert ist. Auch dies geht genau so lange gut, bis die erste Schwachstelle bekannt wird. Stellen Sie sich einen erfolgreichen Hacking-Angriff auf eine Onlinebanking-Seite vor und die Reaktion der Presse ...
Unsichere Software kann Softwareherstellern das Geschäft ruinieren.
Da die meisten Softwaremärkte doch inzwischen recht gesättigt sind, wird Sicherheit zunehmend zu einem Differenzierungsmerkmal, und wenn ein Produkt zwar als das funktional bessere, aber in puncto Sicherheit als das deutlich schlechtere wahrgenommen wird, so entscheiden sich immer mehr Kunden im Business-Bereich für das sicherere Produkt, selbst bei vermutlichem Verlust von Funktionalität. Es muss noch nicht einmal dazu kommen, dass Produkte gar nicht mehr gekauft werden, alleine schon die Verzögerung im Vertriebsprozess und der damit verbundene deutlich spätere Geldeingang kann aufgrund der Auswirkung auf die Liquidität für die Existenz einer Unternehmung kritisch sein.
Alle diese Beobachtungen sind natürlich nur dann bemerkbar, wenn man einen Markt über einen längeren Zeitraum beobachtet. Wie bei allen sicherheitsrelevanten bzw. sicherheitskritischen Tätigkeiten ist es immer möglich, kurzfristig Profit zu erzielen und dabei die Investitionen für Sicherheitsmaßnahmen einzusparen. Daher hilft diese Argumentation in einem Überzeugungsgespräch nur, wenn auf der Gegenseite jemand sitzt, der Interesse an einer langfristigen Perspektive hat. Bevor Sie also den Aufwand treiben, einen Überzeugungsversuch für sichere Software zu starten, sollten Sie genau einschätzen können, wer Ihnen gegenübersitzt und welche Motivationen er hat.
Der Schwerpunkt dieses Buches ist, Ihnen einen erweiterten Überblick darüber zu geben, was alles erforderlich ist, um sichere Software professionell produzieren zu können. Das ist kein Hexenwerk, es gibt aber auch kein Allheilmittel. Vielmehr ist in der Praxis mühevolle Kleinarbeit erforderlich, die sich an vielen, über den gesamten Entwicklungsprozess verteilten Stellen zeigt – oder eben nicht zeigt, aber dennoch erforderlich ist. Dieses Buch ist
kein Buch über das Hacken,
kein Buch über Sicherheitstests und
kein Buch über sicheres Programmieren.
Sollten Sie diese Erwartung haben, dann muss ich Sie leider enttäuschen. Zwar wird in diesem Buch natürlich auf diese Themen eingegangen, aber eben nur im Überblick, denn der Mix, die Kombination, das Zusammenwirken ist der Schlüssel für sichere Software. Lieber in allen Bereichen moderat investieren und gezielt risikoorientiert vorgehen, um die wichtigsten Tätigkeiten durchzuführen, als in einem Bereich das gesamte Budget zu versenken. Wenn es eine Botschaft geben soll, von der ich mir wünsche, dass Sie, geneigter Leser, sie nicht vergessen, dann diese. Es bringt Ihnen nämlich nichts außer einem Strohfeuer und der damit verbundenen Aufregung, wenn Sie Ihr Sicherheitsbudget z. B. komplett in eine Sicherheitsüberprüfung Ihrer Software stecken – denn womit bezahlen Sie dann die erforderlichen Folgeaktionen? Oder in die Schulung ihrer Programmierer – woher wissen Sie, dass Sie die richtigen Schwachstellen abdichten?
Hier ein Überblick über die Inhalte dieses Buches:
In Kapitel 2 beginnen wir mit der Sicht des Kunden. Kunden haben in Bezug auf Sicherheit oft ein großes Problem: Sie wissen gar nicht, was sie in diesem Bereich eigentlich erwarten. Also müssen Sie diese Arbeit für den Kunden übernehmen, wenn Sie Ihren Auftrag, Sicherheit (mit-) zu produzieren, ernst nehmen.
In Kapitel 3 wechseln wir die Perspektive und wenden uns der Sicht des Angreifers zu. Der Angreifer hat andere Möglichkeiten, andere Motivationen, einen anderen Hintergrund. Und oft anders als man es erwarten würde. Daher sollten Sie nach diesem Kapitel mit allem rechnen.
Kapitel 4 gibt einen Überblick über die existierenden methodischen Ansätze (Methodologien), sichere Software zu produzieren. Dabei werden strenge Vorgehensweisen, wie Common Criteria, genauso betrachtet wie pragmatische Ansätze, wie etwa OpenSAMM. Natürlich darf der Microsoft SDL nicht fehlen. Wichtig: Die Umsetzung dieser Ansätze ist für jedes Entwicklungsmodell möglich!
Ab Kapitel 5 gehen wir auf die einzelnen Aktivitäten ein, die Sie entlang Ihres Entwicklungsprozesses einführen bzw. ergänzen sollten, um zunehmend sicherere Software produzieren zu können. Kapitel 5 widmet sich der Thematik der Sicherheitsanforderungen, welche Besonderheiten es bei Sicherheit gibt und wie man sich diese erschließen kann.
Das 6. Kapitel, Bedrohungsmodellierung, beschreibt eine besondere Technik, um die möglichen Bedrohungen für eine Software ermitteln und bewerten zu können. Da dafür erste Umsetzungsansätze wie eine oberflächliche Softwarearchitektur und ein erster Entwurf erforderlich sind, steht diese Aktivität in gewisser Weise »zwischen« Anforderungen und Entwurf, hat aber Auswirkungen auf und Rückkopplungen zu beiden Bereichen.
Folgerichtig findet sich in Kapitel 7 der Themenbereich des sicheren Entwurfs. Da ca. die Hälfte der Sicherheitsschwachstellen in entwurfsspezifischen Entscheidungen liegen, diese aber sehr hohe Folgekosten verursachen, ist es besonders wichtig, in dieser Phase auf Sicherheit zu achten. Neben Prinzipien, die eine sichere Architektur ausmachen, stellen wir dort auch viele Sicherheitsentwurfsmuster vor, mit denen wiederkehrende Sicherheitsprobleme adressiert werden sollten.
In Kapitel 8 schließt sich die sichere Programmierung an, also der Teil, der sich mit konkreten Angriffen und deren Vermeidung beschäftigt. Dort werden Angriffe beschrieben, klassifiziert und Gegenmaßnahmen vorgestellt. Es wurde bewusst auf eine möglichst einfache und nicht technische Darstellung Wert gelegt, Bücher für sichere Programmierung gibt es viele und bessere.
Kapitel 9 beschäftigt sich mit dem Testen von Sicherheit. Wir beschreiben, wie Testfälle erzeugt werden, welche Methoden eingesetzt werden können, um Sicherheitstests durchführen zu können, und welche besonderen Schwierigkeiten dabei bestehen.
Mit der Entwicklung und dem Testen ist die Software noch nicht beim Kunden angekommen und auch auf diesen letzten Metern kann sicherheitstechnisch noch alles schiefgehen. Daher widmet sich Kapitel 10 der sicheren Einrichtung von Software, unter anderem, wie man Software sicher zum Kunden bringt, aber auch, wie man Software sicher konfiguriert und die initiale Versorgung mit Daten vornimmt.
Es gibt keine Software, die keine Fehler enthält. Genauso ist es auch mit Sicherheit. Selbst wenn Sie alles, was Sie bis hierher gelesen haben, umgesetzt haben, so kann es doch passieren – und es wird passieren –, dass in Ihrer Software eine Schwachstelle identifiziert wird. Daher beschäftigt sich Kapitel 11 mit Sicherheit im Supportprozess, der sogenannten Security Response. Dort wird erläutert, wie auf gefundene Schwachstellen reagiert werden sollte, wie man die Lösung von Schwachstellen koordiniert und wie man über Schwachstellen verantwortungsvoll kommuniziert.
Kein Prozess wird besser, wenn er nicht untersucht, verglichen und beobachtet wird – das geht nur über Messungen, um objektive Zahlen statt Bauchgefühl für die weitere Entwicklung verwenden zu können. Kapitel 12 enthält den Themenbereich Metriken für sichere Software. Welche Metriken es gibt, wie man selbst welche entwickeln kann und wie man mit Metriken umgeht, wird in diesem Kapitel erläutert.
Alle diese Maßnahmen sind vergeblich, wenn Sie innerhalb des Entwicklungsprozesses einen Innentäter haben, der Hintertüren einbauen kann, Kunden im Support ausspäht usw. Daher widmet sich Kapitel 13 dem Schutz des Codes selbst. Der Vollständigkeit halber haben wir auch Schutzmaßnahmen gegen Diebstahl von Code und Lizenzierungsmechanismen mit aufgenommen.
Diese inhaltlichen Kapitel werden ergänzt um ein Kapitel, in dem Sie Testfragen inklusive Antworten finden, um Ihr Wissen überprüfen zu können, und ein Kapitel zu weiterführender Literatur. Die Testfragen sind genau so aufgebaut wie die Prüfungsfragen vom ISSECO CPSSE (siehe Abschnitt 1.3.2) und sollten Ihnen daher ermöglichen, sich inhaltlich auf die Prüfung vorzubereiten – idealerweise begleitend zu einer Schulung eines ISSECO-akkreditierten Schulungsanbieters.
Begleitet werden die Inhalte von Ben, einem Softwareprojektmanager, und seinem Team, die in so manches Fettnäpfchen treten, bevor sie es im Rahmen ihres Projekts dann doch ganz gut hinbekommen, und einem Hacker Jewgeni, ihrem unbemerkten Gegenspieler, der die entwickelte Anwendung für seine eigenen Zwecke ziemlich erfolgreich missbraucht. Sie finden am Anfang und am Ende eines jeden Kapitels jeweils eine kurze Beschreibung des Istzustandes (also wie es heute meistens ist, aber eben nicht sein sollte) und des Sollzustandes (wie es idealerweise laufen könnte).
Wer sollte dieses Buch lesen? Nun, vordergründig jeder, der mit sicherer Softwareentwicklung zu tun hat. Es ist aber ein Lehrbuch über die Grundlagen der sicheren Softwareentwicklung und daher werden natürlich nur die wichtigsten Themen im Detail erläutert. Themen, die aufgrund der Anwendbarkeit im gesamten Entwicklungsprozess von Bedeutung sind, werden im gebotenen Detail beschrieben, wie z. B. die Bewertungsmechanismen von Schwachstellen. Andere Themen, speziell technischer Natur, sind bewusst schmal gehalten.
Das Buch wendet sich daher primär an Entwicklungsverantwortliche, die die Aufgabe bekommen haben (oder entdeckt haben, was mich freuen würde), Sicherheit in den Entwicklungsprozess zu integrieren. Dazu zählen aber auch Qualitätsmanager, Architekten, Testverantwortliche, Requirements Engineer und Supportverantwortliche, die sich nun mit der Thematik Sicherheit auseinandersetzen wollen oder müssen. Natürlich würden auch Programmierer von der breiten Darstellung von Sicherheitsmaßnahmen im Entwicklungsprozess profitieren, aber erfahrungsgemäß interessieren sie sich dann doch eher für die reinen programmierrelevanten Themen und Tipps (sorry, Jungs, ich habe zu lange mit Euch zusammengearbeitet).
Und natürlich ist die kommende Generation der IT-Experten eine große Zielgruppe, von der ich hoffe, dass sie das Thema Sicherheit anders wahrnimmt als die meisten in meiner Generation. Daher richtet sich das Buch an die vielen Studenten, die wissen wollen, wie man sichere Software entwickeln kann – und die Dozenten, die dieses Wissen ihren Studenten vermitteln wollen.
Die Inhalte dieses Buches sind gemeinsam mit den Kollegen von ISSECO entstanden. ISSECO ist ein Verein zur Förderung sicherer Softwareentwicklung (International Secure Software Engineering Council, www.isseco.org), die Mitgliedschaft ist kostenlos, jeder mit berechtigtem, nicht kommerziellem Interesse kann mitarbeiten.
Das Ziel des Vereins ist die Förderung von sicherer Softwareentwicklung. Denn nur durch bessere, sicherere Software kann die für die heutigen und zukünftigen Anwendungen von Informationstechnologie erforderliche Sicherheit gewährleistet werden. Zusätzliche Schutzmechanismen sind heute und werden auch morgen immer nur ein nicht optimal passendes Schutznetz darstellen, niemals aber die Sicherheit an sich gewährleisten können. Im Gegensatz zu OWASP (Open Web Application Security Project), diese Organisation wird in der Folge im Detail dargestellt werden, liegt der Fokus nicht auf einer möglichst breiten Versorgung der Entwicklergemeinde mit Werkzeugen und Information, sondern auf der Sensibilisierung von Entscheidern, dass Sicherheit durchgängig im Entwicklungsprozess verankert werden muss.
Entsprechend ist die Hauptaktivität des Vereins, dafür passende Schulungsinhalte zusammenzustellen. Schulungsanbieter können sich akkreditieren lassen und dann die von ISSECO bereitgestellten Inhalte als Schulungen anbieten. Zu den Schulungen gibt es auch ein Zertifikat, das man nach erfolgreich abgelegter Prüfung durch das iSQI (International Software Quality Institute) erlangen kann. Das Zertifikat heißt »Certified Professional for Secure Software Engineering« (CPSSE). Im Sinne der ISO 17024 bildet damit der geschäftsführende Vorstand des Vereins das »Board« der Zertifizierung.
Die Inhalte dieses Buches sind so ausgelegt, dass damit die CPSSE-Prüfung bestanden werden kann, auch wenn in einigen Bereichen der Stoff dieses Buches über die für die Prüfung erforderlichen Lerninhalte hinausgeht. Das vorliegende Buch bildet damit eine Grundlage für die Prüfungsvorbereitung für alle, die die CPSSE-Prüfung nach iSQI ablegen wollen. Die CPSSE-Prüfung kann auch als ein Baustein des QAMP-Zertifikats (Quality Assurance Management Professional) eingebracht werden und ist somit in das Qualifizierungsangebot von iSQI eingebunden. Die Inhalte dieses Buches sind zur Struktur der Kapitel des Syllabus der CPSSE-Prüfung fast identisch, nur in einem einzigen Punkt wird in diesem Buch von der Struktur des Syllabus abgewichen: Aus didaktischen Gründen wurden in diesem Buch die Kapitel »Sicht des Kunden« (View of the Customer) und »Sicht des Angreifers« (View of the Attacker) getauscht.
Die aktuell verfügbaren Inhalte sind auf ein Basiswissen ausgelegt, das für die Aufgabe als Verantwortlicher für sichere Softwareentwicklung erforderlich ist – daher auch der Name des Buches. Weitere Module für eine Höherqualifizierung sind angedacht, so z. B. speziell für bestimmte Themen, etwa die Bedrohungsmodellierung (»Threat Modeling«) oder Security Response, architekturell für bestimmte Designbereiche, wie z. B. Identitätsmanagement oder die Sitzungsverwaltung, oder für bestimmte Programmiersprachen mit Fokus auf sicherer Entwicklung. In diesem Sinne stellt die aktuelle CPSSE-Version eine Art Foundation Level dar.
Die Prüfung zum CPSSE ist weltweit verfügbar. Zurzeit gibt es zwar fast ausschließlich Schulungsanbieter aus Mitteleuropa, aber durch die PC-basierte Prüfung von Pearson Vue kann die Prüfung weltweit in jeder größeren Stadt abgelegt werden. Suchen Sie auf der Webseite von Pearson Vue (www.pearsonvue.com) nach einem Prüfungsort für iSQI-Prüfungen! Konsequenterweise sind die Inhalte für die Prüfung international ausgelegt und daher komplett auf Englisch erstellt.
Es gibt bisher nur eine vergleichbare Zertifizierung, nämlich die zum »Certified Software Security Lifecycle Professional« (CSSLP) von (ISC)2 – International Information Systems Security Certification Consortium. Inhaltlich sind sich die Prüfungen sehr ähnlich, wobei der CSSLP sich aufgrund seiner Provenienz stärker an Sicherheitsexperten richtet, die Kompetenz im Entwicklungsbereich übernehmen wollen, und natürlich in den USA stark verbreitet ist. Dies erklärt auch, warum der CSSLP fast ausschließlich Fragen zum amerikanischen Rechtsraum beinhaltet. In der Community der Softwareentwickler ist dieses Zertifikat aufgrund der fehlenden Affinität zu allgemeiner Softwarequalität so gut wie gar nicht bekannt. Damit stellt der CPSSE sowohl für die Entwicklergemeinde als auch mit seiner internationaleren Ausrichtung eine interessante Alternative dar.
Wenn man manchmal nur wüsste, was Kunden wirklich wollen ... Im Ernst: Die meisten Kunden wissen nicht genau, was sie im Hinblick auf Sicherheit wollen. In diesem Kapitel wird erläutert, wie man sich dieser Perspektive nähern kann, womit man rechnen muss, und wie man von pauschalen Antworten eines Kunden zu konkreten technischen Anforderungen für ein Softwareprojekt kommt. Zudem stellen wir ein Beispielprojekt vor, das wir im Laufe des Buches begleiten werden.
Ben arbeitet bei einer Softwareprojektentwicklungscompany. Seine Firma hat zwar über 200 Angestellte, diese arbeiten aber alle an kleinen, kundenspezifischen Entwicklungsprojekten in kleinen, individuellen Teams von maximal 10 Leuten, die immer wieder neu zusammengestellt werden. Das Besondere an dem Business-Modell der Firma von Ben ist, dass sie zwar nur auf Kundenauftrag entwickeln, wohl aber eine gewisse Supportdienstleistung anbieten, d. h., sie sichern zu, Korrekturen zeitnah liefern zu können. Die Preiskalkulation ist dementsprechend so, dass die Entwicklungstage recht knapp kalkuliert werden (also günstig sind) und am Supportvertrag dann verdient werden kann. Die Verantwortung für die Supporttätigkeiten liegt bei dem jeweiligen Projektleiter, und da diese an den Supporteinnahmen beteiligt werden, stößt dieses Modell bei ihnen auch auf Gegenliebe. Die Entwickler selbst, die pro Projekt aufgrund ihrer Skills hinzugezogen werden, haben deutlich weniger Interesse, aber sie helfen natürlich – wenn auch murrend –, die von ihnen eingebauten Fehler zu entfernen.
Ben hat nun einen Auftrag akquiriert, und zwar die Entwicklung eines Multi-Client-Frontends zur Selbstverwaltung von Versicherungsverträgen. Multi-Client bedeutet, dass die Funktionalität sowohl im Browser, also von jedem internetfähigen PC aus, als auch von verschiedenen Mobilgeräteplattformen (iPhone, iPad, Android, Windows Mobile) verwendet werden kann. Kunden sollen über diese Anwendung die Möglichkeit bekommen, Vertragsdaten einzusehen, Parameter des Vertrags zu ändern, und gegebenenfalls sogar – Einwilligung vorausgesetzt – auch neue Verträge abzuschließen. Zudem soll es möglich sein, Schadensmeldungen einzugeben, etwa einen Autounfall für die Haftpflichtversicherung, idealerweise mit Bild und Ortsangabe.
Ben freut sich sehr, denn er hat schon mehrere Multi-Client-App-Projekte geleitet, und zwar im Gaming-Umfeld für Werbezwecke, und kann nun sein Wissen in diesem Bereich für die neuen Anwendungsszenarien einsetzen. Er stellt sein Team recht aggressiv zusammen, also überwiegend Coding-Spezialisten, um relativ zügig auch etwas zeigen zu können.
Der Termin mit dem Kunden war auch erfreulich kurz. Nach der telefonischen Zusage hat eine Stunde gereicht, um mit dem Kunden die erforderlichen Szenarien durchzusprechen. Sobald er wieder im Büro war, machte er sich an eine Architekturskizze. »Bis Tom«, sein Hauptentwickler, der üblicherweise lange am Entwurf sitzt, bevor er damit zufrieden ist, »sich damit vertraut gemacht hat, habe ich die fertig«, denkt er sich und präsentiert am nächsten Morgen den Entwurf seinem Team, wobei er gleich die Mitarbeiter auf die verschiedenen Pakete verteilt. »Super«, denkt er, »endlich mal ein schnelles, schönes, einfaches Projekt.«
Eigentlich könnte alles ganz einfach sein: Die Hersteller entwickeln gute Software, die den Anforderungen genügt, und die Kunden sind zufrieden. Hin und wieder gibt es einen Technologie- und Innovationssprung, und die Kunden schaffen sich neue Software oder Services an. Sicherheitsprobleme gibt es nicht, da bei der Entwicklung alle erforderlichen Aspekte für den Betrieb bedacht werden.
Doch leider ist die Welt nicht perfekt. In einer Zeit, in der jeder Marktteilnehmer versucht, für sich das meiste Geld für die wenigste Leistung herauszuholen, um den Gewinn zu maximieren, muss man Abstriche machen. Als Hersteller muss man damit verschiedenen Herren dienen. Ist man eine Aktiengesellschaft und vielleicht sogar börsennotiert, so muss man vorrangig auf die Geschäftszahlen achten, und die ständige Gewinnmaximierung ist eine immer präsente Priorität. Aber auch wenn nur der direkte Konkurrent diesem Druck unterliegt, sieht man sich schnell genötigt, selbst die gleichen Anforderungen in Bezug auf Marktsichtbarkeit, neue Features oder Image zu erfüllen. Die Kundenzufriedenheit kann dabei durchaus auf der Strecke bleiben.
Zudem ist es ein Gesetz des Marktes, dass vollständige, fertige Produkte nicht optimal sind, denn sie lassen keinen Spielraum für Erweiterungen, Verbesserungen oder Innovationen. Die erfolgreichsten Produkte sind die, die Kundenbedürfnisse fast erfüllen, aber eben nicht ganz. Das trifft – komischerweise – auch für den Sicherheitsaspekt zu. Man sollte denken, dass mangelnde Sicherheit ein K.-O.-Kriterium ist, aber weit gefehlt! Der Mensch ist risikobereit und ist es gewohnt, Nachteile und auch Risiken in Kauf zu nehmen, um bestimmte Vorteile zu bekommen. Also ist auch mangelnde Sicherheit »nur« einer von verschiedenen möglichen Nachteilen, die der Hersteller abwägen kann.
Der Hersteller ist aber nicht nur dem Kunden oder den Eignern verpflichtet. Gerade, wenn es um Sicherheit geht, gibt es weitere Interessengruppen:
Die öffentliche Hand, Regierungen oder Ämter fordern die Befolgung von Gesetzen, dies trifft natürlich auch die Softwareindustrie, und zwar nicht nur beim Herstellungs- und Vertriebsprozess, sondern auch und gerade in Bezug auf die Möglichkeiten der Produkte. Ein wichtiger Bereich ist der des Datenschutzes, dabei geht es nicht um die technische Sicherheit (die dafür auch erforderlich ist), sondern vorrangig um den Schutz von Persönlichkeitsrechten, speziell um das Recht der informationellen Selbstbestimmung. Zumindest ist dies in Europa der Fall, in anderen Regionen der Welt wird dies kulturell und damit auch rechtlich durchaus anders gesehen. Auch Exportvorgaben, korrekte Rechnungslegung oder Umweltfreundlichkeit haben Auswirkungen auf die Anforderungen an ein Softwareprodukt. Zwar ist – anders als beim klassischen Produktsicherheitsgesetz – der, der die Software einsetzt, verantwortlich, doch indirekt wirkt sich das auch auf den Hersteller aus – auch ein Beispiel, wo der Kunde eigentlich nicht genau weiß, was er an Sicherheit möchte.
Banken und Versicherungen