SlideShare ist ein Scribd-Unternehmen logo
Stephan Kaps | Bundesversicherungsamt
Continuous Security Testing
Unbekannt, http://rachaelandtom.info/gallery/v/falken-random/random-pics/kurios119.jpg.html
© Christian Schneider
© Christian Schneider
Mögliche Lösung:
Continuous Security Testing
Stephan Kaps
Techn. Projektleiter
Software-Architekt
JEE – SOA - Host
Java seit 2002Speaker & Autor
ISTQB, ISAQB,
IREB und ITIL
zertifiziert
Leidenschaft sind neue Technologien
und Methoden
• Was ist das?
• Warum machen wir das?
• Wie fängt man an?
• Das Projekt
• Maturity Model
• Ausblick
• Fazit
Agenda
Was ist das?
Continuous Security Testing bedeutet:
statische und dynamische Analysen
bereits während der Entwicklung durchzuführen,
um frühzeitig und regelmäßig
Sicherheitsmaßnahmen umzusetzen,
bevor manuelle Prüfungen
wie Penetrationstests zum Einsatz kommen
Was ist das?
• Secure Coding Guide
• Integration in Build-Prozess (SDLC)
• Automatisierung (wenn möglich)
• Zusammenarbeit von Entwicklung, Betrieb und
Sicherheitsbeauftragten (SecDevOps)
Im Detail
#SecDevOps
Warum machen wir das?
• Wir müssen
– ISO 2700x, BSI Grundschutz
• Wir wollen
– proaktiv werden
– Mysterium enträtseln
• „moving security to the left!“
Warum machen wir das?
Warum machen wir das?
Bisher
Warum machen wir das?
Bisher
Bei Continous Delivery
Wie fängt man an?
Verstehen!
Angriffe
Verwundbarkeiten
Fehler
Schwachstellen
Attacken
• Verfügbare Informationsquellen
– OWASP Top 10
– MITRE Top 25
• Schwachstellen (CWE)
• Attacken (CAPEC)
– Web Application Security
Consortium (WASC)
Wie fängt man an?
WASC Katalog
DevOpsCon 2016 - Continuous Security Testing - Stephan Kaps
Zusammenhang
Ein Beispiel
• Java Web-Anwendungen:
– Als Basis die TOP 10 des OWASP
– Schwachstellen zu den einzelnen Risiken
• eindeutige Vorgaben formulieren
• Testbar durch statische Analysen
• Integration in Build-Prozess möglich
Konkret
Das Projekt
• Erstellung und Etablierung von
Programmierrichtlinien zur sicheren
Softwareentwicklung
• Schneller Start mit Quick Wins
• Umsetzung mit wenig Aufwand möglich
• Richtlinien sollen leicht und schnell testbar sein
Ziele
Der Plan
Richtlinien
Nr Beschreibung Risiko Verwundbarkeit
/Schwachstelle
Attacken testbar durch
1 Verhindere das Injizieren von Schadcode in SQL-Befehlen A1 - OWASP Top10 2013 WASC-20
CWE-20
CWE-89
WASC-19
CAPEC-66
FindSecBugs
2 Verwende keine hart kodierten Passwörter A2 - OWASP Top10 2013 CWE-798
CWE-259
CWE-321
FindSecBugs
3 Verwende sicheres Session-Management A2 - OWASP Top10 2013 CWE-613
CWE-614
WASC-47
CAPEC-21
web.xml Check
4 Verwende keine vorhersagbaren Zufallszahlen-Generatoren A2 - OWASP Top10 2013 CWE-6
CWE-330
CAPEC-21
CAPEC-112
WASC-11
FindSecBugs
5 Verhindere den unerlaubten Zugriff auf Dateien durch Pfad-Manipulationen A4 - OWASP Top10 2013 CWE-22 WASC-33
CAPEC-126
FindSecBugs
6 Vermeide die Anzeige von technischen Fehlermeldungen A5 - OWASP Top10 2013 CWE-209
WASC-14
CAPEC-54 web.xml Check
7 Verwende keine schwachen kryptografischen Algorithmen A6 - OWASP Top10 2013 CWE-326
CWE-327
CWE-261
CAPEC-55
CAPEC-112
FindSecBugs
8 Verwende ausreichend lange Schlüssel A8 - OWASP Top10 2013 CWE-6 CAPEC-21 web.xml Check
9 Verwende keine 3rd-Party Libraries mit bekannten Verwundbarkeiten A9 - OWASP Top10 2013 diverse: injection,
broken access
control, XSS, etc.
entsprechend
den
Verwundbarkeiten
Dependency Check
10 Verhindere das unzulässige Umleiten zu anderen URLs A10 - OWASP Top 10 2013 CWE-601 CAPEC-194
WASC-38
FindSecBugs
Verhindere das Injizieren von
Schadcode in SQL-Befehlen
Beispiel
• Ursache:
– Ungeprüfte Übernahme von Usereingaben oder
Input-Parametern in SQL-Abfragen
• Auswirkung:
– Ausführung unberechtigter Abfragen oder
Manipulation von Daten
Beispiel: SQL Injection
• Kann verhindert werden durch:
– Verwendung von Prepared Statements
– Verwendung von Hibernate Criteria
Beispiel: SQL Injection
Vermeide die Anzeige von
technischen Fehlermeldungen
Beispiel II
• Ursache:
– Technische Fehlermeldungen werden bis zum
Anwender durchgereicht
• Auswirkung:
– Sensible Informationen über eine Anwendung, die
Infrastruktur oder verarbeitete Daten werden für
Unberechtigte sichtbar
Beispiel: techn. Fehlermeldungen
• Kann verhindert werden durch:
– Definition von Standard-Error-Pages in der web.xml
– Ausgabe von StackTraces in separate Log-Dateien
Beispiel: techn. Fehlermeldungen
Integration in den Build-Prozess
• FindSecBugs
(http://h3xstream.github.io/find-sec-bugs/)
• OWASP Dependency Check
(https://www.owasp.org/index.php/OWASP_Dependency_Check)
• Web.xml Checker
Demnächst https://github.com/kitenco
Tools
FindSecBugs Report
DevOpsCon 2016 - Continuous Security Testing - Stephan Kaps
Jenkins Report
DevOpsCon 2016 - Continuous Security Testing - Stephan Kaps
Web.xml Checker
Code-Beispiel auf Github
https://github.com/kitenco/security-test
Xanitizer.com
No work for Devs
Maturity Model
© Christian Schneider
4 verschiedene Axen
Dynamische Tiefe
4
3
2
1
1
2
3
4
Intensität
Konsolidierung 4 3 2 1 1 2 3 4 Statische Tiefe
Statische Tiefe
1
• Third-Party Libraries überprüfen
• Tool: OWASP Dependency Check, retire.js für JavaScript
2
• Wichtigen Code scannen
• Tool: FindSecBugs, ScanJS
3
• Kompletten Code scannen
• Tool: FindSecBugs, ScanJS
4
• Source-Code der Third-Party Libraries scannen
• Tool: FindSecBugs, ScanJS
Dynamische Tiefe
1
• public attack surface (pre-auth)
• Tool: Spider (z.B. ZAP, Arachni, BDD-Security)
2
• Scan über GUI (authenticated, post-auth)
• Tool: Spider (ZAP + Session Properties, Selenium)
3
• Separates Scannen einzelner Layer
• Tool: ZAP (z.B. bei internen Web-Service Aufrufen)
4
• Gezieltes, individuelles Scannen
• Tool: Selenium Tests über ZAP oder BDD-Security
Intensität
1
• Dynamisch: Passives Scannen
• Statisch: Einsatz des Standard-Regelwerks
2
• Dynamisch: leichtgewichtige aktive Scanns
• Statisch: Anpassung des Standard-Regelwerks
3
• Dynamisch: schwergewichtige Scanns für wichtige Bereiche
• Statisch: FindSecBugs Threshold=Low, Effort=Max
4
• Dynamisch: schwergewichtige Scanns für alle Bereiche
• Statisch: Customized rule sets
Konsolidierung
1
• Erzeuge HTML Reports
• Anzeige im Jenkins
2
• Definition von Quality Gates
3
• Duplikate diverser Tools konsolidieren
• Tickets im Bug-Tracker erzeugen
4
• Code coverage of security tests
• z.B. OWASP Code Pulse -> dann Reviews
• Level 3-4Statische Tiefe
• Level 0Dynamische Tiefe
• Level 3-4Intensität
• Level 2Konsolidierung
Dieses Projekt erreicht ...
Ausblick
• Weitere Programmier-Richtlinien aufstellen
• Dazugehörige Tests entwickeln und in den
Build-Prozess aufnehmen
• KVP!
Ausblick
https://www.owasp.org/index.php/OWASP_Proactive_Controls
1. Verify for Security Early and Often
2. Parameterize Queries
3. Encode Data
4. Validate All Inputs
5. Implement Identity and Authentication Controls
6. Implement Appropriate Access Controls
7. Protect Data
8. Implement Logging and Intrusion Detection
9. Leverage Security Frameworks and Libraries
10.Error and Exception Handling
OWASP Proactive Controls
• ZAP (Zed Attack Proxy) by OWASP
– https://www.owasp.org/index.php/OWASP_
Zed_Attack_Proxy_Project
• BDD-Security (ContinuumSecurity)
– http://www.continuumsecurity.net
• Arachni Scanner
– http://www.arachni-scanner.com/
Dynamische Analysen (DAST)
Zed Attack Proxy (ZAP)
DevOpsCon 2016 - Continuous Security Testing - Stephan Kaps
BDD-Security
Scenario: Issue a new session ID after authentication
• Apache Shiro
– http://shiro.apache.org
• OWASP ESAPI
– https://www.owasp.org/index.php/Category
:OWASP_Enterprise_Security_API
• JBoss Keycloak
– http://www.keycloak.org
Security Frameworks
DevOpsCon 2016 - Continuous Security Testing - Stephan Kaps
• OWASP Java Encoder
– https://www.owasp.org/index.php/OWASP_
Java_Encoder_Project
• Google Keyczar
– https://github.com/google/keyczar
• OWASP Code Pulse
– https://www.owasp.org/index.php/OWASP_
Code_Pulse_Project
Weitere Tools
Bald…
• SecureCodeBox von Iteratec
• Docker Container zu Security Test Farm
https://www.iteratec.de/themen/securecodebox/
DevOpsCon 2016 - Continuous Security Testing - Stephan Kaps
Fazit
• Aufstellen von Richtlinien, die durch eine kurze und
präzise Erläuterung verstanden werden
• Einführung von kleinen Tools, die sich in den Build-
Prozess integrieren lassen und somit kontinuierlich
und am besten automatisiert die Einhaltung der
Richtlinien verifizieren.
Wichtige Erfolgskriterien
• Ausführung dynamischer Tests kann sehr viel
Zeit in Anspruch nehmen
• Nicht bei jedem Build-Lauf möglich
• Oder weniger Auslieferungen
ABER
Nur wenn sich Security Testing nahtlos in den
Entwicklungs-Workflow integriert, indem Security
Bugs genauso aufgespürt, verwaltet und behoben
werden wie andere Bugs, dann wird dieses
Instrument auch von Entwicklern akzeptiert und die
Art und Weise, wie sichere Software entwickelt wird,
positiv beeinflusst.
Fazit
Artikel zum Vortrag erschienen in der ObjektSpektrum 4/2015
Noch Fragen?
http://www.kitenco.de
info@kitenco.de | @kitenco1
Vielen Dank
work just simply smarter
● Continuous
Delivery
● Application
Lifecycle
Management
● Social-
Collaboration
● Vorträge
● Artikel
● PoCs
● JIRA
● Jenkins
● Confluence
● Schulung
● Coaching
● Training
Suppression of False Positives
• BDD-Security
– Use false positive tables in story files
• FindSecurityBugs
– Use exclusion lists in config (XML filter files)
– Use annotation @SuppressWarnings on false
positive code lines
• Dependency-Check
– XML file of suppressions (checked-in along with
the project)

Weitere ähnliche Inhalte

Was ist angesagt?

DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes
QAware GmbH
 
Per Anhalter zu Cloud-nativen API Gateways
Per Anhalter zu Cloud-nativen API GatewaysPer Anhalter zu Cloud-nativen API Gateways
Per Anhalter zu Cloud-nativen API Gateways
QAware GmbH
 
Making the internet faster HTTP/3 und QUIC
Making the internet faster HTTP/3 und QUICMaking the internet faster HTTP/3 und QUIC
Making the internet faster HTTP/3 und QUIC
QAware GmbH
 
Mit LoRaWAN und Serverless zur eigenen Smart-Office-Lösung
Mit LoRaWAN und Serverless zur eigenen Smart-Office-LösungMit LoRaWAN und Serverless zur eigenen Smart-Office-Lösung
Mit LoRaWAN und Serverless zur eigenen Smart-Office-Lösung
QAware GmbH
 
Enterprise Cloud Native ist das neue Normal
Enterprise Cloud Native ist das neue NormalEnterprise Cloud Native ist das neue Normal
Enterprise Cloud Native ist das neue Normal
QAware GmbH
 
IT-Sicherheit und agile Entwicklung – geht das? Sicher!
IT-Sicherheit und agile Entwicklung – geht das? Sicher!IT-Sicherheit und agile Entwicklung – geht das? Sicher!
IT-Sicherheit und agile Entwicklung – geht das? Sicher!
Carsten Cordes
 
stackconf 2020 | SecDevOps in der Cloud by Florian Wiethoff
stackconf 2020 | SecDevOps in der Cloud by Florian Wiethoffstackconf 2020 | SecDevOps in der Cloud by Florian Wiethoff
stackconf 2020 | SecDevOps in der Cloud by Florian Wiethoff
NETWAYS
 
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
QAware GmbH
 
Agile Breakfast - If it hurts do it more often
Agile Breakfast - If it hurts do it more oftenAgile Breakfast - If it hurts do it more often
Agile Breakfast - If it hurts do it more often
pingworks
 
Punkt.de – Layout-Testing: was geht, was bringt´s, wer braucht´s?
Punkt.de – Layout-Testing: was geht, was bringt´s, wer braucht´s?Punkt.de – Layout-Testing: was geht, was bringt´s, wer braucht´s?
Punkt.de – Layout-Testing: was geht, was bringt´s, wer braucht´s?
punkt.de GmbH
 
DevDay 2016: Peter Lehmann - Testautomatisierungsframework Xeta
DevDay 2016: Peter Lehmann - Testautomatisierungsframework XetaDevDay 2016: Peter Lehmann - Testautomatisierungsframework Xeta
DevDay 2016: Peter Lehmann - Testautomatisierungsframework Xeta
DevDay Dresden
 
Qualitymanagement mit Sitecore und Sonarqube
Qualitymanagement mit Sitecore und SonarqubeQualitymanagement mit Sitecore und Sonarqube
Qualitymanagement mit Sitecore und Sonarqube
Daniel Scherrer
 
Holistische Sicherheit für Microservice-basierte Systeme
Holistische Sicherheit für Microservice-basierte SystemeHolistische Sicherheit für Microservice-basierte Systeme
Holistische Sicherheit für Microservice-basierte Systeme
QAware GmbH
 

Was ist angesagt? (13)

DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes DevOps Prinzipien im Zusammenspiel mit Kubernetes
DevOps Prinzipien im Zusammenspiel mit Kubernetes
 
Per Anhalter zu Cloud-nativen API Gateways
Per Anhalter zu Cloud-nativen API GatewaysPer Anhalter zu Cloud-nativen API Gateways
Per Anhalter zu Cloud-nativen API Gateways
 
Making the internet faster HTTP/3 und QUIC
Making the internet faster HTTP/3 und QUICMaking the internet faster HTTP/3 und QUIC
Making the internet faster HTTP/3 und QUIC
 
Mit LoRaWAN und Serverless zur eigenen Smart-Office-Lösung
Mit LoRaWAN und Serverless zur eigenen Smart-Office-LösungMit LoRaWAN und Serverless zur eigenen Smart-Office-Lösung
Mit LoRaWAN und Serverless zur eigenen Smart-Office-Lösung
 
Enterprise Cloud Native ist das neue Normal
Enterprise Cloud Native ist das neue NormalEnterprise Cloud Native ist das neue Normal
Enterprise Cloud Native ist das neue Normal
 
IT-Sicherheit und agile Entwicklung – geht das? Sicher!
IT-Sicherheit und agile Entwicklung – geht das? Sicher!IT-Sicherheit und agile Entwicklung – geht das? Sicher!
IT-Sicherheit und agile Entwicklung – geht das? Sicher!
 
stackconf 2020 | SecDevOps in der Cloud by Florian Wiethoff
stackconf 2020 | SecDevOps in der Cloud by Florian Wiethoffstackconf 2020 | SecDevOps in der Cloud by Florian Wiethoff
stackconf 2020 | SecDevOps in der Cloud by Florian Wiethoff
 
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
 
Agile Breakfast - If it hurts do it more often
Agile Breakfast - If it hurts do it more oftenAgile Breakfast - If it hurts do it more often
Agile Breakfast - If it hurts do it more often
 
Punkt.de – Layout-Testing: was geht, was bringt´s, wer braucht´s?
Punkt.de – Layout-Testing: was geht, was bringt´s, wer braucht´s?Punkt.de – Layout-Testing: was geht, was bringt´s, wer braucht´s?
Punkt.de – Layout-Testing: was geht, was bringt´s, wer braucht´s?
 
DevDay 2016: Peter Lehmann - Testautomatisierungsframework Xeta
DevDay 2016: Peter Lehmann - Testautomatisierungsframework XetaDevDay 2016: Peter Lehmann - Testautomatisierungsframework Xeta
DevDay 2016: Peter Lehmann - Testautomatisierungsframework Xeta
 
Qualitymanagement mit Sitecore und Sonarqube
Qualitymanagement mit Sitecore und SonarqubeQualitymanagement mit Sitecore und Sonarqube
Qualitymanagement mit Sitecore und Sonarqube
 
Holistische Sicherheit für Microservice-basierte Systeme
Holistische Sicherheit für Microservice-basierte SystemeHolistische Sicherheit für Microservice-basierte Systeme
Holistische Sicherheit für Microservice-basierte Systeme
 

Andere mochten auch

Security testing
Security testingSecurity testing
Security testing
Rihab Chebbah
 
Security testing ?
Security testing ?Security testing ?
Security testing ?
Maikel Ninaber
 
Software Project Management: Testing Document
Software Project Management: Testing DocumentSoftware Project Management: Testing Document
Software Project Management: Testing Document
Minhas Kamal
 
Security testing presentation
Security testing presentationSecurity testing presentation
Security testing presentation
Confiz
 
we45 - Web Application Security Testing Case Study
we45 - Web Application Security Testing Case Studywe45 - Web Application Security Testing Case Study
we45 - Web Application Security Testing Case Study
we45
 
Continuous and Visible Security Testing with BDD-Security
Continuous and Visible Security Testing with BDD-SecurityContinuous and Visible Security Testing with BDD-Security
Continuous and Visible Security Testing with BDD-Security
Stephen de Vries
 
Pactera Cybersecurity - Application Security Penetration Testing - Mobile, We...
Pactera Cybersecurity - Application Security Penetration Testing - Mobile, We...Pactera Cybersecurity - Application Security Penetration Testing - Mobile, We...
Pactera Cybersecurity - Application Security Penetration Testing - Mobile, We...
Kyle Lai
 
8 Access Control
8 Access Control8 Access Control
8 Access Control
Alfred Ouyang
 
Audit Checklist for Information Systems
Audit Checklist for Information SystemsAudit Checklist for Information Systems
Audit Checklist for Information Systems
Ahmad Tariq Bhatti
 

Andere mochten auch (9)

Security testing
Security testingSecurity testing
Security testing
 
Security testing ?
Security testing ?Security testing ?
Security testing ?
 
Software Project Management: Testing Document
Software Project Management: Testing DocumentSoftware Project Management: Testing Document
Software Project Management: Testing Document
 
Security testing presentation
Security testing presentationSecurity testing presentation
Security testing presentation
 
we45 - Web Application Security Testing Case Study
we45 - Web Application Security Testing Case Studywe45 - Web Application Security Testing Case Study
we45 - Web Application Security Testing Case Study
 
Continuous and Visible Security Testing with BDD-Security
Continuous and Visible Security Testing with BDD-SecurityContinuous and Visible Security Testing with BDD-Security
Continuous and Visible Security Testing with BDD-Security
 
Pactera Cybersecurity - Application Security Penetration Testing - Mobile, We...
Pactera Cybersecurity - Application Security Penetration Testing - Mobile, We...Pactera Cybersecurity - Application Security Penetration Testing - Mobile, We...
Pactera Cybersecurity - Application Security Penetration Testing - Mobile, We...
 
8 Access Control
8 Access Control8 Access Control
8 Access Control
 
Audit Checklist for Information Systems
Audit Checklist for Information SystemsAudit Checklist for Information Systems
Audit Checklist for Information Systems
 

Ähnlich wie DevOpsCon 2016 - Continuous Security Testing - Stephan Kaps

Integration von Security-Checks in die CI-Pipeline
Integration von Security-Checks in die CI-PipelineIntegration von Security-Checks in die CI-Pipeline
Integration von Security-Checks in die CI-Pipeline
OPEN KNOWLEDGE GmbH
 
Integration von Security-Checks in die CI-Pipeline
Integration von Security-Checks in die CI-PipelineIntegration von Security-Checks in die CI-Pipeline
Integration von Security-Checks in die CI-Pipeline
OPEN KNOWLEDGE GmbH
 
Apache Solr vs. Elasticsearch - And The Winner Is...! Ein Vergleich der Shoot...
Apache Solr vs. Elasticsearch - And The Winner Is...! Ein Vergleich der Shoot...Apache Solr vs. Elasticsearch - And The Winner Is...! Ein Vergleich der Shoot...
Apache Solr vs. Elasticsearch - And The Winner Is...! Ein Vergleich der Shoot...
SHI Search | Analytics | Big Data
 
PHP Summit 2013 - Make or Buy?
PHP Summit 2013 - Make or Buy?PHP Summit 2013 - Make or Buy?
PHP Summit 2013 - Make or Buy?
Sebastian Heuer
 
HTML5 Offline - Fallstricke für mobile Webseiten und WebApps
HTML5 Offline - Fallstricke für mobile Webseiten und WebAppsHTML5 Offline - Fallstricke für mobile Webseiten und WebApps
HTML5 Offline - Fallstricke für mobile Webseiten und WebApps
Ulrich Schmidt
 
Go on a Bughunt in production, but without a map! @ JavaLand 2023
Go on a Bughunt in production, but without a map! @ JavaLand 2023Go on a Bughunt in production, but without a map! @ JavaLand 2023
Go on a Bughunt in production, but without a map! @ JavaLand 2023
QAware GmbH
 
Herstellerunabhängige RZ Automatisierung mit orcharhino
Herstellerunabhängige RZ Automatisierung mit orcharhinoHerstellerunabhängige RZ Automatisierung mit orcharhino
Herstellerunabhängige RZ Automatisierung mit orcharhino
ATIX AG
 
Warum Monitoring und warum Icinga 2 (Webinar vom 04.12.2013)
Warum Monitoring und warum Icinga 2 (Webinar vom 04.12.2013)Warum Monitoring und warum Icinga 2 (Webinar vom 04.12.2013)
Warum Monitoring und warum Icinga 2 (Webinar vom 04.12.2013)
NETWAYS
 
IT-Sicherheit und agile Entwicklung? Geht das? Sicher!
IT-Sicherheit und agile Entwicklung? Geht das? Sicher!IT-Sicherheit und agile Entwicklung? Geht das? Sicher!
IT-Sicherheit und agile Entwicklung? Geht das? Sicher!
Carsten Cordes
 
Ceph Introduction @GPN15
Ceph Introduction @GPN15Ceph Introduction @GPN15
Ceph Introduction @GPN15
m1no
 
DevSecOps .pptx
DevSecOps .pptxDevSecOps .pptx
DevSecOps .pptx
ChristianBauer61
 
Cloud Deployment und (Auto)Scaling am Beispiel von Angrybird
Cloud Deployment und (Auto)Scaling am Beispiel von AngrybirdCloud Deployment und (Auto)Scaling am Beispiel von Angrybird
Cloud Deployment und (Auto)Scaling am Beispiel von Angrybird
AOE
 
Das kleine Einmaleins der sicheren Architektur
Das kleine Einmaleins der sicheren ArchitekturDas kleine Einmaleins der sicheren Architektur
Das kleine Einmaleins der sicheren Architektur
QAware GmbH
 
OSMC 2014 | Icinga Web 2 kann mehr by Thomas Gelf
OSMC 2014 | Icinga Web 2 kann mehr by Thomas GelfOSMC 2014 | Icinga Web 2 kann mehr by Thomas Gelf
OSMC 2014 | Icinga Web 2 kann mehr by Thomas Gelf
NETWAYS
 
Das kleine Einmaleins der sicheren Architektur @heise_devSec
Das kleine Einmaleins der sicheren Architektur @heise_devSecDas kleine Einmaleins der sicheren Architektur @heise_devSec
Das kleine Einmaleins der sicheren Architektur @heise_devSec
Mario-Leander Reimer
 
2005 - NRW Conf: Design, Entwicklung und Tests
2005 - NRW Conf: Design, Entwicklung und Tests2005 - NRW Conf: Design, Entwicklung und Tests
2005 - NRW Conf: Design, Entwicklung und Tests
Daniel Fisher
 
OSMC 2014: Icinga Web 2 kann mehr | Thomas Gelf
OSMC 2014: Icinga Web 2 kann mehr | Thomas GelfOSMC 2014: Icinga Web 2 kann mehr | Thomas Gelf
OSMC 2014: Icinga Web 2 kann mehr | Thomas Gelf
NETWAYS
 
Backend-Services mit Rust
Backend-Services mit RustBackend-Services mit Rust
Backend-Services mit Rust
Jens Siebert
 
Docker und Kubernetes Patterns & Anti-Patterns
Docker und Kubernetes Patterns & Anti-PatternsDocker und Kubernetes Patterns & Anti-Patterns
Docker und Kubernetes Patterns & Anti-Patterns
Josef Adersberger
 
Docker und Kubernetes Patterns & Anti-Patterns
Docker und Kubernetes Patterns & Anti-PatternsDocker und Kubernetes Patterns & Anti-Patterns
Docker und Kubernetes Patterns & Anti-Patterns
QAware GmbH
 

Ähnlich wie DevOpsCon 2016 - Continuous Security Testing - Stephan Kaps (20)

Integration von Security-Checks in die CI-Pipeline
Integration von Security-Checks in die CI-PipelineIntegration von Security-Checks in die CI-Pipeline
Integration von Security-Checks in die CI-Pipeline
 
Integration von Security-Checks in die CI-Pipeline
Integration von Security-Checks in die CI-PipelineIntegration von Security-Checks in die CI-Pipeline
Integration von Security-Checks in die CI-Pipeline
 
Apache Solr vs. Elasticsearch - And The Winner Is...! Ein Vergleich der Shoot...
Apache Solr vs. Elasticsearch - And The Winner Is...! Ein Vergleich der Shoot...Apache Solr vs. Elasticsearch - And The Winner Is...! Ein Vergleich der Shoot...
Apache Solr vs. Elasticsearch - And The Winner Is...! Ein Vergleich der Shoot...
 
PHP Summit 2013 - Make or Buy?
PHP Summit 2013 - Make or Buy?PHP Summit 2013 - Make or Buy?
PHP Summit 2013 - Make or Buy?
 
HTML5 Offline - Fallstricke für mobile Webseiten und WebApps
HTML5 Offline - Fallstricke für mobile Webseiten und WebAppsHTML5 Offline - Fallstricke für mobile Webseiten und WebApps
HTML5 Offline - Fallstricke für mobile Webseiten und WebApps
 
Go on a Bughunt in production, but without a map! @ JavaLand 2023
Go on a Bughunt in production, but without a map! @ JavaLand 2023Go on a Bughunt in production, but without a map! @ JavaLand 2023
Go on a Bughunt in production, but without a map! @ JavaLand 2023
 
Herstellerunabhängige RZ Automatisierung mit orcharhino
Herstellerunabhängige RZ Automatisierung mit orcharhinoHerstellerunabhängige RZ Automatisierung mit orcharhino
Herstellerunabhängige RZ Automatisierung mit orcharhino
 
Warum Monitoring und warum Icinga 2 (Webinar vom 04.12.2013)
Warum Monitoring und warum Icinga 2 (Webinar vom 04.12.2013)Warum Monitoring und warum Icinga 2 (Webinar vom 04.12.2013)
Warum Monitoring und warum Icinga 2 (Webinar vom 04.12.2013)
 
IT-Sicherheit und agile Entwicklung? Geht das? Sicher!
IT-Sicherheit und agile Entwicklung? Geht das? Sicher!IT-Sicherheit und agile Entwicklung? Geht das? Sicher!
IT-Sicherheit und agile Entwicklung? Geht das? Sicher!
 
Ceph Introduction @GPN15
Ceph Introduction @GPN15Ceph Introduction @GPN15
Ceph Introduction @GPN15
 
DevSecOps .pptx
DevSecOps .pptxDevSecOps .pptx
DevSecOps .pptx
 
Cloud Deployment und (Auto)Scaling am Beispiel von Angrybird
Cloud Deployment und (Auto)Scaling am Beispiel von AngrybirdCloud Deployment und (Auto)Scaling am Beispiel von Angrybird
Cloud Deployment und (Auto)Scaling am Beispiel von Angrybird
 
Das kleine Einmaleins der sicheren Architektur
Das kleine Einmaleins der sicheren ArchitekturDas kleine Einmaleins der sicheren Architektur
Das kleine Einmaleins der sicheren Architektur
 
OSMC 2014 | Icinga Web 2 kann mehr by Thomas Gelf
OSMC 2014 | Icinga Web 2 kann mehr by Thomas GelfOSMC 2014 | Icinga Web 2 kann mehr by Thomas Gelf
OSMC 2014 | Icinga Web 2 kann mehr by Thomas Gelf
 
Das kleine Einmaleins der sicheren Architektur @heise_devSec
Das kleine Einmaleins der sicheren Architektur @heise_devSecDas kleine Einmaleins der sicheren Architektur @heise_devSec
Das kleine Einmaleins der sicheren Architektur @heise_devSec
 
2005 - NRW Conf: Design, Entwicklung und Tests
2005 - NRW Conf: Design, Entwicklung und Tests2005 - NRW Conf: Design, Entwicklung und Tests
2005 - NRW Conf: Design, Entwicklung und Tests
 
OSMC 2014: Icinga Web 2 kann mehr | Thomas Gelf
OSMC 2014: Icinga Web 2 kann mehr | Thomas GelfOSMC 2014: Icinga Web 2 kann mehr | Thomas Gelf
OSMC 2014: Icinga Web 2 kann mehr | Thomas Gelf
 
Backend-Services mit Rust
Backend-Services mit RustBackend-Services mit Rust
Backend-Services mit Rust
 
Docker und Kubernetes Patterns & Anti-Patterns
Docker und Kubernetes Patterns & Anti-PatternsDocker und Kubernetes Patterns & Anti-Patterns
Docker und Kubernetes Patterns & Anti-Patterns
 
Docker und Kubernetes Patterns & Anti-Patterns
Docker und Kubernetes Patterns & Anti-PatternsDocker und Kubernetes Patterns & Anti-Patterns
Docker und Kubernetes Patterns & Anti-Patterns
 

DevOpsCon 2016 - Continuous Security Testing - Stephan Kaps

  • 1. Stephan Kaps | Bundesversicherungsamt Continuous Security Testing
  • 6. Stephan Kaps Techn. Projektleiter Software-Architekt JEE – SOA - Host Java seit 2002Speaker & Autor ISTQB, ISAQB, IREB und ITIL zertifiziert Leidenschaft sind neue Technologien und Methoden
  • 7. • Was ist das? • Warum machen wir das? • Wie fängt man an? • Das Projekt • Maturity Model • Ausblick • Fazit Agenda
  • 9. Continuous Security Testing bedeutet: statische und dynamische Analysen bereits während der Entwicklung durchzuführen, um frühzeitig und regelmäßig Sicherheitsmaßnahmen umzusetzen, bevor manuelle Prüfungen wie Penetrationstests zum Einsatz kommen Was ist das?
  • 10. • Secure Coding Guide • Integration in Build-Prozess (SDLC) • Automatisierung (wenn möglich) • Zusammenarbeit von Entwicklung, Betrieb und Sicherheitsbeauftragten (SecDevOps) Im Detail
  • 13. • Wir müssen – ISO 2700x, BSI Grundschutz • Wir wollen – proaktiv werden – Mysterium enträtseln • „moving security to the left!“ Warum machen wir das?
  • 14. Warum machen wir das? Bisher
  • 15. Warum machen wir das? Bisher Bei Continous Delivery
  • 18. • Verfügbare Informationsquellen – OWASP Top 10 – MITRE Top 25 • Schwachstellen (CWE) • Attacken (CAPEC) – Web Application Security Consortium (WASC) Wie fängt man an?
  • 23. • Java Web-Anwendungen: – Als Basis die TOP 10 des OWASP – Schwachstellen zu den einzelnen Risiken • eindeutige Vorgaben formulieren • Testbar durch statische Analysen • Integration in Build-Prozess möglich Konkret
  • 25. • Erstellung und Etablierung von Programmierrichtlinien zur sicheren Softwareentwicklung • Schneller Start mit Quick Wins • Umsetzung mit wenig Aufwand möglich • Richtlinien sollen leicht und schnell testbar sein Ziele
  • 27. Richtlinien Nr Beschreibung Risiko Verwundbarkeit /Schwachstelle Attacken testbar durch 1 Verhindere das Injizieren von Schadcode in SQL-Befehlen A1 - OWASP Top10 2013 WASC-20 CWE-20 CWE-89 WASC-19 CAPEC-66 FindSecBugs 2 Verwende keine hart kodierten Passwörter A2 - OWASP Top10 2013 CWE-798 CWE-259 CWE-321 FindSecBugs 3 Verwende sicheres Session-Management A2 - OWASP Top10 2013 CWE-613 CWE-614 WASC-47 CAPEC-21 web.xml Check 4 Verwende keine vorhersagbaren Zufallszahlen-Generatoren A2 - OWASP Top10 2013 CWE-6 CWE-330 CAPEC-21 CAPEC-112 WASC-11 FindSecBugs 5 Verhindere den unerlaubten Zugriff auf Dateien durch Pfad-Manipulationen A4 - OWASP Top10 2013 CWE-22 WASC-33 CAPEC-126 FindSecBugs 6 Vermeide die Anzeige von technischen Fehlermeldungen A5 - OWASP Top10 2013 CWE-209 WASC-14 CAPEC-54 web.xml Check 7 Verwende keine schwachen kryptografischen Algorithmen A6 - OWASP Top10 2013 CWE-326 CWE-327 CWE-261 CAPEC-55 CAPEC-112 FindSecBugs 8 Verwende ausreichend lange Schlüssel A8 - OWASP Top10 2013 CWE-6 CAPEC-21 web.xml Check 9 Verwende keine 3rd-Party Libraries mit bekannten Verwundbarkeiten A9 - OWASP Top10 2013 diverse: injection, broken access control, XSS, etc. entsprechend den Verwundbarkeiten Dependency Check 10 Verhindere das unzulässige Umleiten zu anderen URLs A10 - OWASP Top 10 2013 CWE-601 CAPEC-194 WASC-38 FindSecBugs
  • 28. Verhindere das Injizieren von Schadcode in SQL-Befehlen Beispiel
  • 29. • Ursache: – Ungeprüfte Übernahme von Usereingaben oder Input-Parametern in SQL-Abfragen • Auswirkung: – Ausführung unberechtigter Abfragen oder Manipulation von Daten Beispiel: SQL Injection
  • 30. • Kann verhindert werden durch: – Verwendung von Prepared Statements – Verwendung von Hibernate Criteria Beispiel: SQL Injection
  • 31. Vermeide die Anzeige von technischen Fehlermeldungen Beispiel II
  • 32. • Ursache: – Technische Fehlermeldungen werden bis zum Anwender durchgereicht • Auswirkung: – Sensible Informationen über eine Anwendung, die Infrastruktur oder verarbeitete Daten werden für Unberechtigte sichtbar Beispiel: techn. Fehlermeldungen
  • 33. • Kann verhindert werden durch: – Definition von Standard-Error-Pages in der web.xml – Ausgabe von StackTraces in separate Log-Dateien Beispiel: techn. Fehlermeldungen
  • 34. Integration in den Build-Prozess
  • 35. • FindSecBugs (http://h3xstream.github.io/find-sec-bugs/) • OWASP Dependency Check (https://www.owasp.org/index.php/OWASP_Dependency_Check) • Web.xml Checker Demnächst https://github.com/kitenco Tools
  • 43. No work for Devs
  • 46. 4 verschiedene Axen Dynamische Tiefe 4 3 2 1 1 2 3 4 Intensität Konsolidierung 4 3 2 1 1 2 3 4 Statische Tiefe
  • 47. Statische Tiefe 1 • Third-Party Libraries überprüfen • Tool: OWASP Dependency Check, retire.js für JavaScript 2 • Wichtigen Code scannen • Tool: FindSecBugs, ScanJS 3 • Kompletten Code scannen • Tool: FindSecBugs, ScanJS 4 • Source-Code der Third-Party Libraries scannen • Tool: FindSecBugs, ScanJS
  • 48. Dynamische Tiefe 1 • public attack surface (pre-auth) • Tool: Spider (z.B. ZAP, Arachni, BDD-Security) 2 • Scan über GUI (authenticated, post-auth) • Tool: Spider (ZAP + Session Properties, Selenium) 3 • Separates Scannen einzelner Layer • Tool: ZAP (z.B. bei internen Web-Service Aufrufen) 4 • Gezieltes, individuelles Scannen • Tool: Selenium Tests über ZAP oder BDD-Security
  • 49. Intensität 1 • Dynamisch: Passives Scannen • Statisch: Einsatz des Standard-Regelwerks 2 • Dynamisch: leichtgewichtige aktive Scanns • Statisch: Anpassung des Standard-Regelwerks 3 • Dynamisch: schwergewichtige Scanns für wichtige Bereiche • Statisch: FindSecBugs Threshold=Low, Effort=Max 4 • Dynamisch: schwergewichtige Scanns für alle Bereiche • Statisch: Customized rule sets
  • 50. Konsolidierung 1 • Erzeuge HTML Reports • Anzeige im Jenkins 2 • Definition von Quality Gates 3 • Duplikate diverser Tools konsolidieren • Tickets im Bug-Tracker erzeugen 4 • Code coverage of security tests • z.B. OWASP Code Pulse -> dann Reviews
  • 51. • Level 3-4Statische Tiefe • Level 0Dynamische Tiefe • Level 3-4Intensität • Level 2Konsolidierung Dieses Projekt erreicht ...
  • 53. • Weitere Programmier-Richtlinien aufstellen • Dazugehörige Tests entwickeln und in den Build-Prozess aufnehmen • KVP! Ausblick
  • 55. 1. Verify for Security Early and Often 2. Parameterize Queries 3. Encode Data 4. Validate All Inputs 5. Implement Identity and Authentication Controls 6. Implement Appropriate Access Controls 7. Protect Data 8. Implement Logging and Intrusion Detection 9. Leverage Security Frameworks and Libraries 10.Error and Exception Handling OWASP Proactive Controls
  • 56. • ZAP (Zed Attack Proxy) by OWASP – https://www.owasp.org/index.php/OWASP_ Zed_Attack_Proxy_Project • BDD-Security (ContinuumSecurity) – http://www.continuumsecurity.net • Arachni Scanner – http://www.arachni-scanner.com/ Dynamische Analysen (DAST)
  • 60. Scenario: Issue a new session ID after authentication
  • 61. • Apache Shiro – http://shiro.apache.org • OWASP ESAPI – https://www.owasp.org/index.php/Category :OWASP_Enterprise_Security_API • JBoss Keycloak – http://www.keycloak.org Security Frameworks
  • 63. • OWASP Java Encoder – https://www.owasp.org/index.php/OWASP_ Java_Encoder_Project • Google Keyczar – https://github.com/google/keyczar • OWASP Code Pulse – https://www.owasp.org/index.php/OWASP_ Code_Pulse_Project Weitere Tools
  • 64. Bald… • SecureCodeBox von Iteratec • Docker Container zu Security Test Farm https://www.iteratec.de/themen/securecodebox/
  • 66. Fazit
  • 67. • Aufstellen von Richtlinien, die durch eine kurze und präzise Erläuterung verstanden werden • Einführung von kleinen Tools, die sich in den Build- Prozess integrieren lassen und somit kontinuierlich und am besten automatisiert die Einhaltung der Richtlinien verifizieren. Wichtige Erfolgskriterien
  • 68. • Ausführung dynamischer Tests kann sehr viel Zeit in Anspruch nehmen • Nicht bei jedem Build-Lauf möglich • Oder weniger Auslieferungen ABER
  • 69. Nur wenn sich Security Testing nahtlos in den Entwicklungs-Workflow integriert, indem Security Bugs genauso aufgespürt, verwaltet und behoben werden wie andere Bugs, dann wird dieses Instrument auch von Entwicklern akzeptiert und die Art und Weise, wie sichere Software entwickelt wird, positiv beeinflusst. Fazit
  • 70. Artikel zum Vortrag erschienen in der ObjektSpektrum 4/2015
  • 72. work just simply smarter ● Continuous Delivery ● Application Lifecycle Management ● Social- Collaboration ● Vorträge ● Artikel ● PoCs ● JIRA ● Jenkins ● Confluence ● Schulung ● Coaching ● Training
  • 73. Suppression of False Positives • BDD-Security – Use false positive tables in story files • FindSecurityBugs – Use exclusion lists in config (XML filter files) – Use annotation @SuppressWarnings on false positive code lines • Dependency-Check – XML file of suppressions (checked-in along with the project)