Der Entwicklungsprozess sicherer Software. Neşe Yılmaz Institut für Informatik FU Berlin

Transkript

1 Der Entwicklungsprozess sicherer Software Neşe Yılmaz Institut für Informatik FU Berlin

2 Inhalt Einführung Security Engineering in der Theorie Security Engineering in der Praxis Vergleich Web Engineering Security 2

4 Security Engineering - Einführung Sicherheit bezeichnet einen Zustand, der frei von Risiken der Beeinträchtigung ist oder als gefahrenfrei angesehen wird. Schutzziele definieren und Sicherheit darauf anwenden Sichere Software: Eine Software ist sicher, wenn folgende Ziele erfüllt sind Vertraulichkeit Integrität Verfügbarkeit yilmaz@inf.fu-berlin.de 4

5 Security Engineering - Einführung Vertraulichkeit Ein System gewährleistet die Informationsvertraulichkeit, wenn es keine unautorisierte Informationsgewinnung ermöglicht. Integrität Ein System gewährleistet die Datenintegrität, wenn es Subjekten nicht möglich ist, die zu schützenden Daten unautorisiert und unbemerkt zu manipulieren. Verfügbarkeit Ein System gewährleistet Verfügbarkeit, wenn authentifizierte und autorisierte Subjekte in der Wahrnehmung ihrer Berechtigungen nicht unautorisiert beeinträchtigt werden können. yilmaz@inf.fu-berlin.de 5

6 Security Engineering - Einführung Ein bestehendes IT-System soll sicher gemacht werden! Was ist Security Engineering? Security Engineering gibt die Maßnahmen und Methoden an, die zur Konstruktion sicherer Software angewendet werden. yilmaz@inf.fu-berlin.de 6

8 Security Engineering Prinzipien Saltzer und Schroeder (1975) Erlaubnisprinzip (fail-safe defaults) Vollständigkeit (complete mediation) Minimale Rechte (need-to-know) Akzeptanz (economy of mechanism) Offener Entwurf (open design) Sicherheitskern (security kernel) und wie sollte man vorgehen? 8

9 Security Engineering Phasen Saltzer und Schroeder [Ecker C., IT-Sicherheit, S. 69] 9

10 Security Engineering Phasen Graphik Ergänzung zum Sicherheitsprozess, der im Grundschutzhandbuch des BSI vorgeschlagen ist. BSI Bundesamt für Sicherheit in der Informationstechnik Gibt Grundschutzhandbuch heraus, indem Empfehlungen für Standardschutzmaßnahmen für typische IT-Systeme enthalten sind nicht nur technische, sondern auch organisatorische, personelle und infrastrukturelle Maßnahmen Ziel bereits bestehende IT-Infrastrukturen sichern 10

11 Security Engineering - Sicherheitsprozess Erstellung des Sicherheitskonzepts gemäß BSI-Prozess: Feststellung der funktionalen Anforderungen und Systemgegebenheiten Bedrohungs- und Risikoanalyse falls hoher Schutzbedarf Modellierung Basis-Sicherheitscheck Soll-Ist-Abgleich yilmaz@inf.fu-berlin.de 11

12 Security Engineering - Sicherheitsprozess BSI-Sicheheitsprozess 1. Vorüberlegung (IT-Sicherheitspolitik) 2. Organisationsstruktur für IT-Sicherheitsmanagement 3. Konzept erstellen 4. Realisierung 5. Schulung und Sensibilisierung 6. Wartung der IT-Sicherheit yilmaz@inf.fu-berlin.de 12

13 Security Engineering Phasen [Ecker C., IT-Sicherheit, S. 70] 13

14 Security Engineering Phasen 14

15 Security Engineering - Strukturanalyse Die Strukturanalyse beschreibt die Vorerhebung von Informationen Netztopologien Client-Server-System Alle Netzkomponenten (Hubs, Switches, Router, Netzwerkdrucker) Netzwerkverbindung (lokale Netze, Funknetze) Vorhandene Verbindungen (ISDN, Modem) Gleichartige Komponenten gruppieren System (Betriebssystem) Art der Nutzung (Personalverwaltung, Dateiverwaltung) Art der Verbindung (TCP/IP) yilmaz@inf.fu-berlin.de 15

16 Security Engineering - Strukturanalyse Beispiel: Netztopologieplan für ein Unternehmensnetz yilmaz@inf.fu-berlin.de 16

17 Security Engineering - Schutzbedarf Das Ziel der Schutzbedarfsermittlung besteht darin, orientiert an möglichen Schäden und Beeinträchtigungen zu entscheiden, welchen Schutzbedarf eine Anwendung bzw. ein IT-System im Hinblick auf die Vertraulichkeit, Integrität und Verfügbarkeit besitzt. Claudia Eckert (IT-Sicherheit, 2004) yilmaz@inf.fu-berlin.de 17

18 Security Engineering - Schutzbedarf Schutzbedarfserstellung: Kategorie nach Grundschutzhandbuch des BSI Schutzbedarfserstellung nach Schadensszenarien Auf die Szenarien werden die Schutzkategorien angewendet yilmaz@inf.fu-berlin.de 18

19 Security Engineering - Schutzbedarf da ein Schutzbedarf meist nicht oder nur schwer quantifizierbar ist, beschränkt man sich auf [ ] auf qualitative Aussagen. Grundlage: Schutzbedarfskategorien Mögliche Schadensszenarien Gesetze Vorschriften Verträge Selbstbestimmungsrecht Unversehrtheit Aufgabenerfüllung Negative Auswirkungen Finanzielle Auswirkungen yilmaz@inf.fu-berlin.de 19

20 Security Engineering - Schutzbedarf Zusammenfassung zum Schutzbedarf: Szenarien erstellen mit Hilfe von Was wäre wenn - Fragen Ist-Zustand der Infrastruktur Defizite zwischen Ist- und Soll-Zustand Bedrohungs- und Risikoanalyse Ursachen und Randbedingungen für das Eintreten von Schadensfällen hinterfragen yilmaz@inf.fu-berlin.de 20

21 Security Engineering - Bedrohungsanalyse Man kann die Bedrohungsanalyse auf zwei Arten festhalten: Bedrohungsmatrix yilmaz@inf.fu-berlin.de 21

22 Security Engineering - Bedrohungsanalyse Bedrohungs- bzw. Angriffsbaum (attack-tree) yilmaz@inf.fu-berlin.de 22

23 Security Engineering - Risikoanalyse Risikoanalyse Bewertung der Bedrohungen Wahrscheinlichkeiten für das Eintreten ermitteln und potentiellen Schaden ermitteln, der dadurch entstehen kann. Angreifer-Modell (Angreifertyp, zur Verfügung stehendes Budget) yilmaz@inf.fu-berlin.de 23

24 Security Engineering - Risikoanalyse Attributierung Attributierungen der Kanten des Baumes Kosten und Aufwand zur Durchführung eines Angriffs die Notwendigkeit zum Einsatz spezieller Hardware Penetrationstests Testen des System mit realen Bedingungen 1. Man sagt an, dass ein Angriff stattfinden wird 2. Man sagt nicht an, dass ein Angriff stattfinden wird Absichern!!! yilmaz@inf.fu-berlin.de 24

25 Security Engineering Phasen 25

26 Security Engineering - und danach Modellierung, Entwurf und Betrieb Sicherheitsstrategie und- modell Ist-Zustand ermitteln Strategie wählen Modell erstellen Systemarchitektur und Validierung Architektur-Grobentwurf Validierung Testen Evaluieren Wartung Monitoring Tools yilmaz@inf.fu-berlin.de 26

28 Security Engineering in der Praxis Proceedings of the 20th Annual Computer Securtiy Applications Conference For the software industry, the key to meeting today s demand for improved security is to implement repeatable processes that reliably deliver measurably improved security. Steve Lipner (The Trustworthy Computing Security Development Lifecycle) Ziel: Solche Prozesse sollen die Anzahl der Schwachstellen (im Design, in der Kodierung und in der Dokumentation) auf Dauer zu minimieren. yilmaz@inf.fu-berlin.de 28

29 Security Engineering in der Praxis Es gibt drei Aspekte zur Gestaltung von sicherer Software: Wiederholbarer Prozess (repeatable process) Technische Weiterbildung (engineer education) Maße und Verantwortlichkeit (metrics and accountability) SDL (Security Development Lifecycle) Ein Verfahrensmodell, zur Gestaltung von Software, die bösartigen Attacken ausgesetzt sein könnte 29

30 Security Engineering in der Praxis Baseline development process (z.b. Wasserfallmodell) 30

31 Security Engineering in der Praxis Im Januar 2002 erklärte Microsoft-Chef Bill Gates das Trustworthy Computing zur obersten Maxime des Unternehmens. Microsoft Zwei Ziele, die sich Microsoft mit SDL gesetzt hat: Verkleinern der Anzahl von sicherheitsrelevanten Entwurfsund Codemängeln sowie Verringern des Schweregrads gegebenenfalls verbleibender Mängel. 31

32 Security Engineering in der Praxis Das SD 3 +C-Prinzip Secure by Design Die Architektur, das Design und die Implementierung von Software müssen so gestaltet sein, dass sie schon von ihrem Konzept her von Angriffen sicher ist. Secure by Default Nicht allgemein gebrauchte Funktionen von Softwareprodukten sind in den Standardeinstellungen deaktiviert und Benutzer somit nur die Rechte erhalten, die sie benötigen. Secure in Deployment Für alle Softwareprodukte werden entsprechende Hilfsmittel zur Verfügung gestellt, die Unternehmen ermöglichen, die SW sicher einzusetzen und Updates einfach bereitzustellen. Communications Sicherheitsrisiken bei Produkten werden den Kunden mitgeteilt. yilmaz@inf.fu-berlin.de 32

33 Security Engineering in der Praxis SDL Overview 33

34 Security Engineering in der Praxis Schulungsphase (requirements phase) Schulung des Produktteams Entwurfsphase (design phase) Bedrohungsmodellierung Entwicklungsphase (implementation phase) Tools, Checklisten, Best Practices Sicherheitstests (verification phase) z.b. Fuzzing Security-Push Versions-Phase (release phase) Erste Version Resonanz-Phase (response phase) Evaluation 34

35 Security Engineering in der Praxis Feedback zu SDL Effektivität Tools, Überprüfung, Code-Überblick Aufwand Schulung online und Workshops Ergebnisse Funktioniert SDL? Microsoft sagt Ja! Anzahl der Mängel konnten ca. um 50%-60% verringert werden. 35

36 Security Engineering in der Praxis SDL bei Microsoft Notwendige Anwendung von SDL Einsatzgebiete Notwendige Ausbildung Schulungen Vorgaben für das Produktions-Team Vorgaben für Bewertungen You can t manage what you can t measure. Das zentrale Sicherheits-Team yilmaz@inf.fu-berlin.de 36

38 Vergleich SLD BSI Schulungsphase Entwurfsphase Entwicklungsphase Sicherheitstests Versions-Phase Resonanz-Phase Vorüberlegung (IT-Sicherheitspolitik) Organisationsstruktur für IT-Sicherheitsmanagement Konzept erstellen Realisierung Schulung und Sensibilisierung Wartung der IT-Sicherheit 38

39 Vergleich Entwurfsphase Sicherheitstests Versions-Phase Resonanz-Phase Entwicklungsphase 39

40 Vergleich Diskussion: Kann man die Theorie in dem SDL wieder finden? Kann man beide vergleichen? Welche Unterschiede fallen auf? 40

42 Web Engineering Security Sicherheit im Web Was wurde erfragt? Untersuchung über Sicherheit in der allgemeinen Anwendung und Sicherheit im Prozess selbst Wie ging man vor? Befragung von 16 Mitarbeitern mit versch. Vorkenntnissen 42

43 Web Engineering Security Rahmenbedingungen des Unternehmens Wasserfall-Herangehensweise Entspricht der jetzige Zustand der Designphase? Fraglich, ob der Entwicklungsprozess überwacht und aktualisiert wird Das Unternehmen hat zwei Entwicklungsmethoden: High level-methode: nach Plan Log level-methode: ad-hoc Entwicklung 43

44 Web Engineering Security Wo wird Sicherheit involviert? 44

45 Web Engineering Security Probleme (nach Aussagen der Mitarbeitern): Programmierer nicht einbezogen Auswertung fehlt Nach der Entwicklungsphase keine Sicherheitsbetrachtung Externe Sicherheitsbeauftragte Sicherheitsbeschluss Wie wird Sicherheit in Ihrem Betrieb behandelt? Während der Entwicklung, während der Modellierung, mit Hilfe von Standards und Prozessen, etc. Problem zwischen Externen und den Internen 45

46 Web Engineering Security Praxis Welche Rolle spielt die Sicherheit in Ihrem Betrieb? Spielt eine große Rolle Spielt eine geringe Rolle Falsche Herangehensweise Wartung manchmal, regelmäßig man geht davon aus, dass es regelmäßig gewartet wird, einige es aber nicht wahrnehmen alle Mitarbeiter involviert? Gefahr geht von Naivität, Ignoranz, Programmcode, Programmierer, etc. aus 46

47 Web Engineering Security Problem: Konflikt zwischen Entwicklern für Anwendungen und Sicherheitsbeauftragte Ergebnis: Bei Web Engineering Security ist die Betrachtung der Sicherheit während der Entwurfsphase 47

48 Vielen Dank! 48