Security Development Lifecycles MS TechDays Bern, 9. April 2009 Jan Münther, CTO Security, n.runs AG

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

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

Training Training bildet den Einstieg in einen Security Lifecycle Security Development Lifecycles – TechDays 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 © n.runs AG, Jan Münther, 27-Mar-17

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

Requirements Sicherheitsthemen gehören ins Pflichtenheft! Security Development Lifecycles – TechDays 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" © n.runs AG, Jan Münther, 27-Mar-17

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

Security Development Lifecycles – TechDays 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 © n.runs AG, Jan Münther, 27-Mar-17

Security Development Lifecycles – TechDays 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 © n.runs AG, Jan Münther, 27-Mar-17

Phase Drei: Design ( 3 / ) Security Development Lifecycles - TechDays © n.runs AG, Jan Münther, 27-Mar-17

Security Development Lifecycles – TechDays 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! © n.runs AG, Jan Münther, 27-Mar-17

Phase Drei: Design ( 5 / 8 ) Design-Problem: Hartkodiertes Passwort Security Development Lifecycles – TechDays 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 © n.runs AG, Jan Münther, 27-Mar-17

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

Phase Drei: Design ( 7 / 8 ) Hartkodierte Passwörter als Backdoors Security Development Lifecycles – TechDays Phase Drei: Design ( 7 / 8 ) Hartkodierte Passwörter als Backdoors Z.B. Netgear WG602 Accesspoint Problematisches Design wird zum Security-Bug Aruba Wireless Controller http://www.nruns.com/security_advisory_aruba_advisory_draft_unauth_access_ms.php http://www.nruns.com/security_advisory_aruba_advisory_draft_buffer_overflow_ms.php © n.runs AG, Jan Münther, 27-Mar-17

Phase Drei: Design ( 8 / 8 ) Design-Problem: Schlechte Kryptographie Security Development Lifecycles – TechDays 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 © n.runs AG, Jan Münther, 27-Mar-17

Phase Drei: Design ( 9 / ) Design-Problem: Schlechte Kryptographie Security Development Lifecycles - TechDays 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 © n.runs AG, Jan Münther, 27-Mar-17

Phase Drei: Design ( 9 / ) Design-Problem: Schlechte Kryptographie Security Development Lifecycles - TechDays 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 © n.runs AG, Jan Münther, 27-Mar-17

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

Implementierung ( 1 / 5 ) Klassisches Gebiet für Code-Defekte Security Development Lifecycles - TechDays 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 © n.runs AG, Jan Münther, 27-Mar-17

Implementierung ( 2 / 5 ) Fehler können verhindert werden durch Security Development Lifecycles - TechDays 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 © n.runs AG, Jan Münther, 27-Mar-17

Security Development Lifecycles - TechDays 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 © n.runs AG, Jan Münther, 27-Mar-17

Implementierung ( 4 / 5 ) SQL Injection – einfach zu verhindern, aber doch noch oft zu finden! <% Dim id, password, q, rs, d id = Request.Form("id") password = Request.Form("password") ' ** Create your Query q = "SELECT * FROM password WHERE id LIKE '" &_      id & "' AND password LIKE '" & password & "'" ' ** Create a RecordSet to store the results of the Query Set rs = Server.CreateObject("ADODB.RecordSet") rs.Open q, "DSN=xxxxxx;" ' ** check for no records returned (id or password not found) if NOT rs.EOF then ' ** Set cookies for user's convenience     d = Date     Response.Cookies("userid") = id     Response.Cookies("pword") = password     Response.Cookies("userid").Expires = DateAdd("yyyy",2,d)     Response.Cookies("pword").Expires = DateAdd("yyyy",2,d) end if %>

Visual C#, Schritt für Schritt, Microsoft Press (S. 587) 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+"'";

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

Verifizierung (1 / 4 ) Typische Maßnahme zur Verifizierung: Fuzzing Security Development Lifecycles - TechDays 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. © n.runs AG, Jan Münther, 27-Mar-17

Security Development Lifecycles - TechDays 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 © n.runs AG, Jan Münther, 27-Mar-17

Verifizierung (3 / 4 ) Problem beim Fuzzing oftmals die Fehleranalyse Security Development Lifecycles - TechDays 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" © n.runs AG, Jan Muenther, 27-Mar-17

Security Development Lifecycles - TechDays 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 © n.runs AG, Jan Münther, 27-Mar-17

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

Security Development Lifecycles - TechDays 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? © n.runs AG, Jan Münther, 27-Mar-17

Release ( 2 / 3 ) Beispiele für schlechtes Release Security Management Security Development Lifecycles - TechDays Release ( 2 / 3 ) Beispiele für schlechtes Release Security Management WonderWare SCADA 2008-01-30: Initial contact email sent by to Wonderware setting the estimated publication date of the advisory to February 25th. 2008-01-30: Contact email re-sent to Wonderware asking for a software security contact for Wonderware InTouch. 2008-02-06: New email sent to Wonderware asking for a response and for a software security contact for Wonderware InTouch. 2008-02-28: Core makes direct phone calls to Wonderware headquarters informing of the previous emails and requesting acknowledgment of the notification of a security vulnerability. 2008-02-29: Vendor asks for a copy of the proof of concept code used to demonstrate the vulnerability. 2008-03-03: Core sends proof-of-concept code written in Python. 2008-03-05: Vendor asks for compiler tools required to use the PoC code. 2008-03-05: Core sends a link to http://www.python.org © n.runs AG, Jan Münther, 27-Mar-17

Release ( 3 / 3 ) Beispiele für schlechtes Release Security Management Security Development Lifecycles - TechDays Release ( 3 / 3 ) Beispiele für schlechtes Release Security Management Quelle: http://securityninja.co.uk/blog/?p=212 © n.runs AG, Jan Münther, 27-Mar-17

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

Response Baldige Antworten auf Meldungen zu Sicherheits-Problemen Security Development Lifecycles - TechDays 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 © n.runs AG, Jan Münther, 27-Mar-17

Kontakt ... Fragen? ... Offene Diskussion Jan Muenther Security Development Lifecycles - TechDays Kontakt Jan Muenther Chief Technical Officer, Security n.runs AG, Nassauer Straße 60, D-61440 Oberursel phone +49 6171 699-0, fax +49 6171699-199 Jan.Muenther@nruns.com, http://www.nruns.com PGP-Fingerprint: 3291 81b8 8A59 6FB9 80F0 1120 2DD5 E13F F58D BAC0 ... Fragen? ... Offene Diskussion © n.runs AG, Jan Muenther, 27-Mar-17

Your MSDN resources check out these websites, blogs & more! 3/27/2017 3:10 PM Your MSDN resources check out these websites, blogs & more! Presentations TechDays: www.techdays.ch MSDN Events: http://www.microsoft.com/switzerland/msdn/de/presentationfinder.mspx MSDN Webcasts: http://www.microsoft.com/switzerland/msdn/de/finder/default.mspx MSDN Events MSDN Events: http://www.microsoft.com/switzerland/msdn/de/events/default.mspx Save the date: Tech•Ed 2009 Europe, 9-13 November 2009, Berlin MSDN Flash (our by weekly newsletter) Subscribe: http://www.microsoft.com/switzerland/msdn/de/flash.mspx MSDN Team Blog RSS: http://blogs.msdn.com/swiss_dpe_team/Default.aspx Developer User Groups & Communities Mobile Devices: http://www.pocketpc.ch/ Microsoft Solutions User Group Switzerland: www.msugs.ch .NET Managed User Group of Switzerland: www.dotmugs.ch FoxPro User Group Switzerland: www.fugs.ch © 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Your TechNet resources check out these websites, blogs & more! 3/27/2017 3:10 PM Your TechNet resources check out these websites, blogs & more! Presentations TechDays: www.techdays.ch TechNet Events TechNet Events: http://technet.microsoft.com/de-ch/bb291010.aspx Save the date: Tech•Ed 2009 Europe, 9-13 November 2009, Berlin TechNet Flash (our by weekly newsletter) Subscribe: http://technet.microsoft.com/de-ch/bb898852.aspx Schweizer IT Professional und TechNet Blog RSS: http://blogs.technet.com/chitpro-de/ IT Professional User Groups & Communities SwissITPro User Group: www.swissitpro.ch NT Anwendergruppe Schweiz: www.nt-ag.ch PASS (Professional Association for SQL Server): www.sqlpass.ch © 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Save the date for tech·days next year! 3/27/2017 3:10 PM 7. – 8. April 2010 Congress Center Basel Save the date for tech·days next year! © 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Premium Sponsoring Partners 3/27/2017 3:10 PM Premium Sponsoring Partners Classic Sponsoring Partners Media Partner © 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.