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

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

RichtlinienNr 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 CheckerDemnächst https://github.com/kitenco

Tools

FindSecBugs Report

Jenkins Report

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)

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

• 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/

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)