Security Development Lifecycles

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

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, 1-Apr-14

SDL von Microsoft Use SecurityDevelopment Tools & Security Best Dev & Test Practices Create SecurityDocsand ToolsFor Product PrepareSecurityResponsePlan Security Push FinalSecurity Review Security Servicing &ResponseExecution Security Training Security Arch & Attack SurfaceReview Security Kickoff& Register withSWI Security DesignBest Practices Pen Testing ThreatModeling Der herkömmliche Entwicklungszyklus bei Microsoft, inkl. Aufgaben und Prozesse Testing and Verification Code Signing A CheckpointExpress Signoff RTM Product SupportService Packs/QFEs SecurityUpdates Feature ListsQuality GuidelinesArch DocsSchedules DesignSpecifications Development of New Code FunctionalSpecifications Bug Fixes Requirements Design Implementation Verification Release Support&Servicing heise Security Konferenz 2008, Jan Münther

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, 1-Apr-14

Security Development Lifecycles– TechDays SDL von Microsoft Use SecurityDevelopment Tools & Security Best Dev & Test Practices Create SecurityDocsand ToolsFor Product PrepareSecurityResponsePlan Security Push FinalSecurity Review Security Servicing &ResponseExecution Security Training Security Arch & Attack SurfaceReview Security Kickoff& Register withSWI Security DesignBest Practices Pen Testing ThreatModeling Requirements Design Implementation Verification Release Support&Servicing heise Security Konferenz 2008, Jan Münther

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, 1-Apr-14

Security Development Lifecycles– TechDays SDL von Microsoft Use SecurityDevelopment Tools & Security Best Dev & Test Practices Create SecurityDocsand ToolsFor Product PrepareSecurityResponsePlan Security Push FinalSecurity Review Security Servicing &ResponseExecution Security Training Security Arch & Attack SurfaceReview Security Kickoff& Register withSWI Security DesignBest Practices Pen Testing ThreatModeling 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, 1-Apr-14

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, 1-Apr-14

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

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, 1-Apr-14

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, 1-Apr-14

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, 1-Apr-14

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, 1-Apr-14

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, 1-Apr-14

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, 1-Apr-14

Security Development Lifecycles - TechDays SDL von Microsoft Use SecurityDevelopment Tools & Security Best Dev & Test Practices Create SecurityDocsand ToolsFor Product PrepareSecurityResponsePlan Security Push FinalSecurity Review Security Servicing &ResponseExecution Security Training Security Arch & Attack SurfaceReview Security Kickoff& Register withSWI Security DesignBest Practices Pen Testing ThreatModeling Requirements Design Implementation Verification Release Support&Servicing heise Security Konferenz 2008, Jan Münther

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, 1-Apr-14

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, 1-Apr-14

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, 1-Apr-14

Implementierung ( 4 / 5 ) • SQL Injection – einfach zu verhindern, aber doch noch oft zu finden! <%Dim id, password, q, rs, did = Request.Form("id")password = Request.Form("password")' ** Create your Queryq = "SELECT * FROM password WHERE id LIKE '" &_ id & "' AND password LIKE '" & password & "'"' ** Create a RecordSet to store the results of the QuerySet 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%>

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,ShipCity,ShipCountry" dataCommand.CommandText += "FROM Orders WHERE CustomerID='" + customerID+"'";

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, 1-Apr-14

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, 1-Apr-14

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, 1-Apr-14

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, 1-Apr-14

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, 1-Apr-14

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, 1-Apr-14

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, 1-Apr-14

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, 1-Apr-14

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, 1-Apr-14

Your MSDN resourcescheck out these websites, blogs & more! PresentationsTechDays: www.techdays.chMSDN Events: http://www.microsoft.com/switzerland/msdn/de/presentationfinder.mspxMSDN Webcasts: http://www.microsoft.com/switzerland/msdn/de/finder/default.mspx MSDN EventsMSDN Events: http://www.microsoft.com/switzerland/msdn/de/events/default.mspxSave 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 BlogRSS: http://blogs.msdn.com/swiss_dpe_team/Default.aspx Developer User Groups & CommunitiesMobile Devices: http://www.pocketpc.ch/Microsoft Solutions User Group Switzerland: www.msugs.ch.NET Managed User Group of Switzerland: www.dotmugs.chFoxPro User Group Switzerland: www.fugs.ch

Your TechNet resourcescheck out these websites, blogs & more! PresentationsTechDays: www.techdays.ch TechNet EventsTechNet 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 BlogRSS: http://blogs.technet.com/chitpro-de/ IT Professional User Groups & CommunitiesSwissITPro User Group: www.swissitpro.chNT Anwendergruppe Schweiz: www.nt-ag.chPASS (Professional Association for SQL Server): www.sqlpass.ch

Save the date for tech·days next year! 7. – 8. April 2010Congress Center Basel

Premium Sponsoring Partners Classic Sponsoring Partners Media Partner

Security Development Lifecycles