Join the conversation #DevSecCon

BY COLIN DOMONEY

Shift Happens …

About Me

You May Remember Me from Conferences Such as ...

“How do I Shift”

• How do I fix?• How do I ensure coverage?

“I’m Shifting”

• How do I test?• How do I ensure I won’t get

slowed down?

The Changing Conversation

The Security Guys

• CISO• Head of IT Security• AppSec Manager

The “DevOps” Guys

• Delivery Manager• Application Lead• Automation Lead• “the guy who optimises stuff

and makes it go faster”

The Changing Personas

Security vs Speed

SECURITY SPEEDSECURITY SPEED

What Does the Market Say?

Testing Fast and Slow

The Dangers of Moving Fast

• Changes being made so quickly, and so often, that it is difficult to understand and review them for risk

• Lack of stage gates which means there are no natural points to insert reviews, tests or other controls

• Not enough time to do exhaustive testing or reviews

• Constantly changing risk profile

The Benefits of Moving Fast

• Frequent delivery drives teams to automate and standardize workflows, especially build-and-deploy pipelines, increasing control over and transparency into change.

• Most changes are incremental and small, which makes it easier to understand and test, and safer to release each change.

Fast and Incremental, Slow and Exhaustive

“The faster teams move, and the more they rely on automation, the more tradeoffs they need to make. Because not enough time is available to run deep, exhaustive scans or other security tests in continuous testing, organizations need to scan first for the most critical vulnerabilities. Then they need to target recently changed code for incremental testing and rely on smoke tests to catch other critical mistakes. Rules and tests that take too long to run or are too noisy need to be tuned or cut out, leaving holes in test coverage.

This means that periodic pen testing, in-depth manual reviews, configuration, auditing, deep scanning and fuzzing are still needed to find errors that escape tight automated loops.”

Three Steps to Shifting Left

• Establish an Inventory Baseline • What does your forward process look like?

• Assess Continuously and Feedback Findings• Visibility of findings

• Automate Testing Process• Optimise process• Amplify feedback loops

The Impact to Security Professionals

Encourage Early Adoption and Failure

• Test as early as possible• Allow failure• Enable learning• Automate

Make Your Tools Accessible and Freely Available

Becoming Selective in Test Scoping

• Some code is more security critical than other• Ensure adequate controls over

’security sensitive’ code• Manual/peer review changes• Use test harnesses to allow

fast, automated security scans

Abstract Your Testing Tools From the User

Be Mean to Your Code

Why Gauntlt?

“Security domain knowledge is generally a mystery to dev teams”

Secure Your Supply Chain

#1 : Prescribe a Policy for OSS Use

• Prescribe a policy for the use of OSS based on:• Risk appetite• Business criticality• Time to market• Organisational maturity

• Provide a recommended architecture of commonly used and pre-approved components

• Educate your security team in the use of OSS components and risk determination

#2 : Control Your Repositories

• Use a caching binary repository server (such as Nexus)

• Maintain a blacklist of known bad (and hence banned) components

• Maintain a whitelist of known good (and hence approved) components

• Quarantine unknown components until assessed• In extremis disable access to public internet

repositories

#3 : Maintain an Inventory of Components

The Changing Skillset Required

• Learn how to code!• Learn the ‘tools of the trade’ (Git, Ansible, etc.)• Learn the basics with a test application i.e. WebGoat.Net• Trawl developer communities (StackOverflow, etc.) for

security related topics and contribute• Contribute security patches to an OSS project• Experience a ‘Day in the Life’ of a Developer

The Impact to Security Tooling

I Love Static Analysis

, said no-one ever

Top Reasons to Hate Static Analysis

• Hard to use / not developer friendly

• False positives

• Sloooooooooooooooooooow

Near Instantaneous Scanning in a Pipeline

A Lot Quicker than 60 Seconds

A Better User Experience is Expected

Build a Map

And Then Measure Everything

Building and Optimising your Pipeline

• Policy and regulatory requirements?• Velocity of pipeline?• Risk appetite?• Technical debt?• Risk history?• Nature of the change?

#1 : Synchronous (aka. The Slowest Option)

ApplicationSAST

ApplicationSAST

#2 : Asynchronous (aka. The Riskiest Option)

RiskWindow

ApplicationSAST

#3 : Hybrid (aka. You’re Probably OK but …)

RiskWindow

ApplicationSAST

#4 : Incremental (aka. Making Shift Happen)

FileSAST

Do No (More) Harm

• Establish a baseline• Declare an amnesty• Accept no more flaws

What Happens When a Scan Fails?

Fall Back

• Go back to the last known good scan• Blue/green releases

Fall Forward

• If your velocity is sufficient wait for the next release• Ensure your

feedback loop is tight

Exception

• Proceed at risk• Understand the risk

An Informed Risk Acceptance Process

• Scan or risk history• Plain old (uncommon) common sense• Points/credits system• Machine Learning (tm) methods• Exception process

“Auto-Configuring” Pipelines

https://blogs.msdn.microsoft.com/visualstudioalmrangers/2017/04/20/set-up-a-cicd-pipeline-to-run-automated-tests-efficiently/

“Self-Adjusting” Policies

The Breakdown of the Monolith

• Discover and monitor inter-service communications• Segment and isolate applications and

services• Automate policy management and

configuration

https://www.darkreading.com/endpoint/rethinking-application-security-with-microservices-architectures-/a/d-id/1325155?

An Era of Greater Openness and Collaboration

Join the conversation #DevSecCon

Thank you