Continuous Delivery (CD) ist in aller Munde. Zu Recht, doch wollen wir unsere Software kontinuierlich ausliefern, müssen wir auch kontinuierlich Sicherheitstests durchführen. 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. Um eine Anwendung bereits während der Entwicklung auf das Vorhandensein sicherheitskritischer Schwachstellen hin überprüfen zu können, ist eine Integration in den Entwicklungsprozess und somit eine kontinuierliche und am besten automatisierte Prüfung notwendig. Der Vortrag stellt die praktischen Erfahrungen aus einem Projekt vor, bei dem Sicherheitsrichtlinien (Secure Coding Guide) für die eigene Entwicklung von Java-Webanwendungen aufgestellt und Sicherheitstests in den Softwareentwicklungsprozess integriert wurden. Dabei wird auf die organisatorischen, inhaltlichen und technischen Überlegungen eingegangen.

1. Stephan Kaps | Bundesversicherungsamt
Continuous Security Testing

2. Unbekannt, http://rachaelandtom.info/gallery/v/falken-random/random-pics/kurios119.jpg.html

3. © Christian Schneider

4. © Christian Schneider

5. Mögliche Lösung:
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

8. Was ist das?

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

11. #SecDevOps

12. Warum machen wir das?

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

16. Wie fängt man an?

17. Verstehen!
Angriffe
Verwundbarkeiten
Fehler
Schwachstellen
Attacken

18. • Verfügbare Informationsquellen
– OWASP Top 10
– MITRE Top 25
• Schwachstellen (CWE)
• Attacken (CAPEC)
– Web Application Security
Consortium (WASC)
Wie fängt man an?

19. WASC Katalog

21. Zusammenhang

22. Ein Beispiel

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

24. Das Projekt

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

26. Der Plan

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

36. FindSecBugs Report

38. Jenkins Report

40. Web.xml Checker

41. Code-Beispiel auf Github
https://github.com/kitenco/security-test

42. Xanitizer.com

43. No work for Devs

44. Maturity Model

45. © Christian Schneider

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 ...

52. Ausblick

53. • Weitere Programmier-Richtlinien aufstellen
• Dazugehörige Tests entwickeln und in den
Build-Prozess aufnehmen
• KVP!
Ausblick

54. https://www.owasp.org/index.php/OWASP_Proactive_Controls

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)

57. Zed Attack Proxy (ZAP)

59. BDD-Security

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

71. Noch Fragen?
http://www.kitenco.de
info@kitenco.de | @kitenco1
Vielen Dank

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)