making security agile

MAKING SECURITY AGILE

Getting security up to speed (with CI/CD)

Oleg Gryb, Sanjay Tambe – Samsung SSIC

Retrospective – Waterfall

2

http://brentmailphotography.com

Making Security Agile

3

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?


4

STRIDE

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


Old 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

5Making Security Agile

DevOps + Agile = Big Bang for Security


What is SAMI Our core product is an API based

service running in a cloud that supports IoT devices in real time

They also include web applications built on top of that.

All of that runs in an agile mode, because competition is too high and losing is not an option

More details: www.samsungsami.io


We had no choice

8

http://www.octopus.euhttp://brentmailphotography.com


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

Sanjay will talk about our approach in details


Aggravating factor – security testing is not exactly QA QA test are deterministic, AppSec tests are

anything but 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 13

Scheduled Job

Scheduled Job

Manual testing

Custom Tools

Security Artists

DevOps Team

Notifications

Step-by-step instructions to configure security automation

Demo of Security Automation Install open source software Configure scans for Web applications Configure security testing using QA

regression


INSTALL OPEN SOURCE

SOFTWARE


A. Install ThreadFix (in AWS or VM) Download ThreadFix from

http://www.threadfix.org/download/ Follow instructions to start ThreadFix

https://github.com/denimgroup/threadfix/wiki/Getting-Started

Enable port 8080 for external access. Once ThreadFix is up and running, go to

http://xxx.xxx.xxx.xxx:8080/threadfix in a web browser and accept warning from browser.Username: userPassword: password


http://www.threadfix.org/download/

http://www.threadfix.org/download/




http://xxx.xxx.xxx.xxx:8080/threadfix

B. Add users in Security team into ThreadFix


C: Add Team in ThreadFix


D. Add application Payments under Accounts team in Threadfix


E. Application Payments under team Accounts


F. Configure Defect tracker in Threadfix


G. Visit application in ThreadFix and note application #

Note: Application Id is shown as 31 for Payments app in URL in snapshot below. We will use this later when we upload findings in XML format from command line.


H. Set Defect tracker for application in ThreadFix


I. Enter login for Defect tracker


J. Install ZAP Download and Install open source ZAP

(Zed Attack Proxy) on AWS/VM using following https://github.com/zaproxy/zaproxy/wiki/Downloads?tm=2

We will be using ZAP on the AWS or VM in an headless mode (without UI).

Install ZAP on your laptop or Mac using above link. We will be using the UI to create sessions for web applications.


https://github.com/zaproxy/zaproxy/wiki/Downloads?tm=2



K. ZAP UI


L. Install web based job scheduler e.g. Juicebox Install any Open source Cron job

scheduler on AWS/VM.

Configure scan

Start scan


BScan – burp automation and more


• 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 is coming, stay tuned !

CONFIGURE SCANS FOR WEB

APPLICATIONS


Configure ThreadFix jarUse following commands in terminal mode on AWS/VM where ThreadFix is installed (obtain your API key from Threadfix)

java -jar /home/user/tfcli.jar --set key 5fPO07kc8xyxyxyxyxyxyxyxyxyxyxyxyxyxyxyxy

java -jar /home/user/tfcli.jar --set url https://127.0.0.1/threadfix/rest


https://127.0.0.1/threadfix/rest

Create Shell scripts to scan each application

Note: Following is Payment.sh script to scan Payment web app. We use app id # 31 found earlier.


Configure JuiceBox to schedule daily scan for Payment web app


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.


Create separate application for QA regression


Start 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.


REVIEW SECURITY FINDINGS AND

CREATE TICKETS


Review results in ThreadFix


Review Findings


Create defect


Create defect in Issue Repository


ThreadFix supports these scanners


Security Transformation Cheat Sheet

45

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


Conclusion You cannot do security as you did it 5-10

years ago. Security must work in parallel w Dev.

Automate security testing by using scheduled jobs, auto-uploading “findings” to a dashboard

Use Security professionals to review findings Make sure that findings are triaged before

they are submitted to a bug tracking system Don’t feed false positives to Dev or you’ll

completely lose your credibility


All of that can be formulated even shorter:

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

STOP creating new buzz words: security as code, security as service, DevSecOps, etc.

START DOING REAL JOB CALLED SECURITY AUTOMATION

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


THANKS FOR COMING!

Sanjay Tambe – Security Architect @ SSIC

Oleg Gryb – Sr. Manager, Security Engineering @ SSIC

Twitter: @oleggryb


making security agile

Software