managing an application vulnerability management program ... · managing an application...

Managing an Application Vulnerability Management Program in a CI/CD Environment

March 29, 2018 OWASP Vancouver - Karim Lalji 1

About Me

• Karim Lalji

– Managing Security Consultant (VA/PT) at TELUS

– Previously:

• Application Security Consultant, Software Engineer, Sysadmin

– M.Sc in Information Security (Candidate)

– B.Tech in Computer Systems / Network Security

– GPEN, GWAPT, GCIH, GSEC Certifications


Application Security

2017 Verizon Data Breach Investigation Report (DBIR)

https://blog.rapid7.com/2017/05/05/verizon-data-breach-report-dbir-key-takeaways/


https://blog.rapid7.com/2017/05/05/verizon-data-breach-report-dbir-key-takeaways/


• Why is application security so important?

– Web apps have many moving parts

– Most organizations have an internet facing application in their environment

– Web apps deal with very sensitive data

– Web apps are a more reliable entry point for attackers



• So why the results in the 2017 DBIR?

– The field of application security is still very young

– The relationship between developers and InfoSec professionals often becomes adversarial

– Successful vulnerability management for web apps requires a paradigm shift and a new set of technologies

– Most InfoSec approaches stem from traditional “network security”


Software Development

• Modern software environments are different from what they used to be:

– Agile methodologies

– Sprints, product backlogs, feature teams

– Single deployable units of code

– Many developers working on a single feature


Software Development

Agile Team

Developer 1 Developer 2 QA Analyst 1 DevOps

Engineer

Business Analyst Scrum Master / PM

Agile Development General Structure


DevOps

• We’ve all heard the new term “DevOps” but what does it mean?

– DevOps is a philosophy

– Focuses on automation

– Continuous Integration (CI)

– Continuous Delivery (CD)


DevOps


Branching


CI/CD

• Many large software enterprises have multiple deployment environments with build cycles

Environment Build Interval

Development N/A

QA Daily

Staging Weekly

Production Bi-Weekly

Code that is merged in development gets “pushed” to QA daily

Features passing QA are moving to staging; features that don’t will be “reverted”


CI/CD

• DevOps helps automate the build/release cycle

– CI Tools: Bamboo and Jenkins

– Build Tools: Maven, Ant and Gradle

– Version Control: Bitbucket, GIT

– Issue Tracking: JIRA


Application Security Testing

• Security bugs found in production cost up to 30x more to fix than in development (NIST)


Application Security Testing

• Many different tools available to us

• AST family of tools

– Static Application Security Testing (SAST)

– Dynamic Application Security Testing (DAST)

– Interactive Application Security Testing (IAST)

• Human Testing (Penetration Testing )


SAST

• Static Application Security Testing (SAST)

• Scans source code for vulnerability

• White-box approach

• Sources and sinks– Source: where external data passes into application

– Sink: code destination that can be abused if malicious data reaches it

– SAST tool must be able to “follow” data flow path


SAST

public void getRequestData()

{

String customerName = request.getParameter(name);

updateCustomerName(customerName)

}

public boolean updateCustomerName(customerName){

Statement statement = conn.createStatement();

String sql =

“UPDATE Customers SET first_name = ” + customerName + “ WHERE id = 5”;

statement.executeUpdate(sql)

}

SOU

RC

E

SINK


SAST

• SAST Considerations

– Often produces many findings

– Requires triage/tuning to reduce false positives

– Speaks to the “developer” in their language

– Provides opportunities to catch security issues early

• Can be executed at any S-SDLC phase but most valuable in development


SAST

• SAST Frequency

– Frequency will depend on organization

– Remember quick feedback to developers!

– Traditionally run daily or weekly

– Modern CI/CD tools allow commit level scans

• Only scan the deltas or what has changed

• Prevent the change from merging before issues are fixed

• Allows developers to learn and promotes application security learning


SAST


SAST


SAST IDE Integration

SAST

• SAST can usually be run on both complied and source code, pro’s cons to both

– Incremental scans require source code

– Immediate feedback requires source code

– Some compilers have been caught inserting backdoors and rootkits.

– Legal issues using raw source on a SaaS platform?

• Option 1 (use bytecode analysis)

• Option 2 (consider an on-premise solution)


DAST

• Dynamic Application Security Testing (DAST)

• Scans the running application

• Black-box approach

• Looks at application behavior, various injection points and security misconfigurations

• Can be executed at any development phase but most valuable in testing and production environments


DAST

• Frequency will depend on organization

• Keep in mind, requires functional running app

– Generally linked to testing and production

• Often times run weekly or bi-weekly (sprint)

• Can also (and perhaps should) be run continuously

• Issues can be automatically pushed to issue tracking software eg: JIRA


DAST


IAST

• Interactive Application Security Testing (IAST)

– Aims to combine some of the functionality of DAST and SAST

– Places an “agent” in a running application

– Agent inspects behavior and triggers dynamic and source code scanning


IAST


By Elsane (Gimp Previously published: www.quotium.com) [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC BY-SA 3.0 (https://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons

IAST

• IAST Pros:– Libraries/frameworks cause SAST tools to produce “lost

sources” and “lost sinks” which it can’t analyze

– Correlates the running application with source code

– Can produce less false positives

• IAST Cons:

– Not “specialized” in either DAST or SAST

– Reduces false positives; may also reduce overall findings

– Can negatively impact application performance


RASP

• Runtime Application Self Protection (RASP)

– Similar to IAST in terms of an application “agent”

– Not a scanning/testing tool

– More of a protection tool

• Designed as a sophisticated form of WAF/IPS

– WAF’s block malicious strings without context

– RASP tools execute the incoming data in an “instrumentation” section, run it and then determine whether it’s safe


AST Tools

Tool Type License

Fortify by Microfocus (HP) DAST/SAST/IAST/RASP Commercial

Veracode DAST/SAST/RASP Commercial

IBM AppScan DAST/SAST Commercial

Whitehat Sentinel DAST/SAST Commercial

Acunetix DAST Commercial

CheckMarx (CxSuite) SAST Commercial

Contrast Security IAST Commercial

Burp Suite DAST/SAST Commercial/Free

OWASP ZAP DAST Free

SonarQube SAST Free

Arachni DAST Free


AST Tools


Human Testing

• Humans are still smarter than computers

• The value of manual security assessments cannot be eliminated by automated tools

• Penetration tests attempt to emulate risks posed by more advanced attackers

• PCI Requirement 11.3 mandates organizations conduct “penetration testing” at least annually


SLA

• A note about SLA’s (Service Level Agreements)– DAST/SAST findings should follow normal client SLA’s

– Ensure prioritization isn’t separate

– Otherwise, expect them to go in the “later” pile

– Utilize time to remediate, SLA breaches and overall baseline scores as part of a Key Progress Indicator (KPI)


Vulnerability Management

• How do we achieve application vulnerability management?

– High visibility (Dashboards)

– Baseline / Targets

– Metrics

– Security awareness (business and developers)


Summary


Phase Tools and Activities

Production • Utilize DAST/IAST at regular intervals • May not be as frequent as test environment • Remember test / prod may not be mirrored

• Integrate into issue tracking software (Eg: JIRA or Service Now) • Tie security issues into regular development SLA’s• Conduct regular penetration testing activities

Testing • Run DAST/IAST tools frequently/continuously• Integrate into developers issue tracking software (eg: JIRA)

Development • Quick developer feedback • Utilize SAST tools • Integrate with CI/CD tools to provide commit/build level feedback• Use IDE integrations to help train developers

Questions


managing an application vulnerability management program ... · managing an application...

Documents