Continuous Security in Modernen Webanwendungen
Sicherheit eingebaut
Martin Reinhardt (Holisticon AG)
@mreinhardt
Agenda
Continuous Delivery
IT-Sicherheit
Continuous Security
Ausblick
Links
About me
Martin Reinhardt (Holisticon AG)
Continuous Delivery
Agile Softwareentwicklung arbeitet kleinteilig
Software oft und zuverlässig in Produktion
Software mit agilen Methoden kann nicht komplett (manuell) getestet werde
Alle 2 Wochen gesamten Funktionsumfang abtesten ist utopisch
Wesentlich ist dabei die Build Pipeline
Wie?
Geschwindigkeit
Automatisierung
Pipeline mehrmals durchlaufen
jeder einzelnen Schritt der Pipeline schnell und zuverlässig
wird durch Automatisierung erreicht
Schritte
Entwicklung
Qualitätssicherung
Auslieferung
Tests liefern schnelles Feedback über Seiteneffekte und Regressionen
Deployment auf Knopfdruck und innerhalb von Minuten auf dem Produktionssystem
Pipeline wird mit jeder Änderung durchlaufen
neuer Softwarestand hinein
qualitätsgesichertes, produktionsreifes und installierbares Softwarepaket
Build Pipeline
wesentliches Ziel ist schnelles Feedback, also Geschwindigkeit
Einzelne Schritt schnell abarbeiten (5 - 10 Minuten)
Möglichst früh Fehler finden (Unit-Tests )
Quellcode muss Continuous Delivery gerecht werden
Warum nicht auch für Security?
Continuous Delivery auch eine Chance für Sicherheitsaspekte
Feature Toggles
Einer der Grundsätze des Continuous Integration besagt, dass es lediglich einen Master-Branch und keine weiteren Feature-Branches geben soll, in den der Code eingecheckt und damit eben diese Merge-Hölle vermieden wird.
IT-Sicherheit
Warum das Ganze?
NSA
BDSG
DSGVO
Kosten
Exploits
CVE-2016-5000 - Apache POI Information Disclosure via External Entity Expansion (XXE)
CVE-2016-4216 - Adobe XMP Toolkit for Java Information Disclosure via External Entity Expansion (XXE)
CVE-2016-3081 - Remote code execution vulnerability in Apache Struts when dynamic method invocation is enabled
CVE-2015-8103 - Remote code execution vulnerability in Jenkins remoting; related to the Apache commons-collections
Black Duck - Open Source Security Analysis
Stand von Open Source Security in kommerziellen Anwendungen bit.ly/2yfsD2x
95% der Anwendungen enthalten OSS
67% der Anwendungen enhalten OSS Schwachstellen
Durchschnittsalter von bekannten Schwachstellen in OSS: 1894 Tage
OWASP Top 10
Kritischsten Risiken in Webanwendungen
A9 - Nutzung von Komponenten mit bekannten Schwachstellen
Schwer zu erkennen
Bewusstsein auf Entwicklungsseite
Sichtbarkeit
Toolunterstützung nicht vorhanden
Patching erfordert erneut Codeänderungen
Arten von Tests
Funktionale Sicherheitstests
Schwachstellen-Scanning / Fuzzing
Penetrationstests
Funktionale Sicherheitstests Wir evaluieren alle sicherheitsrelevanten Funktionen des Systems und überprüfen die Einhaltung von Spezifikationen und Standards. Wir überprüfen auch das Verhalten von Algorithmen und die Widerstandsfähigkeit der Implementierung (z. B. Stresstests).
Schwachstellen-Scanning / Fuzzing Wir testen auf bekannte Schwachstellen in Ihren Systemen, indem wir White Box (Codeanalyse), Black Box (Scanning) und Fuzzing-Methoden anwenden.
Penetrationstests Auf System- und Geräteebene führen wir Penetrationstests an eingebetteten Systemen, Webanwendungen, IT- und Spezialsystemen (z.B. SAP, Industrial Control Systems) durch.
Continuous Security
Testen ist nicht alles, bei Entwicklung auch nicht
Warum also nicht auch bei Security?
logischer Schritt für Automatisierung
Security muss auf verschieden Ebenen betrachtet werden
Code & Architektur (Sonar)
Integrations-Tests (bdd-security, zap, owasp)
Bei Softwareentwicklung auch nicht, Planning etc ...
Methodik
Code Reviews
Konferenzen
Bücher
Security ganzheitlich
Thema einarbeiten
Erstellung von Security Guidelines
Berücksichtigung von Sicherheit im Rahmen der Erstellung von User Stories
Codescans durchführen
Peer-Reviews durch einen Security Champion durchführen
Penetrationstests einplanen
Planing
Secure Scrum
Thread Model
Analog zur restlichen Softwareentwicklung
An nahezu allen Stellen lassen sich Sicherheitsaspekte berücksichtigen. So können User-Stories für die Härtung geschrieben werden oder auch in fachlichen Anforderungen sicherheitsrelevante Punkte berücksichtigt werden. Es ist generell gerade in größeren Projekten ratsam die Rolle des Security Champions zu besetzen und ggf. auch ein- oder mehrere Security-Sprints einzuplanen. Für das methodische Grundgerüst gibt es also verschiedene Punkte die es zu beachten gilt:
Security Aspekte
Methodik + Testen + Konzeption = gute Software
Secure Scrum
Setzt auf eigentliche Scrum-Prozess auf
Security relevante User-Stories im Team identifizieren
Jede User-Story mit Loss-Value versehe und mit S-Marks gekennzeichnet
S-Marks verweisen auf S-Tag
beschreibt das entsprechende Security-Problem als auch mögliche Lösungsansätze
Wird User Story mit einem S-Mark implementiert, muss im selben Sprint der entsprechende S-Tag implementiert werden
Alternativ: Security Backlog im regulären Sprint
NOTES-->
Loss-Value = Verlust der entsteht, wenn die Funktionalität dieser User-Story erfolgreich angegriffen bzw. Daten manipuliert/entwendet
THE SECURE SCRUM METHODOLOGY
Figure 1 – Integration of Secure Scrum components into standard Scrum. Christophe Pohl and Hans-Joachim Hof, 2015.
Identification is the process which diagnoses potential security concerns throughout the application development process. Practically, this is accomplished by marking items in the Product Backlog when security concerns are discovered. The identification process occurs during Product Backlog creation, Product Backlog Refinement, Sprint Planning, and Sprint Review.
Implementation is the process which ensures security concerns are properly understood by the development team and is carried out during Sprint Planning and Daily Scrum meetings.
Verification evaluates an application’s security is run during Daily Scrums.
Definition of Done represents a criteria which establishes the threshold for completion with regards to resolving an application security concern. Source: (Christoph Pohl and Hans-Joachim Hof 2015)
Schritte gebräuchlich im Security Kontext
Identification = Angriffsvektoren
Defining and linking security risks to user stories in a product backlog by marking stories which contain security risks with an “S-Mark” and then describing that concern with “S-Tags” represents the core of the Secure Scrum methodology. Adding an S-Mark and related S-Tags to a user story indicates that a security concern has beenidentified, described, and formally recognized by the development team. S-Tags provide standardized definitions of specific security concerns flagged by an S-Mark. For example, attaching an S-Tag to an S-Marked user story labelled “XSS” represents a potential Cross Site Scripting attack allows developers, including those with no security training, to understand what security risks are present and the path to their mitigation. The success of this methodology was initially confirmed in field tests where university students employing Secure Scrum produced more secure code than the control groups who did not. By guiding developers through identification, implementation, verification, and also the process which defines the conditions of completion, Secure Scrum succeeds in contributing to the development of secure applications.
Continuous Security Testing
Tools mittlerweile verfügbar
meist setzen diese auf OWASP auf
Integration nicht schwieriger als bei DevOps
Node Security Project (NSP)
Prüfung der Abhängigkeiten auf bekannte Schwachstellen
Schlägt korrigierte Version vor
┌───────────────┬───────────────────────────────────────┐
│ │ Insecure Defaults Allow MITM Over TLS │
├───────────────┼───────────────────────────────────────┤
│ Name │ engine.io-client │
├───────────────┼───────────────────────────────────────┤
│ Installed │ 1.5 .4 │
├───────────────┼───────────────────────────────────────┤
│ Vulnerable │ <= 1.6 .8 │
├───────────────┼───────────────────────────────────────┤
│ Patched │ >= 1.6 .9 │
├───────────────┼───────────────────────────────────────┤
│ More Info │ https:
└───────────────┴───────────────────────────────────────┘
OWASP dependency-check
Seit 2012 verfügbar (basiert auf A9 - Komponenten mit bekannten Schwachstellen )
Verfügbar in verschiedenen Varianten: Ant, Maven, Gradle, SBT, Jenkins
Analyse der Abhängigkeiten zu bekannten Schwachstellen für Java & .NET
Experimentielle Unterstützung
CocoaPods
Swift Package Manager
Python
PHP (composer)
Node.js
Ruby
Prinzipiell kann jede gefundenen Schwachstelle zu Buildfehler führen
[ERROR] Failed to execute goal org.owasp:dependency-check -maven:1.4 .0 :check (default ) ...
[ERROR ]
[ERROR ] Dependency-Check Failure :
[ERROR ] One or more dependencies were identified with vulnerabilities
that have a CVSS score greater then '5.0' :
[ERROR ] commons-httpclient-3.1 .jar: CVE-2014 -3577
[ERROR ] mysql-connector-java -5.1 .37 .jar: CVE-2014 -0001 , CVE-2013 -2378 , ....
[ERROR ] tomcat-embed-core-8.0 .33 .jar: CVE-2016 -3092 , CVE-2013 -2185 , CVE-2002 -0493
Nicht praktikabel, deswegen sind Ausnhamen nötig
Kann reduzierter Common Vulnerability Scoring System-Score (CVSS) gewählt werden
Ausnahmen festlegen
HTML - Report
Mit festgelegten Ausnahmen
Ausnahmen werden in eigenem XML-Format festgelegt
<suppress >
<notes >
<![CDATA[This suppresses false positives identified on spring security. ]]>
</notes >
<gav regex ="true" > org\.springframework\.security:spring.*</gav >
<cpe > cpe:/a:mod_security:mod_security</cpe >
<cpe > cpe:/a:springsource:spring_framework</cpe >
<cpe > cpe:/a:vmware:springsource_spring_framework</cpe >
</suppress >
OWASP Zed Attack Proxy (ZAP)
Features
Intercepting Proxy
Automated Scanner
Passive Scanner
Brute Force Scanner
Fuzzer
Port Scanner
Spider
Web Sockets
REST API Scanning (OpenAPI/Swagger)
Can use OpenAPI spec
Selenium Proxy
Funktionsweise
Installation auf separaten Umgebung
Scan der Anwendung
Proxy während Testausführung
Integration in Pipeline
Integration in Build
Einfache Integration
Erweiterung möglich (Selenium Tests)
<plugin>
<groupId> de.martinreinhardt-online</groupId>
<artifactId> zap-maven-plugin</artifactId>
<configuration>
<zapHost> localhost</zapHost>
<zapPort> 44444 </zapPort>
<failingRiskCodeThreshold> 5 </failingRiskCodeThreshold>
<targetUrl> http://ngspring:41180 /</targetUrl>
<authenticationType> form</authenticationType>
<username> user </username>
<password> password</password>
<shouldRunAjaxSpider> true</shouldRunAjaxSpider>
</configuration>
...
</plugin>
Demo: ZAP in Docker Image
mvn -Pdocker,security-check verify
AWS absichern
These needs are at the heart of what Security Monkey is — an AWS security configuration tracker and analyzer that scales for large and globally distributed cloud environments.
Fazit & Ausblick
Bibliotheken = Sicherheitsrisiko
gerade im modernen Umfeld
zeitnahe Aktualisierung nötig
automatisierbar
Absicherung möglich
Feedback ist ein Muss
unerlässlich ein Sicherheitsbewusstsein im Team aufzubauen
sinnvolle Techniken zur Verwaltung von technischen Logins wie z.B. Spring Vault ([spring-vault]) zu berücksichtigen
Policy as a Code
"There is no one-size-fits-all solution to the complex problem of
implementing a deployment pipeline."
Continuous Delivery , J. Humble, D. Farley
"There are only two types of companies : those that have been hacked, and those that will be"
Robert Miller , FBI Director, 2012
Continuous Security in Modernen Webanwendungen
Sicherheit eingebaut
Martin Reinhardt (Holisticon AG)
@mreinhardt