Basiswissen Sichere Software

Aus- und Weiterbildung zum ISSECO Certified Professionell for Secure Software Engineering

Autor	Sachar Paulus
Verlag	dpunkt
Erscheinungsjahr	2012
Reihe	Basiswissen
Seitenanzahl	286 Seiten
ISBN	9783864910524
Format	PDF/ePUB
Kopierschutz	Wasserzeichen/DRM
Geräte	PC/MAC/eReader/Tablet
Preis	31,99 EUR

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.

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 'TeleTrusT'. Weiter war er Mitglied der ständigen Interessenvertretung der ENISA (Europäische Netzwerk- und Informationssicherheitsagentur) 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.

Kaufen Sie hier:

Horizontale Tabs

Blick ins Buch

Inhaltsverzeichnis

Geleitwort von Stephan Goericke	6
Geleitwort von Jörg Brinkmann	8
Vorwort	10
Inhaltsverzeichnis	12
1 Einleitung	16
1.1 Ziele dieses Buches	16
1.1.1 Warum brauchen wir sichere Software?	18
1.1.2 Warum wird Sicherheit bei Softwareentwicklung oft vernachlässigt?	19
1.1.3 Was sind die Folgen von ausgelieferter unsicherer Software?	20
1.2 Inhalte dieses Buches	22
1.3 ISSECO und die CPSSE-Zertifizierung	25
1.3.1 ISSECO	25
1.3.2 Certified Professional for Secure Software Engineering (CPSSE)	26
2 Die Sicht des Kunden	28
2.1 Ben und sein Projektteam	28
2.2 Verschiedene Interessengruppen - verschiedene Interessen	29
2.3 Warum erwarten Kunden sichere Software?	32
2.4 Was genau erwarten Kunden eigentlich?	34
2.4.1 Häufig wiederkehrende Anforderungen	34
2.4.2 Eine Klassifikation der Sicherheitserwartungen an Produkte	35
2.4.3 Eine Klassifikation der Sicherheitserwartungen an den Hersteller	37
2.4.4 Compliance-Anforderungen	37
2.5 Werte, Bedrohungen und Risiken	38
2.6 Von Erwartungen zu technischen Anforderungen	40
2.7 Helfen Sie dem Kunden, dann helfen Sie sich selbst!	41
2.8 Ben spricht noch einmal mit dem Kunden	43
3 Die Sicht des Angreifers	44
3.1 Jewgeni	44
3.2 Was sind Hacker?	45
3.2.1 Berühmte Hacker	46
3.2.2 Qualifizierungsstufen von Hackern	48
3.2.3 Motivationen zum Hacken	49
3.3 Wie geht ein Hacker vor?	51
3.3.1 Vorgehensweisen zum Hacken	51
3.3.2 Der Hacking-»Prozess«	54
3.3.3 Welche Werkzeuge setzt ein Hacker ein?	55
3.4 Jewgeni hat eine Idee	58
4 Methodologien für sichere Software	60
4.1 Bens Entwicklungsmethodik	60
4.2 Sichere Software im Überblick	61
4.3 Softwareentwicklungsmethoden	62
4.4 Maßnahmen zur Verbesserung der Sicherheit	65
4.5 Existierende Modelle	69
4.5.1 Common Criteria	69
4.5.2 ISO 27002: Entwicklung von Informationssystemen	72
4.5.3 SSE-CMM	73
4.5.4 BSIMM / OpenSAMM	75
4.5.5 Microsoft SDL	77
4.5.6 OWASP	79
4.5.7 Weitere Ansätze	80
4.5.8 Welcher Weg ist der richtige?	81
4.6 Ben denkt über Sicherheit nach	82
5 Sicherheitsanforderungen	84
5.1 Bens Sicherheitsanforderungen	84
5.2 Was sind Anforderungen?	84
5.2.1 Funktionale und nicht funktionale Anforderungen	86
5.2.2 Wie definiert man gute Anforderungen?	89
5.3 Wie identifiziert man Sicherheitsanforderungen?	90
5.3.1 Grundwerte der Informationssicherheit	90
5.3.2 Misuse Cases	91
5.3.3 Betrachtung des Kontextes	91
5.3.4 Bedrohungsmodellierung	92
5.3.5 Auflösung von Konflikten	92
5.4 Wichtige Sicherheitsanforderungen	93
5.4.1 Standardisierte Sicherheitsanforderungen nach Common Criteria	93
5.4.2 Sicherheitsanforderungen nach OWASP	96
5.4.3 Gesetzliche Anforderungen	97
5.4.4 Bereiche, die für Sicherheitsanforderungen relevant sein können	98
5.5 Bens neue Anforderungsliste	100
6 Bedrohungsmodellierung	102
6.1 Bens Bedrohungsmodellierung	102
6.2 Der Nutzen einer Bedrohungsmodellierung	102
6.3 Die Phasen der Bedrohungsmodellierung	104
6.3.1 Werte und Akteure identifizieren	105
6.3.2 Übersicht der geplanten Architektur erstellen	107
6.3.3 System in Einzelteile herunterbrechen	108
6.3.4 Bedrohungen identifizieren	109
6.3.5 Bedrohungen dokumentieren	119
6.3.6 Bedrohungen bewerten	119
6.3.7 Gegenmaßnahmen planen	124
6.4 Bens zweiter Versuch	126
7 Sicherer Softwareentwurf	128
7.1 Bens Softwareentwurf für Sicherheit	128
7.2 Sicherer Softwareentwurf und sichere Softwarearchitekturen	129
7.3 Secure Design Patterns	131
7.3.1 Föderiertes Identitätsmanagement	132
7.3.2 Authentifizierung	133
7.3.3 Sitzungsverwaltung	136
7.3.4 Verschlüsselung	137
7.3.5 Zugriffskontrollmodelle	138
7.3.6 Privileged Core	141
7.3.7 Single Access Point	142
7.4 Secure Design Principles	142
7.4.1 Least Privilege	143
7.4.2 Secure the Weakest Link	143
7.4.3 Defense in Depth	143
7.4.4 No Security by Obscurity	144
7.4.5 Secure by Default	144
7.4.6 Fail Safe	145
7.4.7 Input Validation und Output Encoding	145
7.4.8 Minimize Attack Surface	145
7.4.9 Don’t Mix Code and Data	146
7.4.10 Wählen Sie Ihre eigenen Prinzipien	146
7.5 Review der Sicherheitsarchitektur	147
7.6 Ben war auf einer Konferenz	148
8 Sicheres Programmieren	150
8.1 Bens Tricks zum sicheren Programmieren	150
8.2 Es gibt keine Tricks	151
8.3 Welche Schwachstellen sind am kritischsten?	151
8.3.1 OWASP Top Ten	153
8.3.2 The 19 Deadly Sins of Software Security	154
8.3.3 The Seven Pernicious Kingdoms	155
8.4 Wiederkehrende Muster von Schwachstellen	157
8.4.1 Unsicherer Umgang mit Eingaben und Ausgaben	157
8.4.2 Unsicherer Umgang mit dem Speicher	158
8.4.3 Unsicherer Umgang mit Wettlaufsituationen	158
8.4.4 Unsicherer Umgang mit Berechtigungen und Ressourcen	158
8.5 Techniken für sicheres Programmieren	159
8.5.1 Input-Validierung und Output-Sanitisierung	159
8.5.2 Sichere Funktionen und Sprachen	161
8.5.3 Atomare Funktionen und sichere Semaphore	162
8.5.4 Minimale Rechte	163
8.6 Die wichtigsten Schwachstellen und Gegenmaßnahmen	164
8.6.1 Cross-Site Scripting	164
8.6.2 SQL-Injection	165
8.6.3 Cross-Site Request Forgery	165
8.6.4 Insecure Direct Object Reference	166
8.6.5 Remote File Inclusion	167
8.7 Werkzeuge zur sicheren Programmierung	167
8.8 Klaus’ Empfehlungen für die sichere Programmierung	168
9 Software auf Sicherheit testen	170
9.1 Bens Sicherheitstest	170
9.2 Sicherheit und Softwaretests	171
9.2.1 Unterschiede zu »normalen« Softwaretests	171
9.2.2 Sicherheitstests in jeder Phase anwenden	172
9.2.3 Integration mit »normalem« Softwaretesten	173
9.2.4 Quellen für Testfälle	174
9.3 Hacking-Techniken als Sicherheitstests	175
9.3.1 Blackbox-Penetrationstests	177
9.3.2 Whitebox-Penetrationstests	178
9.4 Sicherheitsspezifische Testmuster	179
9.4.1 Spidering	179
9.4.2 Googeln	180
9.4.3 Fuzzing	180
9.4.4 Infrastruktur-Check	181
9.4.5 Business-Logik	181
9.5 Sicherheitskritische Testbereiche	182
9.5.1 Authentifizierung	182
9.5.2 Sitzungsverwaltung	182
9.5.3 Input-Validierung	183
9.5.4 Denial of Service	183
9.6 Codereview	184
9.7 Sicherheitstestberichte schreiben	185
9.8 Der Sicherheitstest vom QMB	186
10 Sichere Auslieferung und Einrichtung	188
10.1 Bens Installationsanleitung	188
10.2 Sicherheit im IT-Betrieb	189
10.2.1 Sicherheitsaspekte von ITIL	189
10.2.2 ISO 27001	191
10.2.3 Common Criteria ISO 15408	192
10.2.4 Sicherheitsrelevante Dokumentationen	192
10.3 Phasen der Softwareeinrichtung	194
10.3.1 Sicherheit in der »Release«-Phase	195
10.3.2 Sichere Konfiguration	197
10.3.3 Sicherheit bei der Aktivierung von Software	199
10.3.4 Sicherheit bei Anpassung und Update	200
10.4 Pauls Korrekturen der Installation	202
11 Umgang mit Schwachstellen	204
11.1 Bens Security Response	204
11.2 Sicherheit im normalen Supportprozess	205
11.2.1 Getrennte Behandlung von Sicherheitsproblemen	205
11.2.2 Getrennte Sicherheitskorrekturen	208
11.3 Offenlegungsstrategien für Schwachstellen	209
11.3.1 Full Disclosure	209
11.3.2 No Disclosure	210
11.3.3 Responsible Disclosure	211
11.4 Erfolgreich über Schwachstellen reden	211
11.4.1 Was muss kommuniziert werden?	212
11.4.2 Erfolgskriterien	213
11.5 Standards für Schwachstellenbeschreibungen	214
11.5.1 CVE	215
11.5.2 CVSS	216
11.5.3 CAIF	217
11.6 Entwicklung einer Security Response Policy	219
11.7 Ben und die IT-Presse	220
12 Metriken für Sicherheit	222
12.1 Bens Messgrößen	222
12.2 Warum überhaupt Metriken für Sicherheit?	222
12.3 Softwaremetriken	224
12.4 Arten von Metriken	226
12.5 Qualitätskriterien für Metriken	227
12.6 Existierende Metriken für Sicherheit	229
12.7 Entwicklung von Metriken für Sicherheit	232
12.7.1 Formale Definition einer Metrik für Softwaresicherheit	232
12.7.2 Prozess zur Entwicklung von Metriken für Softwaresicherheit	233
12.7.3 Ein Satz von Metriken für Bens Team	235
13 Codeschutz	236
13.1 Ben und seine eigene IT-Sicherheit	236
13.2 Gründe, den Code zu schützen	236
13.3 Technische Risiken während der Entwicklungsphase	238
13.4 Grundsätzliche Schutzmechanismen	240
13.5 Besondere Anforderungen durch Export und Politik	242
13.6 Technische Lösungen für den Schutz von Code	244
13.6.1 Software as a Service	245
13.6.2 Verwendung von prozessorspezifischem Code	246
13.6.3 Codeverschleierung	247
13.6.4 Verschlüsselung von Code	248
13.6.5 Code Signing	249
13.7 Lizenzschutz	249
13.7.1 Offline-Lizenzmechanismen	250
13.7.2 Online-Lizenzmechanismen	252
13.7.3 Dongle-basierte Lizenzmechanismen	253
13.7.4 Lizenzaudits	254
13.7.5 Überhaupt Lizenzen?	254
13.8 Was hätte Ben unternehmen können?	254
14 Testfragen	256
Kapitel 1: Einleitung	256
Kapitel 2: Die Sicht des Kunden	257
Kapitel 3: Die Sicht des Angreifers	258
Kapitel 4: Methodologien für sichere Software	259
Kapitel 5: Sicherheitsanforderungen	260
Kapitel 6: Bedrohungsmodellierung	262
Kapitel 7: Sicherer Softwareentwurf	263
Kapitel 8: Sicheres Programmieren	264
Kapitel 9: Software auf Sicherheit testen	265
Kapitel 10: Sichere Auslieferung und Einrichtung	267
Kapitel 11: Umgang mit Schwachstellen	268
Kapitel 12: Metriken für Sicherheit	269
Kapitel 13: Codeschutz	270
Antworten	272
Abkürzungen	274
Glossar	276
Literatur	288
Kapitel 1: Einleitung	288
Kapitel 2: Die Sicht des Kunden	288
Kapitel 3: Die Sicht des Angreifers	288
Kapitel 4: Methodologien für sichere Software	289
Kapitel 5: Sicherheitsanforderungen	290
Kapitel 6: Bedrohungsmodellierung	290
Kapitel 7: Sicherer Softwareentwurf	291
Kapitel 8: Sicheres Programmieren	291
Kapitel 9: Software auf Sicherheit testen	292
Kapitel 10: Sichere Auslieferung und Einrichtung	292
Kapitel 11: Umgang mit Schwachstellen	293
Kapitel 12: Metriken für Sicherheit	293
Kapitel 13: Codeschutz	294
Index	296

Weitere E-Books zum Thema: Software-Design - Softwareentwicklung

Software Engineering

Architektur-Design und Prozessorientierung Format: PDF

Das Lehrbuch behandelt alle Aspekte der Software-Entwicklung, besonders aber Methoden und Richtlinien zur Herstellung großer und qualitativ hochwertiger Softwareprodukte. Es vermittelt das zur…

Software Engineering

Architektur-Design und Prozessorientierung Format: PDF

Das Lehrbuch behandelt alle Aspekte der Software-Entwicklung, besonders aber Methoden und Richtlinien zur Herstellung großer und qualitativ hochwertiger Softwareprodukte. Es vermittelt das zur…

Automotive Embedded Systeme