Sicherheit im Software Entwicklungsprozess („Secure SDLC“) 2015 Secure SDLC.pdf ·...
33
Matthias Rohr / Secodis GmbH / JAX 2015 Sicherheit im Software‐Entwicklungsprozess („Secure SDLC“)
Transcript of Sicherheit im Software Entwicklungsprozess („Secure SDLC“) 2015 Secure SDLC.pdf ·...
Matthias Rohr / Secodis GmbH / JAX 2015
Sicherheit im Software‐Entwicklungsprozess(„Secure SDLC“)
2
86 %Webanwendungen
14 %Infrastruktur
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.
Secodis GmbH 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)
Über mich
www.webappsecbuch.de
3
Motivation (1) – Sicherheit als Querschnittsthema
1) Sicherheit erst spät im Entwicklungsprozesszu adressieren ist teuer….. und wird dadurch gerne auf das Notwendigste reduziert.
Sicherheit ist ein Querschnittsthema, welches in allen Phasen der Entwicklung durch angemessene Maßnahmen adressiert werden muss!
2) Späte Testmethodiken (z.B. Pentests) sind oftmals nur bedingt geeignet, um Fehler in frühen Phasen überhaupt zu identifizieren.
4
86 %Webanwendungen
14 %Infrastruktur
Motivation (2) – Nachhaltigkeit & Angemessenheit
Ansätze mit der Sicherheit in der Webentwicklung adressiert werden:
5
86 %Webanwendungen
14 %Infrastruktur
Existierende Standards und Projekte
Microsoft SDL / SDL for Agile:
Cigital Touchpoints / Build Security In Initiative (US Homeland Security)
ISO 27034
BSIMM (www.bsimm.com, Studie über 67 Unternehmen)
OpenSAMM (www.opensamm.org, Best Practices der OWASP):
Prozesse
Organisa
tion
6
86 %Webanwendungen
14 %Infrastruktur
BSIMM Core Activities
7
• Tools / Sec. Monitoring• Secure Defaults / APIs• Secure Ecosystem (Dev Env)
Technologien• Rollen / Zuständigkeiten• Prozesse / Abnahmen• Budget / Planung
Organisation
Elemente organisatorischer Anwendungssicherheit
• Schulungen / Awareness• Coaching• Wikis / Doku
Qualifikation• Security Standards• Secure Coding Guidelines• Zulieferervorgaben
Vorgaben
Einbindung /Ownershaft
Aufbau vonKnow‐How
Aufbau vonKnow‐How
Einbindung/Ownershaft
©Secodis GmbH
3. Organisation / Prozesse
9
Probleme klassischer Sicherheitsmaßnahmen in einer agilen Welt
Klassisches Vorgehen
Agile Entwicklung DEVOps
Release-Zyklen Monate / Jahre Wochen Stunden
Externe Sicherheits-maßnahmen
Innerhalb vonReleases
Sicherheitskonzepte,Pentests, Sec. Code Reviews
? ???
Außerhalb von Releases Sicherheitskonzepte, Pentests, Sec. Code Reviews
Interne Sicherheits-maßnahmen
Innerhalb vonReleases ? ?? ???
Außerhalb von Releases ? ?? ???
Fehlendes Know‐How
Kurze Release‐Zyklen
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)
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).
SG2: Abnahme des technischen Designs Abnahme von z.B. Sicherheitsarchitektur
oder Sicherheitskonzept
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.
SG1
SG2SG3
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 Sicherheits‐tests 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 IndikatorBeispiel für Security IndikatorBeispiel 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.
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 & Eigenverantwortungim Team!
Sprint Planning Meeting
Daily Cycle
Update product backlog
Sprint retrospective
Sprint review
SCRUM PROCESS
Product Increment
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.
15
Software Security Groups (SSGs)
» Interne Arbeitsgruppe / Community welche die Verbesserung der SW-Sicherheit in der Organisationzum 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 14.78 people”
(BSIMM V)
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)
1. Vorgaben
18
Die „Elfenbeinturm-Problematik“
POLICYS• High‐Level‐Vorgaben• Techn‐ und Implement‐
UnspezifisichIS Policys(ISMS)
Application Security Standards
Entwicklungs‐Richtlinien /Coding Guidelines
?
ENTW.‐RICHTLINIEN• Häufig Vermengung von
Anforderungen auf unterschiedlichen Ebenen
19
Die Lösung der „Elfenbeinturm-Problematik“
POLICYS• High‐Level‐Vorgaben• Techn.‐ und Implement‐
Unspezifisich
IS Policys(ISMS)
Application Security Standards
Secure Coding Guidelines
STANDARDS• Verpflichtend• Techn.‐Spezifisch (z.B. Web)• Implement‐Unspezifisch
GUIDELINES• Empfehlungen• Techn.‐Spezifisch (z.B. Web)• Implementierungs‐
Spezifisch (z.B. Java)
Secure Coding Guidelines
20
(Web-)AppSec-Standard: TSS-WEB
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
» Vorlage für einen technisch organisatorischen Sicherheitsstandard für Webanwendungen «
www.secodis.com/tss-web
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!
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.
24
SAST vs. DAST Tools
Schwachstellen in der laufenden AnwendungManuell: 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 ConditionsBuffer OverflowsBackdoors,Unsichere APIs,Anbindung Backend,…
XSS,SQL Injection,Datenval. allg.Authentifizierung,Zugriffsschutz,Kryptographie,Information Leakage,Fehlerbehandlung,Konfiguration,…
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):
26
SAST – Integration in Build
Beispiel für Integration: Abbruch von Release‐Build bei neuen „High“‐Findings.
Lokaler Scan Server /Cloud Service
Entwickler
QA / Security
AutomatischerScan
Review
Build Server(Jenkings, Hudson,
Bamboo)
Dashboard‐Integration
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)
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 (€€€):
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)
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
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
