Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

This text is for the internal use of the Customer and n.runs AG only. No part of this publication may be reproduced, transmitted, transcribed, stored in.

Ähnliche Präsentationen


Präsentation zum Thema: "This text is for the internal use of the Customer and n.runs AG only. No part of this publication may be reproduced, transmitted, transcribed, stored in."—  Präsentation transkript:

1 This text is for the internal use of the Customer and n.runs AG only. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system or translated into any language in any form by any means without the written permission of the Customer or n.runs AG. This document is under the copy write protection of n.runs AG 1 Security Development Lifecycles MS TechDays Bern, 9. April 2009 Jan Münther, CTO Security, n.runs AG

2 Agenda Roadmap Awareness und Training Phasen der Entwicklung Requirements Design Implementierung Verifizierung Veröffentlichung Response 2© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles – TechDays

3 SDL von Microsoft heise Security Konferenz 2008, Jan Münther 3 Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution Feature Lists Quality Guidelines Arch Docs Schedules Design Specifications Testing and Verification Development of New Code Bug Fixes Code Signing A Checkpoint Express Signoff RTM Product Support Service Packs/ QFEs Security Updates RequirementsDesignImplementationVerificationRelease Support & Servicing Threat Modeling Functional Specifications Der herkömmliche Entwicklungszyklus bei Microsoft, inkl. Aufgaben und Prozesse

4 Training Training bildet den Einstieg in einen Security Lifecycle Sicherheitsbewusstsein Verschiedene Zielgruppen Management Teamleiter / Produktmanager Entwickler Unterstützung der Bemühungen durch Top Level Management unumgängliche Voraussetzung für den Erfolg! Sicherheitsbewusstsein als Teil der Firmenkultur 4© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles – TechDays

5 SDL von Microsoft heise Security Konferenz 2008, Jan Münther 5 Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution RequirementsDesignImplementationVerificationRelease Support & Servicing Threat Modeling Security Development Lifecycles – TechDays

6 Requirements Sicherheitsthemen gehören ins Pflichtenheft! Auch und besonders bei Entwicklung durch Dritte Schutzbedarfsanalyse Wie sicherheitskritisch wird die Anwendung? Definiert letzlich durch den "Data Owner" 6© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles – TechDays

7 SDL von Microsoft heise Security Konferenz 2008, Jan Münther 7 Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution RequirementsDesignImplementationVerificationRelease Support & Servicing Threat Modeling Security Development Lifecycles – TechDays

8 Phase Drei: Design ( 1 / 8 ) Entwurf der Sicherheitsmechanismen zur Umsetzung der Schutzbedürfnisse Threat Modelling hilft beim Erkennen von Bedrohungen Demonstration Threat Modeling Tool v3.0 Threat Modeling ist die zentrale Komponenten im SDL Übersicht über die Bedrohungen Grafische Unterstützung und Visualisierung der Zusammenhänge Automatische Hilfe beim Auffinden von potentiellen Bedrohungen 8© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles – TechDays

9 Phase Drei: Design ( 2 / 8 ) Die Erfahrung zeigt: Das Erfordernis des Threat Modelings allein hebt das Sicherheitsniveau erheblich Umfassende Auseinandersetzung mit dem Thema Sicherheit unumgänglich 9© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles – TechDays

10 Phase Drei: Design ( 3 / ) 10© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles - TechDays

11 Phase Drei: Design ( 4 / 8 ) Design-Fehler sabotieren die Sicherheit der Gesamtlösung von Anfang an Selbst bei sicherer Implementierung kann das Endprodukt nicht sicher sein Ein paar Beispiele für unsicheres Design! 11© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles – TechDays

12 Phase Drei: Design ( 5 / 8 ) Design-Problem: Hartkodiertes Passwort Zwei Varianten "default password" Sollten vom Benutzer geändert werden Erfolgt oft nicht Zum Teil unbekannte Benutzer Beispiel: Oracle OUTLN "hardcoded password" "Wartungszugang" Zum Debugging 12© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles – TechDays

13 Phase Drei: Design ( 6 / 8 ) Hartkodierte Passwörter als Backdoors Z.B. Netgear WG602 Accesspoint Problematisches Design wird zum Security-Bug Aruba Wireless Controller 13© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles – TechDays

14 Phase Drei: Design ( 7 / 8 ) Hartkodierte Passwörter als Backdoors Z.B. Netgear WG602 Accesspoint Problematisches Design wird zum Security-Bug Aruba Wireless Controller 14© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles – TechDays

15 Phase Drei: Design ( 8 / 8 ) Design-Problem: Schlechte Kryptographie Obfuskation von gespeicherten Passwörtern Beispiel: CPIC-User für Synactive SAP GUI XT Passwort "verschlüsselt" in Registry abgelegt Algorithmus lässt sich disassemblieren Decoder 15© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles – TechDays

16 Phase Drei: Design ( 9 / ) Design-Problem: Schlechte Kryptographie Obfuskation von gespeicherten Passwörtern Beispiel: CPIC-User für Synactive SAP GUI XT Passwort "verschlüsselt" in Registry abgelegt Algorithmus lässt sich disassemblieren Decoder 16© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles - TechDays

17 Phase Drei: Design ( 9 / ) Design-Problem: Schlechte Kryptographie Obfuskation von gespeicherten Passwörtern Beispiel: CPIC-User für Synactive SAP GUI XT Passwort "verschlüsselt" in Registry abgelegt Algorithmus lässt sich disassemblieren Decoder 17© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles - TechDays

18 SDL von Microsoft heise Security Konferenz 2008, Jan Münther 18 Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution RequirementsDesignImplementationVerificationRelease Support & Servicing Threat Modeling Security Development Lifecycles - TechDays

19 Implementierung ( 1 / 5 ) Klassisches Gebiet für Code-Defekte Unmanaged Code (C/C++) Fehlende oder unzulängliche Längenüberprüfungen Integer Overflows / Integer Underflows Managed Code Code Access Security Luring Attacks Alle typischen Sicherheitsprobleme wie Injection Attacks Häufig XML-Processing-Probleme.NET Remoting 19© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles - TechDays

20 Implementierung ( 2 / 5 ) Fehler können verhindert werden durch Austausch von riskanten APIs Klassische Beispiele strcpy() und strcat() Einsatz von sicheren Bibliotheken (SafeInt, Anti XSS Libs etc.) Festgelegt durch Secure Coding Policies Überprüft durch Tools zur Statischen Analyse Überprüfung beim Check-In Überprüfung zur "Build Time" Für Managed Code: FXCop beinhaltet Security-Regeln Code Analyse mit Sec Rules in VS Team Edition CAT.NET Einsatz von Tools zur Statischen Analyse kann und sollte Teil des Implementierungsprozesses werden! Kein Check-In bei kritischen Fehlern 20© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles - TechDays

21 Implementierung ( 3 / 5 ) Klassischer Fehler: falsche Überprüfung von Zertifikaten bool RemoteCertValidate(object sender, X509Certificate cert, X509Chain chain, System.Net.Security.SslPolicyErrors error) { certificateName = cert.Subject; if (cert.Subject.StartsWith(subjectName)) { return true; } return false; } Gefunden durch Source Code Audit! Automatisierte Statische Analyse würde diesen Fehler nicht finden 21© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles - TechDays

22 Implementierung ( 4 / 5 ) SQL Injection – einfach zu verhindern, aber doch noch oft zu finden!

23 Implementierung ( 5 / 5 ) Visual C#, Schritt für Schritt, Microsoft Press (S. 587) SqlCommand dataCommand = new SqlCommand(); dataCommand.Connection = dataConnection; dataCommand.CommandText = "SELECT OrderID,OrderDate,ShippedDate,ShipName,ShipAddress,ShipC ity,ShipCountry" dataCommand.CommandText += "FROM Orders WHERE CustomerID='" + customerID+"'";

24 SDL von Microsoft heise Security Konferenz 2008, Jan Münther 24 Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution RequirementsDesignImplementationVerificationRelease Support & Servicing Threat Modeling Security Development Lifecycles - TechDays

25 Verifizierung (1 / 4 ) Typische Maßnahme zur Verifizierung: Fuzzing Automatisiertes Testen zur Provokation von Fehlerfällen Einsatz besonders sinnvoll bei externen Datenquellen Datei-Parsing Netzwerkprotokoll-Parsing Vorgefertigte Tools für verschiedene Protokolle und Formate verfügbar Codenomicon (kommerziell) PROTOS (frei) Frameworks zur Erstellung eigener Fuzzer Peach Sulley Etc. 25© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles - TechDays

26 Verifizierung (2 / 4 ) Fuzzing ändert gültige Werte so ab, dass sie klassische Fehler auslösen Typisches Beispiel: Strings in Dateiformaten oder Netzwerkprotokollen werden durch inkrementierende Länge auf Buffer Overflows getestet Z.B. erst 512 Byte, dann 1024, dann 4096 etc. Dann 513 Byte und 1025, 4097 etc. Off by one, off by few 26© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles - TechDays

27 Verifizierung (3 / 4 ) Problem beim Fuzzing oftmals die Fehleranalyse Manche Exceptions werden abgefangen Ist das Problem für Angreifer ausnutzbar? Welche Funktion hat den Fehler ausgelöst Mitunter Call Stack nicht mehr lesbar Weiteres Problem: Code-Pfade und Testfälle "Code Coverage" nur teilweise messbar Ansätze umfassen "Rückspulen" 27© n.runs AG, Jan Muenther, 4-Jan-14 Security Development Lifecycles - TechDays

28 Verifizierung (4 / 4 ) Untersuchung der aus dem Threat Model ermittelten möglichen Bedrohungen Penetration Testing Manipulationsmöglichkeiten Z.B. logische Fehler Privilegieneskalationen Race Conditions Penetration Test sollte eine umfassende Untersuchung der möglichen Risiken sein Je nach Produkt und Entwicklungsplattform gezieltes Fuzzing Manuelles Testen nach Problemen Z.B. Webapplikationen nach XSS und SQL Injection 28© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles - TechDays

29 SDL von Microsoft heise Security Konferenz 2008, Jan Münther 29 Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution RequirementsDesignImplementationVerificationRelease Support & Servicing Threat Modeling Security Development Lifecycles - TechDays

30 Release ( 1 / 2 ) Wichtig ist vor der Veröffentlichung: Planung für eventuelle Sicherheits-Vorfälle Rekonstruktion der Probleme Geklärte Zuständigkeiten Wer nimmt Reports auf? Wer verifiziert Probleme? Wer behebt Probleme? Wer verifiziert die Behebung? 30© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles - TechDays

31 Release ( 2 / 3 ) Beispiele für schlechtes Release Security Management WonderWare SCADA : Initial contact sent by to Wonderware setting the estimated publication date of the advisory to February 25th : Contact re-sent to Wonderware asking for a software security contact for Wonderware InTouch : New sent to Wonderware asking for a response and for a software security contact for Wonderware InTouch : Core makes direct phone calls to Wonderware headquarters informing of the previous s and requesting acknowledgment of the notification of a security vulnerability : Vendor asks for a copy of the proof of concept code used to demonstrate the vulnerability : Core sends proof-of-concept code written in Python : Vendor asks for compiler tools required to use the PoC code : Core sends a link to 31© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles - TechDays

32 Release ( 3 / 3 ) Beispiele für schlechtes Release Security Management 32© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles - TechDays Quelle:

33 SDL von Microsoft heise Security Konferenz 2008, Jan Münther 33 Security Training Security Kickoff & Register with SWI Security Design Best Practices Security Arch & Attack Surface Review Use Security Development Tools & Security Best Dev & Test Practices Create Security Docs and Tools For Product Prepare Security Response Plan Security Push Pen Testing Final Security Review Security Servicing & Response Execution RequirementsDesignImplementationVerificationRelease Support & Servicing Threat Modeling Security Development Lifecycles - TechDays

34 Response Baldige Antworten auf Meldungen zu Sicherheits-Problemen Kommunikation ist wichtig! Researcher veröffentlichen eventuell ohne erfolgte Patches, wenn die Fehlerbehandlung vernachlässigt wird Längere Antwort- und Patchzeiten sollten begründet werden können Updates aktiv den Kunden zuführen Mails an Kunden 34© n.runs AG, Jan Münther, 4-Jan-14 Security Development Lifecycles - TechDays

35 35 Kontakt Jan Muenther Chief Technical Officer, Security n.runs AG, Nassauer Straße 60, D Oberursel phone , fax PGP-Fingerprint: b8 8A59 6FB9 80F DD5 E13F F58D BAC0... Offene Diskussion... Fragen? © n.runs AG, Jan Muenther, 4-Jan-14 Security Development Lifecycles - TechDays

36 Presentations TechDays: MSDN Events: MSDN Webcasts: MSDN Events MSDN Events: Save the date: TechEd 2009 Europe, 9-13 November 2009, Berlinhttp://www.microsoft.com/switzerland/msdn/de/events/default.mspx MSDN Flash (our by weekly newsletter) Subscribe: MSDN Team Blog RSS: Developer User Groups & Communities Mobile Devices: Microsoft Solutions User Group Switzerland: Managed User Group of Switzerland: FoxPro User Group Switzerland:

37 Presentations TechDays: TechNet Events TechNet Events: Save the date: TechEd 2009 Europe, 9-13 November 2009, Berlinhttp://technet.microsoft.com/de-ch/bb aspx TechNet Flash (our by weekly newsletter) Subscribe: Schweizer IT Professional und TechNet Blog RSS: IT Professional User Groups & Communities SwissITPro User Group: NT Anwendergruppe Schweiz: PASS (Professional Association for SQL Server):

38 This text is for the internal use of the Customer and n.runs AG only. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system or translated into any language in any form by any means without the written permission of the Customer or n.runs AG. This document is under the copy write protection of n.runs AG Save the date for tech·days next year! 7. – 8. April 2010 Congress Center Basel

39 This text is for the internal use of the Customer and n.runs AG only. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system or translated into any language in any form by any means without the written permission of the Customer or n.runs AG. This document is under the copy write protection of n.runs AG Classic Sponsoring Partners Media Partner Premium Sponsoring Partners


Herunterladen ppt "This text is for the internal use of the Customer and n.runs AG only. No part of this publication may be reproduced, transmitted, transcribed, stored in."

Ähnliche Präsentationen


Google-Anzeigen