Let's see why and how you could include security in your devops pipeline

1. Including security in devops
DevOpsCH
21/01/2016 – Jérémy MATOS

2. whois securingapps
Developer background
Spent last 10 years working between Geneva and Lausanne
implementing and deploying security products and solutions
Focus on mobile since 2010
Now software security consultant at my own company
http://www.securingapps.com
Provide services to build security in software
Mobile
Web
Cloud
Internet Of Things
https://twitter.com/securingapps

3. Introduction
Security is often out of scope in the DevOps initiatives
Historically security is in the hands of the operations
Emphasis on network infrastructure
Keep the bad guy out
Firewall (DMZ, vlans), Reverse proxy (WAF), Intrusion Detection System (IDS), etc…
Fine tuning OS/database configurations
If bad guy can still enter, reduce impact
Disabling features, patching, access right policies, audit logging, encryption, etc…
Application security not always addressed in the SDLC

4. Security strategy in the organisation
Chief Information Security Officer (CISO) often
Has no practical experience in dev, nor control on the dev team
Considers software as a black box
Can only recommend to comply with generic safe coding guidelines
Buys stuff for sysadmins and asks them to fill the gaps
Those extra security integration steps
Slow down deployment
Cause bugs only in production because of stricter config
Lead to issues difficult to fix by sysadmins only
Business often pushes to get lowest acceptable security level:
Demonstrate the organisation somehow cares about security in
case things turn bad

5. Building security in
OWASP Software Assurance Security Model
REQUIREMENTS
AND
USE CASES
ARCHITECTURE
AND
DESIGN
CODE
TESTS
AND
TEST
RESULTS
OPERATIONS
/
SERVICE
DELIVERY
Vulnerability
Management
Environment
Hardening
Operational
Enablement
Security
Requirements
Security Standards
& Guidelines
Secure
Architecture
Attack Models &
Threat Assessment
Penetration
Testing
Code
Review
Security
Testing
Architecture &
Design Analysis

6. Penetration testing: automated tools
Pen testers first rely on automated tools to have an idea where
to look at
Script kiddies only rely on those free tools
Well, run those tools in the continuous integration loop ! e.g.
ZAP : Vulnerability finder for web applications
Sqlmap : SQL injection detection
Get rather good coverage on basic web attacks
Pentesters will be paid to find higher value issues
Script kiddies will problably give up and switch to another target
You won’t get hacked because of a basic mistake

7. Penetration testing: OWASP ZAP
Java GUI tool
Can be instrumented using
Java, e.g. Jenkins Plugin
Automatically crawls a
webapp and test
common vulnerabilities
Scan time may vary from
seconds to hours
There are false positives !
Yellow (and even orange) findings are not really significant

8. Penetration testing: sqlmap
Great python CLI tool
Automatically test very
complex SQL attacks
Detects database type
and adapt injections
Expects a url with
parameters
Really useful to validate the findings of ZAP concerning SQL

9. Penetration testing: challenges
Lots of findings to manage
Not anymore a point in time assessment with few points to address
Reports must be processed automatically
1 issue = 1 entry in bug tracking does not scale (false positives…)
Issues must have a good identifier to be tracked over time
Do not switch to the least effort mode
Application security errors (e.g. XSS, SQLi) must be fixed in code
Do not rely on a workaround in the server config
Write a unit test
Test application in both environments
Standalone to discover as many errors as possible
Hardened environment to ensure countermeasures are effective
Review application & environment logs to check alerts are usable

10. Code review
Static Appliction Security Testing (SAST):
Scan source code to look for dangerous constructions
Integration is generally straightforward as pure dev question
Most solutions, and particularly free ones, are better at identifying quality
issues than real security problems
Generally poor results on dynamic languages (e.g. javascript, PHP…)
Sonar feedback is still useful
Same challenges than automated pentesting (DAST)
Many issues to address
Customizing rules is key to reduce false positive rate
Security rules need to be updated regurlarly to keep up with
attacks and new frameworks/libraries
New rules => new issues, but on old code

11. Security testing
If you have implemetend or integrated security features, they
should be automatically tested
Use case to check legitimate logic/data is indeed accepted
Abuse case to confirm invalid logic/data is refused
Whenever possible, consider writing unit tests
If impossible, setup an integration test
Examples of possible unit tests for a JWT authentication
Change any field of a valid token and expect a signature error
Remove signature from JSON payload and expect a signature error
Move time in past or future and check behavior for Not before,
Expiration time and Issued at fields
A vulnerability is fixed with a unit or integration test proving it

12. Deployment
Vulnerability management
For your infrastructure: vulnerability scanner
Nessus Home free, but not for commercial usage
For your software: keep dependencies up to date
OWASP dependency check
Be careful with javascript hosted on CDN
Subresource Integrity recently introduced by W3C can help
Your automated tests should enable you to update 3rd party code transparently
Environment hardening
Great guide (in French) from ANSSI to secure GNU Linux
Include those recommandations in your Docker/VM images

13. Conclusion
Security is both a matter of dev and ops
Security features are features and hence should be
automatically tested
Free and automated application security tools are available:
why not include them in the continuous deployment pipeline ?
Yet continuous integration tools are not particularly secure
Continous Intrusion: Why CI tools are an attacker’s best friends
Watch out your deployment
Pay great attention if accessible from outside your LAN

14. Thank you !
Any question
contact@securingapps.com