Secure Engineering. Prof. Dr. Michael Waidner. Fraunhofer SIT und TU Darmstadt

Transkript

1 Secure Engineering Prof. Dr. Michael Waidner Fraunhofer SIT und TU Darmstadt 2011 ICT-Security Technologietag, DB Systel, Frankfurt, 5. Juni 2012 Page 1 of 29

2 Fraunhofer-Institut für Sichere Informationstechnologie Ältestes und größtes Institut für IT-Sicherheit in Deutschland 160 Angestellte 9.1 M Jahresbudget, zu 2/3 aus Auftragsforschung für Industrie und Staat 2 Lehrstühle an der TU Darmstadt (Waidner, Sadeghi) Birlinghoven Berlin Darmstadt Kompetenzfelder Secure Engineering & Security Testing Mobile & Cyberphysical Systems Cloud Systems & Services Identity and Privacy Multimedia Security Information Security Management IT-Forensics 10 IT-Sec Profs an der TU Darmstadt + 6 an der h_da Page 2 of 29

3 BMBF-Finanziertes Zentrum für Cybersecurity-Forschung ( ) TU Darmstadt + Fraunhofer SIT Wissenschaftliche Exzellenz Security & Privacy by Design Trends Anwendungen und Architekturen Methoden und Tools Bausteine für IT-Sicherheit Fokus auf exzellente Nachwuchsgruppen Claude Shannon Fellows Stand: 2 von ca. 6 CSF s besetzt Schwesterzentren in Karlsruhe, Saarbrücken Page 3 of 29

4 Gliederung 1. Sicherheit und Unsicherheit von IT 2. Secure Engineering: Security and Privacy by Design 3. Zusammenfassung Page 4 of 29

5 Sicherheitsunfälle des Jahrs 2011 Trend bislang ungebrochen: Cyber-Kriminalität, Hacktivismus, Spionage SecureID Compromise Anonymous Source for base graphics: IBM X-Force Research and Development, 2012 Page 5 of 29

6 Anatomie eines Angriffs RSA & Lockheed-Martin (2011) 1: Social Engineering + Unpatched Vulnerability 3: Angreifer findet Schlüssel für das SecureID System und lädt sie über einen Staging Server. 17. März: RSA warnt Kunden Ungewöhnlich schnell (z.b. Angriff auf Nortel wurde 10 Jahre lang nicht beachtet) 3. März: Vorgetäuschte an RSA Angestellte: [2011 Recruitment plan.xls] mit Flash und Zero-day CVE in Adobe Flash Player. Hinterlässt Poison Ivy Trojan. 2: Digitales Shoulder Surfing Poison Ivy verbindet sich mit dem Control Server, Angreifer erhält volle Kontrolle über Rechner. Angreifer bewegt sich in Richtung hochwertiger Systeme und Daten : Angreifer nutzt SecureID Schlüssel zum digitalen Einbruch in Verteidigungsindustrie. 3. Juni: Lockheed informiert über einen verhinderten Angriff. RSA startet Austauschprogramm für SecureID Token (>40M weltweit, Lockheed > ). August 2011: RSA bestätigt unmittelbare Kosten von 66M$. 27. March 2012: NSA identifiziert China als Ursprung des Angriffs. Page 6 of 29

7 Aktuelle Cyber-Gefährdungen und Angriffsformen Register des Bundesamtes für Sicherheit in der Informationstechnik (BSI) Gezieltes Hacking von Webservern mit dem Ziel der Platzierung von Schadsoftware oder zur Vorbereitung der Spionage in angeschlossenen Netzen oder Datenbanken Drive-by-Exploits zur breitflächigen Infiltration von Rechnern mit Schadsoftware beim Surfen mit dem Ziel der Übernahme der Kontrolle des betroffenen Rechners Gezielte Malware-Infiltration über und mithilfe von Social Engineering mit dem Ziel der Übernahme der Kontrolle über den betroffenen Rechner und anschließender Spionage Distributed Denial of Service-Angriff mittels Botnetzen mit dem Ziel der Störung der Erreichbarkeit von Webservern oder der Funktionsfähigkeit der Netzanbindung der betroffenen Institution Ungezielte Verteilung von Schadsoftware mittels SPAM oder Drive-by- Exploits mit Fokus auf Identitätsdiebstahl Mehrstufige Angriffe, bei denen z.b. zunächst zentrale Sicherheitsinfrastrukturen (wie TLS/SSL-Zertifizierungsstellen) kompromittiert werden, um dann in weiteren Schritten die eigentlichen Ziele anzugreifen Source: Register aktueller Cyber-Gefährdungen und Angriffsformen, BSI, Bonn 2012 Page 7 of 29

8 Informationstechnologie findet sich überall und meistens gibt es schon gehackte Beispiele Page 8 of 29

9 Wieso ist IT unsicher? Im Prinzip wissen wir seit mehr als 20 Jahren, wie man IT sicher entwerfen und betreiben kann. Page 9 of 29

10 1. Industrialisierte und gut ausgestattete Angreifer Page 10 of 29

11 2. Wir machen immer wieder dieselben Fehler Vulnerabilities = Fehler in der SW/HW Fehler im Design, Code, Configs Fehler im Sicherheitsmodell Blinde Integration externer Komponenten (z.b. aus Open Source Projekten) Kontext, Identitäten, Events usw. gehen zwischen Systemen verloren Entwickler, Administratoren, Endnutzer Überfordert und unmotiviert Neugierde, Effizienz, Vertrauen Schlechtes IT-Management Unklare Verantwortlichkeiten Kein Überblick Kein Change Management Keine Frühwarnfähigkeiten Typische Ursachen aus Sicht von Development-Organisationen: Sicherheit nachgeordnetes Ziel Keine Zeit bzw. keine Ressourcen Mangelndes Fachwissen Schlechte Unterstützung durch Entwicklungstools und prozesse Page 11 of 29

12 Dumme Fehler in Web-Anwendungen 86% Konfigurationsfehler, 79% Integrationsfehler (IBM X-Force 2011) Könnten durch Checklisten, Reviews und Tools alle sehr leicht abgefangen werden! Source: IBM X-Force Research and Development, OWASP Top Ten 2010 Page 12 of 29

13 Dumme Fehler in der Cloud Öffentliche AMI s in Amazon Elastic Compute Cloud (CASED/SIT 2011) Analyse findet geheime Schlüssel und Passwörter in öffentlichen AMIs von Privaten, aber auch von einigen (eher unprofessionellen) Herstellern: Für alle Maschinen desselben Typs passende Schlüssel Angriffe auf Nutzer dieser AMIs (Manipulation, Botnetze) Für Maschinen im Netz des Herstellers passende Schlüssel Angriffe auf Hersteller der AMIs Diese öffentlichen AMIs wurden genutzt, auch von namhaften Firmen Source: Bugiel et al.: AmazonIA: when elasticity snaps back; ACM CCS 2011 Page 13 of 29

14 Zeichen von Stabilisierung, wenn auch auf hohem Niveau Anzahl neuer Vulnerabilities pro Jahr, nach Herstellerangaben? Source for base graphics: IBM X-Force Research and Development, 2012 Page 14 of 29

15 Fehlervermeidung ist 100x günstiger als Patching Klares Indiz für den Wert von Security and Privacy by Design Relative durchschnittliche Kosten zur Behebung eines Bugs 1x 10x 100x Entwurf Test Betrieb Überschlagsrechnung Große Software hat M LoC (Lines of Code) 1 Bug / 1000 LoC 1 Vulnerability / 100 Bugs Also Vulnerabilities Source: Shull et.al.: What We Have Learned About Fighting Defects; IEEE 2002 Studien zu den absoluten Kosten/Bug: IBM: 80$ 7 600$ Cigital: 139$ $ Page 15 of 29

16 3. Sicherheit hat natürliche Grenzen Komplexität von IT Menschen machen Fehler: Unmöglich, SW/HW fehlerfrei herzustellen oder zu nutzen Sicherheitsaufwand muss Risiko angemessen sein, 80/20 Unsichere Systeme Unsichere Attribution von Angreifern Möglicherweise unsicheres Verhalten ist oft gewollt oder notwendig und darf nicht verhindert werden Nutzung von IT braucht im allg. Freiheitsgrade IT mit zu starken Einschränkungen wird umgangen Überwachung schafft neue Risiken Überwachungsmechanismen sind neues Angriffsziel Erschwert Schutz der Privatsphäre Online Social Networks als freiwillige (?) Überwachung Page 16 of 29

17 Gliederung 1. Sicherheit und Unsicherheit von IT 2. Secure Engineering: Security and Privacy by Design 3. Zusammenfassung Page 17 of 29

18 Komponenten eines Secure Engineering Programms Vereinfacht: Reine Produkt-Perspektive Governance: Strategy, Responsibilities and Powers, Metrics, Policies Standards Secure Coding Patterns, Models Protocols Libraries (Crypto, ) Training Awareness (Up & Down) Community Education & Training Supply Chain Security Trusted Supplier Code Signing 3 rd -party Code Open Source Code Design Security Requirements Use/Abuse Cases Threat/Attack Model Security & Privacy Risk Usability Security Architecture Resilient Architecture Development Dev/Test Process with Security Gates Dev/Test Environment Dev/Test Tooling Measuring Progress Test/Verification External Assurance Maintaining Security Security Research Product Security Incident Response Team Incident Response Plan Vulnerability Disclosure Hardening, Patching Page 18 of 29

19 Komponenten eines Secure Engineering Programms Blau: Forschungsthemen in CASED Governance: Strategy, Responsibilities and Powers, Metrics, Policies Standards Secure Coding Patterns, Models Secure Protocols Libraries (Crypto, ) Training Awareness (Up & Down) Community Education & Training Supply Chain Security Trusted Supplier Code Signing 3 rd -party Code Open Source Code Design Security Requirements Use/Abuse Cases Threat/Attack Model Security & Privacy Risk Usability Security Architecture Resilient Architecture Development Dev/Test Process with Security Gates Dev/Test Environment Dev/Test Tooling Measuring Progress Test/Verification External Assurance Maintaining Security Security Research Product Security Incident Response Team Incident Response Plan Vulnerability Disclosure Hardening, Patching Page 19 of 29

20 Secure Development Lifecycles Microsoft (SDLC, STRIDE), Cigital (TP, BSIMM), OWASP (CLASP, OpenSAMM) Source: Source: Source: McGraw: A Software Security Marketplace Case Study; IEEE Software, 9/ Page 20 of 29

21 Code-Analyse Werkzeuge Industrie + Forschung. + Code Reviews. + Penetrationstest/Ethical Hacking. Source: Tian-yang et.al.: Research on Software Security Testing; WASET Page 21 of 29

22 Herausforderung: Ende-zu-Ende Secure Engineering Konsistent und verbunden über Dokumentation, über alle Phasen hinweg Security concept artifacts Security concept documentation Complete security analysis Practical methods Development process Security design and implementation Secure product Page 22 of 29

23 Beispiel: Threat Modeling Experiment at Fraunhofer SIT Subject 1 Consistent assessments including partial matches Three experienced security engineers, products and threat modelling techniques Each subject identified about 30 valid threats, over 70 in total There is surprisingly little overlap Subject 3 Subject 2 Page 23 of 29

24 Beispiel: Risikofreundliche IT-Architekturen Architekturen können mehr oder weniger überlebensfähig sein High-risk Architecture Plain data (without metadata) Single Layer of Defense Access Control Centralized data repositories & processing Low-risk Architecture Rich meta data (rights, obligations, retention, ) Multiple Layers of Defense + Wrap Unknown/Legacy Code Usage Control Distributed and client-side data repositories & processing, finegrained protection and isolation Real identity, early identification Broad permissions, opt-in by default Pseudonyms, attributes, late identification Least privilege, security and privacy by default Page 24 of 29

25 Beispiel: Model-driven Security Idee Verständliche Beschreibung Automate Implementierung Beispiele: Abbildung UML-Modelle auf XACML Zugriffskontrollregeln Abbildung Sicherheitsanforderungen auf spezielle Mechanismen / Konstrukte Compiler für kryptographische Protokolle (gezielt auf spezielle Prozessoren usw.) Unterstützung für Patterns und Secure Coding-Guidelines Page 25 of 29

26 Herausforderung: Sichere Ende-zu-Ende Integration Über unterschiedliche Software- und Hardwaresysteme hinweg Semantik / Annahmen Sicherheits-Kontext Sicherheits-Policy Kryptogr. Schlüssel Identitäten Page 26 of 29

27 Gliederung 1. Sicherheit und Unsicherheit von IT 2. Secure Engineering: Security and Privacy by Design 3. Zusammenfassung Page 27 of 29

28 Aktive Forschungsthemen in EC SPRIDE Methoden und Tools Auch: Privacy by Design, Building Blocks, Architekturen für wichtige Gebiete wie Cloud, Mobile, Cyberphysical Systems, Wichtiges Paradigma für Software-Sicherheit Erwartung: 100:1 Kostenvorteil gegenüber Security by Patching Erfolgreiche Programme in der Industrie: Adobe, IBM, Microsoft, SAP, Guter Fortschritt seit Anfang 2000: relativ einfacher Einstieg Aber auch nach wie vor viele offene Fragen Page 28 of 29

29 Prof. Dr. Michael Waidner Fraunhofer-Institut für Sichere Informationstechnologie Rheinstrasse Darmstadt, Germany Technische Universität Darmstadt CASED/EC-SPRIDE & Lehrstuhl Sicherheit in der IT Mornewegstrasse Darmstadt, Germany Page 29 of 29