DevSecCon London 2017: Shift happens ... by Colin Domoney
-
Upload
devseccon-limited -
Category
Technology
-
view
291 -
download
1
Transcript of DevSecCon London 2017: Shift happens ... by Colin Domoney
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