Basiswissen Sichere Software E-Book

Sachar Paulus

• Herausgeber: dpunkt
• Kategorie: Wissenschaft und neue Technologien
• Serie: iSQI-Reihe
• Sprache: Deutsch
• Veröffentlichungsjahr: 2012

Seitenzahl: 419

Beschreibung

Sichere Software zeichnet sich dadurch aus, dass sie jedem möglichen Angriff standhalten können muss. Jeder Beteiligte im Softwareentwicklungsprozess sollte bewusst auf die Schaffung dieser Eigenschaft einer Software hinarbeiten. Dieses Buch vermittelt, welche Aspekte dabei zu berücksichtigen sind und zeigt für alle wichtigen Bereiche der Softwareentwicklung auf, was jeweils für Sicherheit getan werden kann - und muss. Es deckt den Lehrplan zum Certified Professional for Secure Software Engineering nach ISSECO-Standard ab, eignet sich zum Selbststudium und als Begleitliteratur zu Schulungen.

Leseprobe

BasiswissenSichere 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.

BasiswissenSichere Software

Aus- und Weiterbildung zum ISSECO CertifiedProfessional for Secure Software Engineering

Sachar Paulus

Sachar [email protected]

Lektorat: Christa PreisendanzCopy-Editing: Ursula Zimpfer, HerrenbergHerstellung: Nadine ThieleUmschlaggestaltung: Helmut Kraus, www.exclam.deDruck und Bindung: M.P. Media-Print Informationstechnologie GmbH, 33100 Paderborn

Bibliografische Information der Deutschen NationalbibliothekDie 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-7PDF 978-3-86491-052-4ePub 978-3-86491-053-1

1. Auflage 20011Copyright © 2011 dpunkt.verlag GmbHRingstraße 19 B69115 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

Geleitwort von Stephan Goericke

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.

Sicherheit ist Softwarequalität.

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 GoerickeDirector iSQI GmbH

Geleitwort von Jörg Brinkmann

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 BrinkmannCIO Bilfinger Berger SE

Vorwort

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 PaulusNeckargemünd, im Mai 2011

Inhaltsverzeichnis

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

1     Einleitung

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.

1.1     Ziele dieses Buches

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.

1.1.1     Warum brauchen wir sichere Software?

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.

1.1.2     Warum wird Sicherheit bei Softwareentwicklung oft vernachlässigt?

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.

1.1.3     Was sind die Folgen von ausgelieferter unsicherer Software?

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.

1.2     Inhalte dieses Buches

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).

Zielgruppe dieses Buches

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.

1.3     ISSECO und die CPSSE-Zertifizierung

1.3.1     ISSECO

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.

1.3.2     Certified Professional for Secure Software Engineering (CPSSE)

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.

2     Die Sicht des Kunden

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.

2.1     Ben und sein Projektteam

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.«

2.2     Verschiedene Interessengruppen – verschiedene Interessen

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, die ihre Kunden wiederum mit Krediten versorgen, sind interessiert daran, dass die Kunden selbst keinem hohen Risiko ausgesetzt sind, damit die vergebenen Kredite nicht platzen. In der Folge sind auch die Banken indirekt daran interessiert, dass die Kunden keine unsichere Software einsetzen. Nach Basel II, einer Reihe von Eigenkapitalrichtlinien, sind Kreditzinsen abhängig vom Risiko zu vergeben, dazu zählen auch die operationalen Risiken, unter denen sich die Informationssicherheitsrisiken und darunter wiederum die Softwaresicherheitsrisiken finden. Aber auch für ihren eigenen Betrieb spielt die Sicherheit von Software eine große, bedeutsame Rolle. Banken, traditionell ein eher IT-naher Wirtschaftszweig, können ihre Sicherheitsanforderungen aber oft recht gut spezifizieren – was nicht immer heißt, dass sie diese auch einfordern oder durchsetzen können.

Wirtschaftsprüfer schauen in erster Linie nach einer korrekten Buchführung und bestätigen die Korrektheit von Jahresabschluss und Bilanz. Als Teil dessen schauen sie aber auch den Umgang mit operationalen IT-Risiken an, da diese die Korrektheit und Gültigkeit der Zahlen, die für den Jahresabschluss herangezogen werden, erheblich beeinflussen können. Wenn aber natürlich die Software leicht zu manipulieren ist, was ist dann das Testat des Wirtschaftsprüfers wert? Entsprechend ist der Wirtschaftsprüfer vorrangig an der Nicht-Manipulierbarkeit der Software interessiert.

Neben den Kunden, die meist Unternehmen oder andere Organisationen sind, gibt es auch die Benutzer, die Anforderungen an die Sicherheit stellen. Im zentralen Interesse der Benutzer stehen persönliche oder personenbezogene Informationen, und diese sollen vor unlauterem Missbrauch geschützt werden. Sie wollen also, dass ihre Informationen nicht ausgelesen, abgehört oder anders als eigentlich gedacht genutzt werden (z. B. dass Arbeitszeiten aus den Login-Daten ermittelt werden oder Profilinformationen durch Analyse der Kontakte und besuchten Webseiten erstellt werden) oder dass ihr Account nicht »geklaut« wird.

In der Organisation der Kunden gibt es auch noch Führungskräfte, die unter Umständen wieder ein anderes Interesse haben. Neben der Rolle des normalen Benutzers haben Manager oft zusätzlich die Anforderung, dass die verarbeiteten Informationen vertraulich behandelt werden, denn gegebenenfalls handelt es sich doch um Informationen, die eine andere Interessengruppe (z. B. Auditoren, Banken oder Mitarbeiter) nicht oder zumindest noch nicht sehen sollten. Zudem treffen Führungskräfte in der Regel Entscheidungen auf der Basis von Informationen, die in IT-Systemen verarbeitet werden, und diese müssen natürlich korrekt, also integer, sein.

Der Softwaremarkt, in diesem Fall ist damit die Gesamtheit der öffentlich aktiven Akteure gemeint, unter Einbezug von Herstellern, Kunden, Expertengruppen, aber auch Presse, Fachjournalisten und Wissenschaft, ist an Schwachstellen sehr interessiert. In diesem Fall steht also nicht die Sicherheit im positiven Sinn im Vordergrund – denn dann ist das sozusagen langweilig und kein Mensch interessiert sich dafür –, sondern die Schwachstellen in der Software als Ware. Diese Ware ist von hohem Aufmerksamkeitsinteresse, auch wenn nur wenige Kunden infolge eklatanter Sicherheitsprobleme den Anbieter wechseln.

Überhaupt ist die Wahrnehmung von Sicherheit eine sehr eigene Domäne. Solange nichts passiert, was die Aufmerksamkeit der Massen auf sich zieht, ist mangelnde Sicherheit von geringem Interesse. Zwei Beispiele: Kernkraftwerke sind durch den Unfall in Fukushima nicht schlechter oder unsicherer geworden, aber die öffentliche Wahrnehmung der sich nun realisierenden Schäden führt zu einer veränderten Einstellung dazu, ob das Restrisiko getragen werden kann. Auf der anderen Seite ist rein statistisch der gefährlichste Ort in Deutschland das Auto, die meisten Unfälle mit Todesfolge passieren im Straßenverkehr. Aber da dort die Wahrnehmung der Schäden sozusagen unterschwellig bleibt, sind die meisten Menschen der Meinung, dass Auto fahren ein vertretbares Risiko ist. (Nur dass kein falscher Eindruck entsteht: Ich bin gegen Atomkraft – weil wir nicht in der Lage sind, die Konsequenzen der Nutzung schadlos tragen zu können – und für Auto fahren – weil kein anderes Mobilitätskonzept Individualität und Geschwindigkeit so gut vereint –, es geht mir um das Deutlichmachen der Problematik der Wahrnehmung.)

Das ist bei Software und allgemeiner bei Informationssicherheit noch schwieriger. Denn dort geht es in der Regel um immaterielle Güter, wo es schon schwierig genug ist, den Wert dieser Güter zu bestimmen, und noch schwieriger zu verstehen ist, wie Informationen gestohlen werden können, obwohl sie ja noch da sind. Für die meisten Menschen ist es eben nicht gut nachvollziehbar, dass nicht die Information an sich einen Wert darstellt, sondern stattdessen:

die Verfügbarkeit von Information, also die Tatsache, dass sie für verschiedene Zielgruppen zugänglich ist,

die Vertraulichkeit von Information, also die Tatsache, dass sie nur bestimmten Zielgruppen (im Extremfall nur mir selbst) zugänglich ist, und damit für diese einen Informationsvorsprung darstellt,

die Integrität von Information, also die Tatsache, dass die Informationen korrekt sind und weder bewusst noch unbewusst verändert oder verfälscht wurden.

Auch für die Softwaresicherheit sind dies die drei wichtigsten Ziele, jedoch hängt es von der Interessengruppe ab, welche Eigenschaft von welchen Informationen gerade interessant ist. Während z. B. für einen Mitarbeiter die Vertraulichkeit der Anmeldezeiten interessant ist, ist für einen Manager vielleicht gerade die Integrität der Anmeldezeiten wichtig. Es ist also bei dem gesamten Prozess der Softwareentwicklung zu beachten, dass es immer unterschiedliche Anforderungen von den verschiedenen Interessengruppen gibt, und auch wenn wir uns in der Folge vereinfacht »nur« mit DEM Kunden beschäftigen, so gibt es zum einen weitere, wichtige Anforderer und zum anderen ist auch DER Kunde in der Praxis eher mehrschichtig und selten eindimensional.

Anforderer für Sicherheit

Es gibt viele verschiedene Anforderer für Sicherheitseigenschaften. Auch beim Kunden selbst gibt es in der Regel mehr als eine Interessengruppe. Dies kann auch zu Konflikten führen, das sollten Sie immer im Hinterkopf haben.

Und so kann es durchaus zu Widersprüchen und Konflikten kommen und nicht selten werden diese erst aufgedeckt, wenn der Hersteller die Anforderungsanalyse strukturiert durchführt, denn bis dahin wurden die verschiedenen Sicherheitsanforderungen oft noch gar nicht thematisiert.

2.3     Warum erwarten Kunden sichere Software?

Kunden, und das ist interessanterweise völlig unabhängig von der Branche oder der Größe der Organisation, haben immer Erwartungen an die Sicherheit von Software. Das ist wie bei einem Autokauf: Jeder hat Erwartungen daran, wie sicher ein Auto ist. Im Prinzip ist das etwas Gutes, denn das bedeutet, dass dem Kunden die Sicherheit durchaus wichtig, und eben nicht egal ist (wobei der Vergleich nicht ganz richtig ist, da es beim Auto gesetzliche Mindestanforderungen gibt, die zu beachten sind).

Das Problem ist, dass diese Annahmen in der Regel implizit sind, also nicht aktiv artikuliert werden. Und dabei spielt es keine Rolle, ob es sich bei der entwickelten Software um Verbrauchersoftware für die Fotobearbeitung, IndustrieSteuerungssoftware oder betriebswirtschaftliche Software handelt.

Ein sehr interessanter psychologischer – und soziologischer – Aspekt ist, dass Kunden keine (impliziten) Annahmen darüber machen, was die Software und Sicherheitsfunktionen im Allgemeinen haben sollte, also z. B. in Bezug zu den Funktionalitäten und dem Hauptanwendungszweck, sondern dass diese Erwartung sehr stark personalisiert wird. Damit ist gemeint, dass Kunden die Schutzfunktionen eines Gegenstands (nicht nur auf Software bezogen) auf die ganz individuelle Nutzung beziehen.

Bei einem Smartphone zum Beispiel gibt es sehr unterschiedliche Nutzungsszenarien. Die einen nutzen hauptsächlich den Internetzugang, andere wiederum die Kalender- und E-Mail-Funktion, und wieder andere vielleicht die Möglichkeit, eigene Apps auf dem Gerät zu installieren. Nun machen sich aber nicht alle Gedanken um die Sicherheit des Smartphones an sich, sondern ganz konkret um den Schutz der Daten, wie sie jeweils genutzt werden, was ja ganz natürlich ist. In diesem einfachen Beispiel ist das leicht nachvollziehbar, aber genauso ist es auch bei komplexer Software.

Dass die Erwartungen die individuelle Nutzung betreffen, macht die Aufnahme der Anforderungen etwas leichter, da aber die Erwartungen in den meisten Fällen wie bereits erwähnt eher implizit vorhanden sind, ist das Ermitteln der Anforderungen nun doch nicht so einfach. Im Beispiel des Smartphones etwa könnten die impliziten Erwartungen etwa so lauten:

Der Surfer erwartet, dass er unbeobachtet surfen kann.

Der Organisierte erwartet, dass mit Kalender und E-Mail nichts passieren kann.

Der Programmierer erwartet, dass seine Apps nicht geklaut werden.

Alle diese Anforderungen sind eher ungenau und unpräzise und nicht gut geeignet (die erste vielleicht noch), um sie einem späteren Test zuführen zu können. Zudem könnten die Anforderungen sich ja auch widersprechen, z. B.: »Ich will, dass meine E-Mails überall verfügbar sind« (Mitglied der Geschäftsleitung) vs. »Ich will, dass firmenvertrauliche E-Mails im Firmennetz bleiben« (Sicherheitsverantwortlicher). Schon bei der Übertragung dieser Erwartungen in konkrete Anforderungen stellen sich Schwierigkeiten ein.

Das größte Problem aber ist, dass der Kunde selten über diese Erwartungen spricht. Wenn es sich um Verbrauchergüter oder -software handelt, dann kann sich das Produktmanagement gegebenenfalls noch am eigenen Beispiel überlegen, wie die Erwartungen sein könnten. Aber bei kundenspezifischen Entwicklungen ist es hochgradig kritisch, wenn die Kunden ihre impliziten Sicherheitserwartungen nicht artikulieren. Das heißt aber, dass der Hersteller in der Pflicht ist, die Sicherheitsanforderungen aktiv aus dem Kunden »herauszuholen«. Dazu ist es notwendig, mit dem Kunden über die Anwendung der geplanten Software zu reden. Das ist bei projektspezifischer Software normalerweise sowieso gegeben, da sich aus der neuen Anwendung die Anforderung an die Software ergibt, bei Standardsoftware ist das aber schon etwas schwieriger und bei Software as a Service (SaaS) ist noch unklarer, wie man an diesen Input kommt.

Kunden haben implizite Erwartungen

Sie müssen sich aktiv mit dem Kunden auseinandersetzen, um die implizit vorhandenen Sicherheitsanforderungen bestimmen zu können. Dabei sollten Sie sich dem Anwendungsszenario des Kunden widmen, denn dort kann er Aussagen über seinen Schutzbedarf machen. Daraus können Sie dann die Anforderungen für Ihre Software ableiten.

2.4     Was genau erwarten Kunden eigentlich?

2.4.1     Häufig wiederkehrende Anforderungen

Wenn die Erwartungen von den Einsatzszenarien abhängen, dann ist es natürlich nicht möglich, diese Erwartungen kundenunabhängig zu beschreiben. Es gibt aber eine Reihe von Anforderungen, die fast immer gültig sind, da sie sozusagen inhärent durch die Verwendung von Software entstehen:

Vertraulichkeit von personenbezogenen Daten:Da bei der Verwendung von Software durch Personen fast immer Daten über diese Personen gesammelt werden, und sei es nur die Historie der verwendeten Befehle, entstehen automatisch personenbezogene Daten, die nach den Vorgaben der verschiedenen Datenschutzgesetze geschützt werden müssen. Aber auch ohne Gesetz haben Anwender die Anforderung des Schutzes dieser Daten, und Anwender können sich durch die Beachtung dieser Erwartungen differenzieren. Es gibt Fälle, wo gerade diese Profilierung Sinn und Zweck einer Software ist (z. B. Facebook), dazu sollte aber immer zumindest die explizite Erlaubnis des Dateneigners eingeholt werden.

Vertraulichkeit von Firmengeheimnissen:Obgleich es schwierig ist, die Vertraulichkeit von firmeninternen Informationen einschätzen zu können – also z. B. was ist wirklich ein wertvolles Firmengeheimnis, oft werden zu viele Informationen als solche angesehen (aber besser so als umgekehrt) –, so ist es enorm wichtig in der heutigen Zeit, diese Informationen geeignet zu schützen. Es sollte inzwischen allgemein bekannt sein, dass andere Staaten aktive Wirtschaftsspionage betreiben und dafür elektronische Medien sehr erfolgreich einsetzen, bis hin zu trojanischen Pferden und speziellen Spähviren.

Verfügbarkeit und Integrität der Informationen, die in der Software verarbeitet werden:Wenn die Informationen nicht zur Verfügung stehen und unverfälscht sind, dann ist die Software sozusagen nutzlos, da auf der Basis der Arbeit, die die Software geleistet hat, keine weiteren Entscheidungen getroffen werden können.

Verfügbarkeit und Integrität des Systems, auf dem die Software läuft:Bedingung für die Verfügbarkeit der Informationen ist nicht nur, dass die Software selbst störungsfrei und unmanipuliert funktioniert, sondern auch, dass die Plattform, auf der diese Software läuft, den gleichen Bedingungen genügt.

Berechtigungen und Zugriffsschutz zur Abwehr von Insider-Angriffen:Selbst wenn niemand die Software von außen angreift, so gibt es dennoch eine große Gefahr von innen: Ca. 65% der Angriffe auf IT-Systeme zum Ausspähen oder Manipulieren von Daten kommen laut gängiger Meinung von Experten von innen, werden also durch Innentäter, denen man vertraut, ausgeführt. Da diese Innentäter in der Regel schon Benutzer sind und Rechte in der Software haben, lässt sich der Schaden durch Innentäter nur dadurch eindämmen, indem weitere Zugriffsmöglichkeiten eingeschränkt werden.

Robustheit des Systems gegen Angriffe von außen:Grundsätzlich sollte ein Softwaresystem so gebaut sein, dass ein störungsfreier Betrieb auch dann möglich ist, wenn das System von außen, also nicht durch Innentäter, angegriffen wird. Zu dieser Robustheit gehören die Möglichkeiten, Angriffe zu erkennen, Angriffe abzublocken und gegebenenfalls das System sicher herunterzufahren, sollte zu viel Schaden durch einen Angriff von außen drohen.

Diese generischen Schutzziele für eine Software treten in der überwiegenden Anzahl von Fällen auf und sind damit ein erster Schritt für eine Anforderungsanalyse für die erwarteten Sicherheitseigenschaften. Die damit verbundenen Anforderungen bestehen aus funktionalen und nicht funktionalen Elementen, wie wir in Kapitel 5 sehen werden.

2.4.2     Eine Klassifikation der Sicherheitserwartungen an Produkte

Wie in Abschnitt 2.3