Upload
vannga
View
232
Download
3
Embed Size (px)
Citation preview
Christian Schneider | @cschneider4711
Security DevOpsAutomation von Security-Checks in der Build-Kette
`whoami`
» Software Developer, Whitehat Hacker & Trainer » Freelancer since 1997 » Focus on Java & Web Security
(Pentests & Security Architecture Consulting) » Speaker at Conferences » @cschneider4711
www.mail@}Christian-Schneider.net
Security – SAST & DAST
Static Application Security Testing (SAST)
Dynamic Application Security Testing (DAST)
Fun Part
The Ratio Problem
Dev OpsSec
100 10 1 : :
The Frequency Problem
mehr Rollouts als Pentests
Security DevOps ?
Integrate Security Tools into Build-Jobs / CI-Chain
on every commit or nightly
Why Security DevOps?
» Keep up with rollout pace in agile projects » Automate certain checks as best as possible within
the build-chain » Early feedback to Devs
» Does not remove the pentest requirement! » Aims to free pentesters’ time to hunt more
high-hanging bugs
four axes each with four belts as incremental stepsimplicit master
… what levels will we cover?
Four different axes
4 3 2 1 1 2 3 4
4
3
2
1
1
2
3
4
Dynamic Depth
Intensity
Static DepthConsolidation
4 3 2 1 1 2 3 4
4
3
2
1
1
2
3
4
Dynamic Depth
Intensity
Static DepthConsolidation
Four different axes
Let’s explore these axes …
» … by showing how to implement this with OpenSource solutions used in the Security & Development domains.
Axis of "Dynamic Depth"
How deep are dynamic scans executed within a Security DevOps CI chain?
i.e. "where" are dynamic security tests applied?
Axis "Dynamic Depth": Level 1
Scanning of public attack surface (pre-auth):
» Spidering of UI layer » No requirement to authenticate scanner with target » Easy integration of scanner(s) in nightly build as
post-step
» "Throw tool at it (in CI-chain) and see what it generates…"
Zed Attack Proxy (ZAP)
"OWASP ZAP" features:
»passive scanning (Proxy / Spider) »active scanning (Proxy / Spider) »manual payload delivery (Intercepting Proxy) »Spider (classic & AJAX) »Fuzzing »Plugins »…
Active Scanning with ZAP…
ZAP in SecDevOps?
"OWASP ZAP" features relevant for Security DevOps integration:
»Headless operation mode / daemon »REST-API »Highly scriptable »CLI
ZAP + Jenkins = SecDevOps?
"OWASP ZAP" scanner + Jenkins plugin "ZAP Jenkins Plugin"
» Allows us to "Spider & Scan" as step in build job » Point plugin config to URL of integration system to test » Plugin saves HTML-report in project’s job for inspection » Best as separate Jenkins job to run during nightly build
(duration): » ZAP sends reporting data back to Jenkins » Jenkins publishes and archives the report(s) » Jenkins can create JIRA tickets when desired
UI- and Service-Tests in CI
… enhanced with OWASP ZAP
passive & active scanning
place report (html,xml) into workspace
Arachni in SecDevOps?
"Arachni Scanner" features relevant for Security DevOps integration:
» Command-Line Interface (CLI)
» Optional Web-UI
» RPC / REST-API
» Headless PhantomJS based browser cluster
» Better at spidering JavaScript-heavy applications
» Auto-login handling & session management
» Scanning authenticated application parts
Arachni + Jenkins = SecDevOps?
"Arachni Scanner" + Jenkins CLI step in build » Start in build job as CLI step and point to URL
of system under test » Generate HTML report and place into
workspace for inspection » Better execute within nightly build job
(due to duration)
» Alternatively: Start remote (also via CLI) to run async
HTML report of Arachni scanBildquelle: Arachni Scanner
Arachni Web-UI: Scan scheduling
Bildquelle: Arachni Scanner
Axis "Dynamic Depth": Level 2
Scanning of authenticated parts (= "post-auth") via UI layer » Properly maintaining sessions » Logout-detection & automatic re-login » Different users / roles » Spider & scan post-auth
Handling of hardening measures of application under test
» CSRF-Tokens, etc.
Guide ZAP into Post-Auth in CI
Different ways exist to let ZAP scan inside the authenticated parts:
» Configure authentication within ZAP—> works for standard login dialog submits
» Individually script authentication within ZAP—> flexible (sometimes complex) scripted in JavaScript—> can be recorded as Zest-Script
Login config example within ZAP
ZAProxy Jenkins Plugin: ZAP session use
Guide Arachni into Post-Auth
Give authentication infos to Arachni (Auth, Logged-In Indicators, Users)
» Use Arachni "autologin" plugin to specify via command line – Login URL, formfield names, credentials, logged-in
indicator, excludes
» Alternatively write custom ruby script for "login_script" plugin – Individual custom login logic possible – Logged-In indicators (RegExp) to know when to re-login
Login config example within Arachni (used in CI): via config
./arachni --plugin=autologin: url=https://example.com/login.action, parameters='j_username=foo&j_password=bar', check='Logout' --scope-exclude-pattern=logout.action https://example.com/
Axis "Dynamic Depth": Level 3
Separate scanning of different application layers / backends
• Scan internal WebServices (e.g. SOAP / REST) = directly scan backends
• Detect and scan parameter positions within XML, JSON, …
• Scan from "within" the different application’s layers
• IAST with distributed agents & instrumentation aims into that direction
• At least one simple step in that direction:
• Use the scanning proxy also between your backend service calls
• Or (if available): Use existing SOAP-Tests directly proxying through scanner
Backend scans with ZAP
How to achieve this with ZAP?
• ZAP operates as proxy server: place it between backend calls
• ZAP can inject payloads in observed XML tags/attributes & JSON fields
• Capture service call traffic in integration test during CI while either
A. frontend UI tests execute service backend calls indirectly, or
B. executing service tests that directly access the service endpoint
• Automatically scan as new requests are seen: "ATTACK Mode"
Also keep an eye on an alpha-level SOAP-Scanner ZAP addon
Axis "Dynamic Depth": Level 4
Targeted scanning of individual forms / wizards (UI) and service layers
» More individualized workflow coverage (not just simple spidering)
» Business-logic compliant usage patterns & inputs – "fill shopping cart followed by checkout process" – "access backend WebServices in special order to test
workflow", etc. » Custom coded security tests tailored to the application
Many ways exist… The simplest one could be: Re-use existing UI tests (Selenium, …)
» Proxy this traffic through ZAP in "ATTACK-Mode" (in security test phase of build)
» Optionally use ZAP Attack-Policies to specify/limit certain attack types
ZAP with special workflows (1/2)
ZAP with special workflows (2/2)
A more customized handling of individual workflows can be achieved:
Re-use & enhance existing "UI test code" at the desiredworkflow steps with calls to ZAP’s (REST)-API ordering attacks » Basically it’s like Unit-Test code that uses Selenium along
with with ZAP-Calls at the proper positions in application workflow
» Type of "ordered attacks" can again be defined via policies » Start ZAP as Daemon from Jenkins via plugin
Axis of "Static Depth"
How deep is static code analysis performed within a Security DevOps CI chain?
i.e. "where" are static security tests applied?
Axis "Static Depth": Level 1
Assurance that no third-party code with known vulnerabilities is used » Check application’s dependencies
– For Java applications: JAR files, etc.
Useful even for projects not currently under development » New vulnerabilities could become public:
Run a build regularly to check
Java libs: OWASP Dependency-Check
Scans all dependencies (even transitive ones) against CVE list
» Available as Maven plugin and Ant task » CLI version also available » Jenkins plugin for nice reporting
(and build breaking thresholds) » Not false-positive free
– regularly needs some time to triage findings
Axis "Static Depth": Level 2
Scan important parts of source code for vulnerability patterns
» At least important parts of applications’ codebases are scanned – like in-house reused code & custom developed
frameworks – for big multi-project Maven projects:
at least frontend and backend projects – or code of changed modules within a sprint
Java: FindSecurityBugs
Plugin for FindBugs with enhanced checks for security issues in Java code
»Runs within FindBugs, so that it can execute in Maven and/or Sonar
»Generates XML-file with potential findings »Jenkins FindBugs plugin for representing results
(also possible to display in Sonar)
Ruby on Rails apps: Brakeman
Scans RoR code for vulnerabilities
» CLI based » Nicely integrates with Jenkins
– Rendering scan results and trend analysis » Allows to compare scan results (delta detection)
– "What has been fixed and what was newly introduced?"
Axis "Static Depth": Level 3
Scan the complete applications’ source code for vulnerability patterns
» Just like "Level 2", but now for the complete codebase(no excludes)
– i.e. all projects of a multi-project Maven project – best via parent or corporate pom.xml
For FindSecurityBugs this means: » pre-compile even all JSPs (if you have any)
to scan them
Axis "Static Depth": Level 4
Scan source code of (important) third-party dependencies used in application
» If the component is open-source: – include it in regular scanning activities
» If the component is closed-source: – consider using code scanners that operate on binaries
• FindBugs (hence its FindSecurityBugs plugin) can also scan Java binaries, since it operates on Bytecode
Axis of "Intensity"
How intense are the majority of the executed attacks within a Security
DevOps CI chain?
i.e. "what" is being checked for?
Axis "Intensity": Level 1
Dynamic checks: Only passive scanning
» Simply proxy testcase generated traffic through passive scanners » Quick-win for using existing testcase code (i.e. Service- or UI-tests) » Can execute within existing tests that execute on every commit
– No requirement for a separate nightly CI job (i.e. doesn’t slow down build)
Static checks: Just scan the code along with other code metrics » Use the default rules of the scanners and integrate them into CI
Axis "Intensity": Level 2
Use lightweight active scanning options for dynamic checks
» ZAP: active scanning of observed URLs – provide a ZAP policy with desired active scan intensity
» Arachni: enable "active scan" during spidering
Better to execute in separate (nightly) build job due to duration
Axis "Intensity": Level 3
Use heavyweight scanning options on important parts of application
Dynamic checks: create "riskier" custom attack profiles
ZAP: – set "Threshold" to "Low" / "Strength" to "High" (or selectively "Insane") – enable more scanning rules via Policy Files
(could be maintained & used via SCM) – use ZAP’s "Advanced SQLInjection Scanner" extension
Arachni: – Enable the more aggressive "audit flags" like --audit-forms, …
Static checks: FindSecurityBugs: – set "Threshold" to "Low" and "Effort" to "Max"
Axis "Intensity": Level 4
Use customised rule sets for dynamic checks
Some examples for ZAP:
» Custom coded scan scripts as active & passive scan rules for company-individual checks
» Security regression tests (in Zest) against previous found vulns (also logic flaws)
» Custom input vector scripts: e.g. define certain injection points in custom encoded params
» Proxy scripts: for example for generic request/response modifications
Scripting possibilities in ZAP
… and for static code scans?
Use customised rule sets for static checks
Some example for FindSecurityBugs:
» Custom coded rule files (in Java) to check for wrong usages of server-side inhouse frameworks
Axis of "Consolidation"
How complete is the process of handling findings within a Security DevOps CI chain?
i.e. "how" are the results used?
Axis "Consolidation": Level 1
Generate human-readable (HTML) reports from tools and link them in Jenkins
» All relevant mentioned static and dynamic scanners generate HTML reports
» Collect and publish them in Jenkins build: via Jenkins "HTML Publisher Plugin"
Jenkins "HTML Publisher Plugin": Configuration of HTML reports to link
Jenkins "HTML Publisher Plugin":
Result in build
HTML report of ZAP scan
Axis "Consolidation": Level 1 (cont.)
Use simple criteria to "break the build" on heavy findings (ok, at least "unstable")
» Most scanners have capabilities to automatically flag the build » Dependency-Check (Severity Threshold), » FindSecurityBugs (via Sonar when rated as blocker), » etc.
» For others: at least do a simple log parse from Jenkins "Log Parser Plugin" to flag the build as unstable and/or broken
OWASP Dependency-Check: Thresholds to break build
Axis "Consolidation": Level 2
Custom logic to make build unstable and/or broken depending on
» Type of vulnerability (CWE or WASC or …) » Severity ranking (high risk) » Confidence level (firm vs. tentative)
Provide useful remediation info to developers Respect suppression mechanisms to rule out false positives
Flagging builds from reports
How (from within a CI job)?
» Most scanners also emit XML reports that can be parsed – Often a simple XPath count is just fine
» Alternatively fetch the results by accessing the scanner’s API
» Be sure to only break build with findings of high severity and high confidence !!!
– Less is more (when it comes to automation)…
» When new check introduce many findings: Baseline-Approach: Only break on new findings
Suppression of false positives
Custom finding list (from XML reports): filter out according to list from code repo
FindSecurityBugs: Use exclusion lists in config (XML filter files) & annotation @SuppressWarnings on false positive code lines
Dependency-Check: XML file of suppressions (checked-in along with the project)
Axis "Consolidation": Level 3
Consolidation goals:
» Consolidate & de-duplicate findings from different scanner reports
» including better false positive handling
» Push consolidated findings into established bug-tracker
» Delta analysis & trends over consolidated data sets
ThreadFix as result consolidator
Use a local ThreadFix server, which imports native scanner outputs
• does the heavy lifting of consolidation & de-duplication
• pushes findings toward bug-tracker and IDE (via plugins)
• process can be customised using it’s own REST-API
• ThreadFix imports findings of ZAP, Arachni, FindBugs, Brakeman, etc.
Report generated by ThreadFixBildquelle: ThreadFix
Trend Chart generated by ThreadFixBildquelle: ThreadFix
Axis "Consolidation": Level 4
Measure the concrete code coverage of your security testing activities
» Find untested "white spots" » Derive where static checks and code reviews
should focus more to compensate
Code coverage analysis
Use "OWASP Code Pulse", which instruments your Java app
» collects coverage data during dynamic security testing scans » generates reports ("code treemaps") of coverage
Code Treemap of dynamic scan coverageBildquelle: OWASP Code Pulse
Thank you very much!
LinksOWASP ZAP https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_ProjectZAP Selenium Demo https://github.com/continuumsecurity/zap-webdriverZAP Jenkins Plugin https://wiki.jenkins-ci.org/display/JENKINS/zap+pluginArachni http://www.arachni-scanner.comOWASP Dependency Check https://www.owasp.org/index.php/OWASP_Dependency_CheckFindSecurityBugs http://h3xstream.github.io/find-sec-bugs/Jenkins Log Parser Plugin https://wiki.jenkins-ci.org/display/JENKINS/Log+Parser+PluginThreadFix http://www.threadfix.orgOWASP Code Pulse https://www.owasp.org/index.php/OWASP_Code_Pulse_Project
Bildquelle: dreamstime.com
Hands-on Trainings for these and more Security Tools:
www.Christian-Schneider.net [email protected]
Twitter: @cschneider4711