Sicherheit im Software Entwicklungsprozess ( Secure SDLC ) Matthias Rohr / Secodis GmbH / JAX 2015

Transkript

1 Sicherheit im Software Entwicklungsprozess ( Secure SDLC ) Matthias Rohr / Secodis GmbH / JAX 2015

2 Über mich Matthias Rohr Geschäftsführer der Secodis GmbH in Hamburg In der Applikationssicherheit seit 2004 aktiv Medien Inf. (FH), CISSP, CSSLP, CISM, CCSK Gründungsmitglied des deutschen OWASP Chapters und an zahlreichen OWASP Projekten beteiligt. 86 % Secodis GmbH Webanwendungen Gegründet 2013 am Standort Hamburg Schwerpunkt: Nachhaltige Verankerung von Sicherheit im Software Entwicklungsprozess Produktunabhängig, jedoch enger technischer Austausch mit diversen Herstellern (u.a. HP, Checkmarx, Veracode) 14 % Infrastruktur 2

3 Motivation (1) Sicherheit als Querschnittsthema 1) Sicherheit erst spät im Entwicklungsprozess zu adressieren ist teuer.. und wird dadurch gerne auf das Notwendigste reduziert. 2) Späte Testmethodiken (z.b. Pentests) sind oftmals nur bedingt geeignet, um Fehler in frühen Phasen überhaupt zu identifizieren. Sicherheit ist ein Querschnittsthema, welches in allen Phasen der Entwicklung durch angemessene Maßnahmen adressiert werden muss! 3

4 Motivation (2) Nachhaltigkeit & Angemessenheit Ansätze mit der Sicherheit in der Webentwicklung adressiert werden: 86 % Webanwendungen 14 % Infrastruktur 4

5 Existierende Standards und Projekte Microsoft SDL / SDL for Agile: Cigital Touchpoints / Build Security In Initiative (US Homeland Security) ISO % Webanwendungen BSIMM ( Studie über 67 Unternehmen) OpenSAMM ( Best Practices der OWASP): 14 % Infrastruktur Prozesse Organisation 5

6 BSIMM Core Activities 14 % Infrastruktur 86 % Webanwendungen 6

7 Elemente organisatorischer Anwendungssicherheit Organisation Rollen / Zuständigkeiten Prozesse / Abnahmen Budget / Planung Einbindung / Ownershaft Technologien Tools / Sec. Monitoring Secure Defaults / APIs Secure Ecosystem (Dev Env) Einbindung/ Ownershaft Aufbau von Know How Secodis GmbH Vorgaben Qualifikation Security Standards Secure Coding Guidelines Zulieferervorgaben Aufbau von Know How Schulungen / Awareness Coaching Wikis / Doku 7

8 3. Organisation / Prozesse

9 Probleme klassischer Sicherheitsmaßnahmen in einer agilen Welt Klassisches Vorgehen Agile Entwicklung DEVOps Release-Zyklen Monate / Jahre Wochen Stunden Externe Sicherheitsmaßnahmen Interne Sicherheitsmaßnahmen Innerhalb von Releases Außerhalb von Releases Innerhalb von Releases Außerhalb von Releases Sicherheitskonzepte, Pentests, Sec. Code Reviews Fehlendes Know How???? Sicherheitskonzepte, Pentests, Sec. Code Reviews???????????? Kurze Release Zyklen 9

10 Security Gates (SG) Variante des Quality Gates, durch welche flexible Sicherheitskontrollpunkte an bestimmten Stellen des Entwicklungsprozesses etabliert. Verschiedene Formen, z.b.: Statement: Projekt/Team dokumentiert bestimmte Sicherheitsanforderungen. Review: Durchführung festgelegter Sicherheitsprüfungen (auch innerhalb des Teams). Sign Off (Abnahme): Nächster Prozessschritt nur mit formeller Freigabe durch autorisierte Stelle (z.b. IT Sicherheit). Security Gates können optional oder verpflichtend sein und unterschiedliche Inhalte besitzen (z.b. in Abhängigkeit vom Schutzbedarf) 10

11 Wichtige Security Gates SG1: Initiales Security Gate Festlegung welche Maßnahmen umzusetzen und welche Gates mit welchen Prüfungen zu durchlaufen sind. Bei Changes: Bewerten ob Change sicherheitsrelevant und ggf. Einbinden der Sicherheit (siehe später). SG1 SG2: Abnahme des technischen Designs Abnahme von z.b. Sicherheitsarchitektur oder Sicherheitskonzept SG3 SG2 SG3: Finale Sicherheitsabnahme (FSB) Prüfung ob in SG1 festgelegte Maßnahmen umgesetzt wurden. Prüfung der Ergebnisse ggf. durchgeführter Sicherheitstests (z.b. Pentests). Bewertung von offenen Sicherheitsproblemen. 11

12 Security Change Management Arten von Changes Typ 1: Nicht Sicherheitsrelevant Basis: Security Indikator (Prüfung in SG1) Beispiel: Änderungen der Font Größe Keine Sicherheitsmaßnahmen / Security Gates / Tests erforderlich (=> kein SG2 oder SG3) Typ 2: Potentiell oder bestimmt Sicherheitsrelevant Basis: Security Indikator (Prüfung in SG1) Change wird als sicherheitsrelevant geflaggt Bei externen Anwendungen: Dedizierter Sicherheitstests der konkreten Änderung. IT Sicherheit wird eingebunden und ggf. weitere Maßnahmen abgestimmt. Typ 3: Änderungen an Sicherheitsfunktionen Werden nur im Rahmen eines Security Changes geändert und erfordern explizite Freigaben und Planung Sollten nicht in jedem Sprint durchgeführt werden Entwicklung über separaten Release Prozess möglich. Beispiel für Security Indikator Änderungen an (externen) Schnittstellen oder Änderungen bzgl. Der Verarbeitung vertraulicher Daten (Logging, Validierung, etc.) oder Änderungen an Rollen oder Berechtigungen oder Es liegen sonstige Sicherheitsbedenken vor. 12

13 Maßnahmen für Agile Sicherheit (Auswahl) Automatisierung (Tools, Integ. in Jenkins etc.) Sichere Standards (Secure Defaults) Security Change Management Mehrschichtige Sicherheit Peer (Security) Reviews Bucket / Every Sprint Requirements Security User Stories / Tasks Tagging von Sec Related Stories / Tasks Planung & Eigenverantwortung im Team! Sprint Planning Meeting Update product backlog Sprint retrospective SCRUM PROCESS Daily Cycle Sprint review Product Increment 13

14 Security Champions Lokale Zuständigkeit für Applikationssicherheit Rolle (z.b. Entwickler), welche: Ansprechpartner innerhalb des Teams und zur IT Sicherheit für Sicherheitsthemen ist als interner Multiplikator dient, aktuelle Sicherheitsvorgaben kennt, Sicherheitstools bedient kann, Interne Sicherheitsmaßnahmen koordiniert und sich auf dem Laufenden im Hinblick auf Sicherheitsthemen hält. Häufiges Modell: Pro Team / Projekt ist ein Security Champion zu bestimmen. 14

15 Software Security Groups (SSGs)» Interne Arbeitsgruppe / Community welche die Verbesserung der SW-Sicherheit in der Organisation zum Auftrag hat «Aufgaben: Diskussion und Verabschieden von Maßnahmen/Vorgaben (z.b. in Form von Standards), Tools und aktueller Risiken Dokumentation / Wiki Organisation von Awareness Maßnahmen Mitglieder (ständige & fallbezogene), z.b.: IT Sicherheits Management (Lead )Entwickler Security Champions Security Tester / QA Operations (optional) All 67 firms agree that the success of their program hinges on having an internal group devoted to software security the SSG. SSG size on average is people (BSIMM V) 15

16 Security Tests Ziel: Langfristig Sicherheitstests zumindest teilweise auch innerhalb der Organisation durchzuführen Schritt 0: Externe Pentests Große Abhängig vom Tester, Ergebnis: PDF Berichte, sehr eingeschränkte Nachhaltigkeit Schritt 1: Verbesserung der Qualität externer Pentests Risiko basiertes Testen, CVSS Scorings, Security Bug Bars, Security Testfallkatalog, etc. Schritt 2: Internes Security Testing (z.b. durch Qualitätssicherung) Beispiel 1: Reflected XSS: ><script>alert(0)</script> Beispiel 2: Horizontale Priv. Erweiterung: Zugriff auf Objekt IDs (z.b.?obj=1234) mit unterschiedlichen Rollen testen Security Peer Reviews (z.b. per gerrit, Crucible) Automatisierte Tests durch Tools (später mehr) 16

17 1. Vorgaben

18 Die Elfenbeinturm-Problematik IS Policys (ISMS) POLICYS High Level Vorgaben Techn und Implement Unspezifisich? Application Security Standards Entwicklungs Richtlinien / Coding Guidelines ENTW. RICHTLINIEN Häufig Vermengung von Anforderungen auf unterschiedlichen Ebenen 18

19 Die Lösung der Elfenbeinturm-Problematik IS Policys (ISMS) POLICYS High Level Vorgaben Techn. und Implement Unspezifisich Application Security Standards STANDARDS Verpflichtend Techn. Spezifisch (z.b. Web) Implement Unspezifisch Secure Coding Secure Coding Guidelines Guidelines GUIDELINES Empfehlungen Techn. Spezifisch (z.b. Web) Implementierungs Spezifisch (z.b. Java) 19

20 (Web-)AppSec-Standard: TSS-WEB» Vorlage für einen technisch organisatorischen Sicherheitsstandard für Webanwendungen «Enthält exemplarische Vorgaben für u.a.: Sicherheit im Entwicklungsprozess Implementierung (Validierung, Auth, etc.) Betrieb / Härtung der Plattform HTTP Security Header Software Zulieferer Sicherheit von Programmcode Sicherheitstests 20

21 (Agile) Secure Coding Guidelines Coding Guidelines dienen dazu die Vorgaben aus dem Standard für die Entwickler zu konkretisieren. Besser als statische Dokumente sind hierfür Wikis (z.b. Confluence, Mediawiki) geeignet: Zusätzlich wichtig: Secure Defaults! 21

22 2. Technologien

23 Secure Defaults (Sichere Standards) Sichere Standards (inkl. Einstellungen) sind entscheidend bei Agiler Sicherheit! Technologie Entscheidungen können große Auswirkung auf die Sicherheit haben (insb. bei Webframeworks, Security APIs) Erweiterung vorhandener Frameworks um Security Funktionen / Ref Apps. Beispiele: 1. Whitelisting (explizites Erlauben) statt Blacklisting (explizites Verbieten) 2. Sichere Krypto Standards und einfache APIs (z.b. encrypt(string), z.b. mit keyczar 3. Default Deny Prinzip: Zugriffe werden standardmäßig unterbunden und müssen explizit freigeschaltet werden 4. Minimierung der Angriffsfläche: Was nicht benötigt wird, wird abgeschaltet (Funktionen, Schnittstellen, Dienste, Parameter, etc.): 5. Implizite Enkodierung der Ausgaben durch das Framework (z.b. bei GWT), Alternativ Vorschlag für DevOPS: HTML Enkodierung aller Eingaben. 23

24 SAST vs. DAST Tools Schwachstellen in der laufenden Anwendung Manuell: Pentest Autom: Dynamic App. Security Testing (DAST) Schwachstellen auf Codeebene Manuell: Security Code Review Autom: Static App. Security Testing (SAST) Session Mgmt / CSRF, Unsichere Einbindung, Logikfehler, Anti Automatisierung, Race Conditions Buffer Overflows Backdoors, Unsichere APIs, Anbindung Backend, XSS, SQL Injection, Datenval. allg. Authentifizierung, Zugriffsschutz, Kryptographie, Information Leakage, Fehlerbehandlung, Konfiguration, 24

25 SAST (Code Security Scanner) Tools meist kommerziell: u.a. HP Fortify ( ), Checkmarx ( ), Veracode ( ), IBM AppScan SE ( ) und mit teilweise sehr unterschiedlicher Eignung! Häufiges Problem ist die Tool Ownershaft => auch deshalb wichtig innerhalb der Entwicklung zu positionieren. Beispiel Integration in Eclipse (Fortify): 25

26 SAST Integration in Build Beispiel für Integration: Abbruch von Release Build bei neuen High Findings. Build Server (Jenkings, Hudson, Bamboo) Automatischer Scan Lokaler Scan Server / Cloud Service Review Entwickler QA / Security Dashboard Integration 26

27 DAST (Web Security Scanner) Das Ownership-Problem Kommerziell (u.a.) IBM AppScan ( ), HP WebInspect ( ), Accunetix ( ) Burp ( ) Kostenfrei (u.a.): skipfish, w3af, OWASP ZAP: Probleme: (1) Generell schwer zu automatisieren, (2) Einsatz erfordert Security Know How (in QS selten vorhanden) 27

28 IAST - Security Analyse auch ohne Security Experten Analyse der Anwendung durch Agenten auf Application Server Statt Sicherheitstests reichen hierfür in der Regel fachliche Tests oder reines Crawlen der Anwendung aus (=> kaum Security Know How erforderlich) Tools (u.a.): Seeker ( ) und Contrast ( ): 28

29 Weitere Tools Auch einfache Tests können jedoch sehr effektiv sein Security Test Cases (Reflected XSS), Priviligierungstests, Security Header Blacklisting von unsicheren APIs/Imports (Code Firewall) am SVS/Git Retire JS, OWASP Dependency Checker: Identifikation von unsicheren OpenSource Libs via Maven/Jenkins (kostenfrei) 29

30 Application Security Program (ASP)

31 Exemplarische Roadmap Phase 1: Voranalyse, Planung und einfache Maßnahmen (3 6 Monate) Ist Analyse: Identifikation des Sicherheitsniveaus / Reifegrads durch Pentests, Risikoanalysen, GAP Analyse gegen OpenSAMM / BSIMM Beheben bekannter Sicherheitsprobleme und Low Hanging Fruits (Awareness) Workshops Identifikation der Stakeholder, des Zielreifegrades & Erstellung der Initial Planung Gewinnen eines Sponsers und Budgetierung der nächsten Phasen Phase 2: Erste Stufe der Integration (9 12 Monate) Aufsetzen der SSGs Pilotierung und Einführung von Security Tools Umsetzung von Standards und Guidelines Pilotierung / Etablierung von SG1 + SG3 Aufbau eines Qualifikationsprogrammes / Durchführung von Schulungen / Coachings Phase 3: Zweite Stufe der Integration (12 18 Monate) Umbau der Organisation / Etablierung von Rollen / Zuständigkeiten Integration von Security Tools in Prozesse Aufbau von internem Security Testing Interne Zuständigkeiten und Gremien für Applikationssicherheit Anpassungen und laufende Überarbeitung 31

32 Zum Schluss, ein paar wichtige Gedanken Wenn Du ein Schiff bauen willst, dann trommle nicht Männer zusammen um Holz zu beschaffen, Aufgaben zu vergeben und die Arbeit einzuteilen, sondern lehre die Männer die Sehnsucht nach dem weiten, endlosen Meer. Antoine de Saint Exupery Ein Ding ist dann wichtig, wenn irgend jemand denkt, dass es wichtig ist. William James 32

33 Vielen Dank! Fragen? Folien: Matthias Rohr 0151 /