DevSecCon London 2017: Shift happens ... by Colin Domoney

1. Join the conversation #DevSecCon
BY COLIN DOMONEY
Shift Happens …

2. About Me

3. You May Remember Me from Conferences Such as ...

4. “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

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

6. Security vs Speed
SECURITY SPEED
SECURITY SPEED

8. What Does the Market Say?

9. Testing Fast and Slow

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

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

12. 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.”

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

14. The Impact to Security Professionals

15. Encourage Early Adoption and Failure
• Test as early as possible
• Allow failure
• Enable learning
• Automate

16. Make Your Tools Accessible and Freely Available

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

18. Abstract Your Testing Tools From the User

19. Be Mean to Your Code
Why Gauntlt?
“Security domain
knowledge is generally a
mystery to dev teams”

20. Secure Your Supply Chain

21. #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

22. #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

23. #3 : Maintain an Inventory of Components

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

25. The Impact to Security Tooling

26. I Love
Static Analysis
, said no-one ever

27. Top Reasons to Hate Static Analysis
• Hard to use / not developer friendly
• False positives
• Sloooooooooooooooooooow

29. Near Instantaneous Scanning in a Pipeline

30. A Lot Quicker than 60 Seconds

31. A Better User Experience is Expected

32. Build a Map

33. And Then Measure Everything

34. Building and Optimising your Pipeline
• Policy and regulatory requirements?
• Velocity of pipeline?
• Risk appetite?
• Technical debt?
• Risk history?
• Nature of the change?

35. #1 : Synchronous (aka. The Slowest Option)
Application SAST

36. Application SAST
#2 : Asynchronous (aka. The Riskiest Option)
Risk Window

37. Application SAST
#3 : Hybrid (aka. You’re Probably OK but …)
Risk Window

38. Application SAST
#4 : Incremental (aka. Making Shift Happen)
File
SAST

39. Do No (More) Harm
• Establish a baseline
• Declare an amnesty
• Accept no more flaws

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

41. An Informed Risk Acceptance Process
• Scan or risk history
• Plain old (uncommon) common sense
• Points/credits system
• Machine Learning (tm) methods
• Exception process

43. “Auto-Configuring” Pipelines
https://blogs.msdn.microsoft.com/visualstudioalmrangers/2017/04/20/set-
up-a-cicd-pipeline-to-run-automated-tests-efficiently/

44. “Self-Adjusting” Policies

45. 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?

46. An Era of Greater Openness and Collaboration

48. Join the conversation #DevSecCon
Thank you