making security agile - oleg gryb

MAKING SECURITY AGILE

Getting security up to speed (with CI/CD)

Oleg Gryb – Visa Inc.

DevOps Look at Security

2Making Security Agile

DevOps Look at Security


The only thing more dangerous than a developer is a developer conspiring with Security. The two working together gives us means, motive, and opportunity.

Information Security is always flashing their badges at people and making urgent demands, regardless of the consequences to the rest of the organization, which is why we don’t invite them to many meetings. The best way to make sure something doesn’t get done is to have them in the room.They’re always coming up with a million reasons why anything we do will create a security hole that alien space-hackers will exploit to pillage our entire organization and steal all our code, intellectual property, credit card numbers, and pictures of our loved ones. These are potentially valid risks, but I often can’t connect the dots between their shrill, hysterical, and self-righteous demands and actually improving the defensibility of our environment.

From a real survey


“Stop pretending that you’re the only one in the roomoccupying a higher moral ground”

Credits: http://www.looppng.com/

That Love between Sec & DevOps Goes both Ways

5Making Security Agile From @RSnake Post at Twitter

Difficult to understand

Won’t fix attitude

Retrospective – Waterfall

6

http://brentmailphotography.com

Making Security Agile

7

DREAD

• Damage potential: How great is the damage if the vulnerability is exploited?

• Reproducibility: How easy it is to reproduce the attack?

• Exploitability: How easy it is to successfully exploit this condition?

• Affected users: As a rough percentage, how many users are affected?

• Discoverability: How easy it is to find the vulnerability?


8

STRIDE

• Spoofing• Tampering• Repudiation• Information disclosure• Denial of service• Elevation of privileges


Old Waterfall AppSec Summary We’ve generated huge *doc and *xls with

Threat Models and pen test results. We wrote nice exec summaries and we

presented details to Dev/OPS/DB teams We had a cool heat map to visualize the risk

allocation for execs. Then we worked on remediation with

developers – informal name “nagging” We supported a security dashboard and

reported/escalated to CTO weekly


DevOps + Agile = Big Bang for Security


We had no choice


Credits to Pierre de Rauglaudre

https://www.linkedin.com/profile/view?id=AAMAAAAH6MkBVeMcpBSHjvAtItRfIA9ty5Dg6kA&authType=name&authToken=dEEz&trk=hp-richmedia-name

https://www.linkedin.com/profile/view?id=AAMAAAAH6MkBVeMcpBSHjvAtItRfIA9ty5Dg6kA&authType=name&authToken=dEEz&trk=hp-richmedia-name

New Agile Reality aka Reqs No 2-4 weeks for security purposes Nobody cares about (or understand) formalities

such as STRIDE, DREAD or heat maps Forget about 2 full days of interviews, not

possible Nobody gives Environment for 2-3 weeks solely

for pen testing. Need to share. Need to do security as Dev process goes and in

parallel Need to be integrated better with the DevOps and

QA teams


Other Challenges for API products You *can* pass an API URL to a scanner

and tell “do automatic scanning” , but it’s not going to crawl. No Spidering is available.

You can manually call each and every API while on a scan proxy and then do scanning, but if you have too many ever changing API’s, you’ll die doing that


Differences – QA/DevOps and Security

Ops: run_script(input) $? (0, non-zero)

QA: assert(condition) {true,false}

Security: scan(app) {HML…,false positive}

where HML and FP is really a human’s decision


QA and security differences

You can’t dump all app scanner’s “findings” to a bug tracking system

You usually need to triage each finding and verify a severity before submitting it to a bug tracking system

In many cases you still need to explain your finding and remediation to developers


Coming to a Solution Since Security does require a manual

review, our hypothesis was that we need a dashboard with a broad import/export capabilities

Import from scanners, export to bug tracking systems

All scanners should be automated to run regression

Should also allow manual testing and import for new features and products


Making Security Agile 17

Scheduled Job

Scheduled Job

Manual testing

Custom Tools

Security Artists

DevOps Team

Notifications

CONFIGURE SECURITY TESTING

USING QA REGRESSION


Why use QA regression Over the years, QA team has built

hundreds or even thousands of functional test scripts. They continue to add new scripts everyday.

Security team can reuse the work done by QA team to do security testing.

They can use a proxy such as BURP or ZAP to analyze requests & responses to find any security vulnerabilities.


Automation with ZAP Proxy Use command such as following to start

ZAP in headless mode on port 8085:

java -Xmx2048m -jar /home/user/zap/ZAP_2.4.2/zap-2.4.2.jar -cmd -daemon -installdir /home/user/zap/ZAP_2.4.2 -config api.key=12345 -port 8085


Configure and start QA regression Configure QA regression properties to

use proxy running on port 8085. Use command such as following to start

QA regression (will vary depending on scripts used for your QA regression)

mvn clean test -Dcategory=api -Dtarget.environment=qa -DexcludedGroups=in-progress,sdr,email,logs,cleanup -DuseProxy=true -DlocalProxy=true


Save security findings from regression in XML form At the end of regression, save findings in XML form:

curl "http://localhost:8085/OTHER/core/other/xmlreport/?apikey=12345" > /home/user/temp/newpaymentregression.xml

Upload the findings to Threadfix using (app id for regression # 32 found earlier)

java -jar /home/user/tfcli.jar --upload 32 /home/user/temp/newpaymentregression.xml

Note: Above commands are part of automated script.


ThreadFix supports these scanners


BScan – Automation with Burp


• Automates burp using Ruby extensions• Allows adding custom tests to the same scan• Can be run as simple as:

jruby –S bscan –c config• Will generate report automatically when completed• Can work in auto proxy mode• Configurable – can overwrite any Burp and custom settings• Version 3.0 has been released on 10/2015 !

https://rubygems.org/gems/bscan/versions/3.0.0

BScan – Simple Config


# BScan settingsbscan.inactivity_to=20bscan.issues=issuesbscan.run_proxy=truebscan.report_url_prefix=https://www.google.com|google.xmlbscan.report_url_prefix=https://www.whitehatsec.com|wh.xmlbscan.report_def_name=report_all.xmlbscan.ignore_info=falsebscan.ignore_low=false

# Burp Settingsscanner.numthreads=10proxy.interceptrequests=false

#listen on port 8083 instead of standard 8080proxy.listener0=1.8083.1.0..0.0.1.0..0..0..0.

BScan – Simple Run & Test with QA Regression


jruby -J-Xmx1024m -J-Djava.awt.headless=true \-S bscan -c bscan.conf -L 2 -l bscan.log &

Aka QA regression:

curl -k -x http://localhost:8083 https://www.google.com

curl -k -x http://localhost:8083 \https://www.whitehatsec.com

https://www.google.com/

https://www.google.com/

https://www.whitehatsec.com/



Security Transformation Cheat Sheet

27

From TOTwo full days TM meetings with many people involved

Participating in arch/design discussions through Confluence or other collab tools

Very formal, “scientific” TM with DREAD, STRIDE residual risks, etc.

Recommendations in JIRA coming from arch/design discussions

DREAD, residual risks, etc. HML (High, Medium, Low)

STRIDE CVE (usually automatically assigned by a tool)

Manual pen testing for everything Selective pen testing for new features and products

Expensive commercial scanners To OWASP ZAP, Burp, custom tools

Docs and PDF reports, manual export to Dev bug tracking systems

Exporting tickets directly to JIRA from Threadfix

Running/uploading scans manually Automated batch jobs w auto-upload to Threadfix


Returning to “Phoenix Project”- DevOps Implemented

“I’m amazed at how quickly the Unicorn security fixes are being integrated,” he says. “Compared to the rest of Phoenix, fixing Unicorn security issues is a breeze. The cycle time is so short, we once put in a fix within an hour. More typically, we can get fixes in within a day or two. Compared to this, remediating Phoenix issues is like pulling our own teeth out, without any anesthesia. Normally, we’ d have to wait for a quarter for any meaningful changes to be made, and jumping through all the hoops required to get an emergency change order through was almost not worth the trouble.


Summary: STOP wiring buttons that nobody will ever push © Lean Startup Conference - 2013

There is no “one size fits all” solution, which depends on your org and its culture.

Try to change the mentality and remove quotes in “Love” between security, DevOps and others.

Remember: coding along is not going to solve all your security problems

Don’t forget about Security Artists, because security is just as politics – an art of possibilities and tools are very much useless without them.


THANKS FOR COMING!

Oleg GrybA Human in Chief, Interested in Security

Twitter: @oleggrybLinkedin: https://www.linkedin.com/in/ogryb


making security agile - oleg gryb

Technology