O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

DevOpsCon 2016 - Continuous Security Testing - Stephan Kaps

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.

  • Entre para ver os comentários

DevOpsCon 2016 - Continuous Security Testing - Stephan Kaps

  1. 1. Stephan Kaps | Bundesversicherungsamt Continuous Security Testing
  2. 2. Unbekannt, http://rachaelandtom.info/gallery/v/falken-random/random-pics/kurios119.jpg.html
  3. 3. © Christian Schneider
  4. 4. © Christian Schneider
  5. 5. Mögliche Lösung: Continuous Security Testing
  6. 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. 7. • Was ist das? • Warum machen wir das? • Wie fängt man an? • Das Projekt • Maturity Model • Ausblick • Fazit Agenda
  8. 8. Was ist das?
  9. 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. 10. • Secure Coding Guide • Integration in Build-Prozess (SDLC) • Automatisierung (wenn möglich) • Zusammenarbeit von Entwicklung, Betrieb und Sicherheitsbeauftragten (SecDevOps) Im Detail
  11. 11. #SecDevOps
  12. 12. Warum machen wir das?
  13. 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. 14. Warum machen wir das? Bisher
  15. 15. Warum machen wir das? Bisher Bei Continous Delivery
  16. 16. Wie fängt man an?
  17. 17. Verstehen! Angriffe Verwundbarkeiten Fehler Schwachstellen Attacken
  18. 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. 19. WASC Katalog
  20. 20. Zusammenhang
  21. 21. Ein Beispiel
  22. 22. • 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
  23. 23. Das Projekt
  24. 24. • 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
  25. 25. Der Plan
  26. 26. 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
  27. 27. Verhindere das Injizieren von Schadcode in SQL-Befehlen Beispiel
  28. 28. • Ursache: – Ungeprüfte Übernahme von Usereingaben oder Input-Parametern in SQL-Abfragen • Auswirkung: – Ausführung unberechtigter Abfragen oder Manipulation von Daten Beispiel: SQL Injection
  29. 29. • Kann verhindert werden durch: – Verwendung von Prepared Statements – Verwendung von Hibernate Criteria Beispiel: SQL Injection
  30. 30. Vermeide die Anzeige von technischen Fehlermeldungen Beispiel II
  31. 31. • 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
  32. 32. • Kann verhindert werden durch: – Definition von Standard-Error-Pages in der web.xml – Ausgabe von StackTraces in separate Log-Dateien Beispiel: techn. Fehlermeldungen
  33. 33. Integration in den Build-Prozess
  34. 34. • 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
  35. 35. FindSecBugs Report
  36. 36. Jenkins Report
  37. 37. Web.xml Checker
  38. 38. Code-Beispiel auf Github https://github.com/kitenco/security-test
  39. 39. Xanitizer.com
  40. 40. No work for Devs
  41. 41. Maturity Model
  42. 42. © Christian Schneider
  43. 43. 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
  44. 44. 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
  45. 45. 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
  46. 46. 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
  47. 47. 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
  48. 48. • Level 3-4Statische Tiefe • Level 0Dynamische Tiefe • Level 3-4Intensität • Level 2Konsolidierung Dieses Projekt erreicht ...
  49. 49. Ausblick
  50. 50. • Weitere Programmier-Richtlinien aufstellen • Dazugehörige Tests entwickeln und in den Build-Prozess aufnehmen • KVP! Ausblick
  51. 51. https://www.owasp.org/index.php/OWASP_Proactive_Controls
  52. 52. 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
  53. 53. • 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)
  54. 54. Zed Attack Proxy (ZAP)
  55. 55. BDD-Security
  56. 56. Scenario: Issue a new session ID after authentication
  57. 57. • 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
  58. 58. • 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
  59. 59. Bald… • SecureCodeBox von Iteratec • Docker Container zu Security Test Farm https://www.iteratec.de/themen/securecodebox/
  60. 60. Fazit
  61. 61. • 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
  62. 62. • Ausführung dynamischer Tests kann sehr viel Zeit in Anspruch nehmen • Nicht bei jedem Build-Lauf möglich • Oder weniger Auslieferungen ABER
  63. 63. 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
  64. 64. Artikel zum Vortrag erschienen in der ObjektSpektrum 4/2015
  65. 65. Noch Fragen? http://www.kitenco.de info@kitenco.de | @kitenco1 Vielen Dank
  66. 66. work just simply smarter ● Continuous Delivery ● Application Lifecycle Management ● Social- Collaboration ● Vorträge ● Artikel ● PoCs ● JIRA ● Jenkins ● Confluence ● Schulung ● Coaching ● Training
  67. 67. 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)

×