Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

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

413 visualizaciones

Publicado el

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

Publicado en: Tecnología
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

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

  1. 1. Join the conversation #DevSecCon BY COLIN DOMONEY Shift Happens …
  2. 2. About Me
  3. 3. You May Remember Me from Conferences Such as ...
  4. 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. 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
  7. 7. What Does the Market Say?
  8. 8. Testing Fast and Slow
  9. 9. 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
  10. 10. 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.
  11. 11. 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.”
  12. 12. 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
  13. 13. The Impact to Security Professionals
  14. 14. Encourage Early Adoption and Failure • Test as early as possible • Allow failure • Enable learning • Automate
  15. 15. Make Your Tools Accessible and Freely Available
  16. 16. 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
  17. 17. Abstract Your Testing Tools From the User
  18. 18. Be Mean to Your Code Why Gauntlt? “Security domain knowledge is generally a mystery to dev teams”
  19. 19. Secure Your Supply Chain
  20. 20. #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
  21. 21. #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
  22. 22. #3 : Maintain an Inventory of Components
  23. 23. 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
  24. 24. The Impact to Security Tooling
  25. 25. I Love Static Analysis , said no-one ever
  26. 26. Top Reasons to Hate Static Analysis • Hard to use / not developer friendly • False positives • Sloooooooooooooooooooow
  27. 27. Near Instantaneous Scanning in a Pipeline
  28. 28. A Lot Quicker than 60 Seconds
  29. 29. A Better User Experience is Expected
  30. 30. Build a Map
  31. 31. And Then Measure Everything
  32. 32. Building and Optimising your Pipeline • Policy and regulatory requirements? • Velocity of pipeline? • Risk appetite? • Technical debt? • Risk history? • Nature of the change?
  33. 33. #1 : Synchronous (aka. The Slowest Option) Application SAST
  34. 34. Application SAST #2 : Asynchronous (aka. The Riskiest Option) Risk Window
  35. 35. Application SAST #3 : Hybrid (aka. You’re Probably OK but …) Risk Window
  36. 36. Application SAST #4 : Incremental (aka. Making Shift Happen) File SAST
  37. 37. Do No (More) Harm • Establish a baseline • Declare an amnesty • Accept no more flaws
  38. 38. 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
  39. 39. An Informed Risk Acceptance Process • Scan or risk history • Plain old (uncommon) common sense • Points/credits system • Machine Learning (tm) methods • Exception process
  40. 40. “Auto-Configuring” Pipelines up-a-cicd-pipeline-to-run-automated-tests-efficiently/
  41. 41. “Self-Adjusting” Policies
  42. 42. The Breakdown of the Monolith • Discover and monitor inter-service communications • Segment and isolate applications and services • Automate policy management and configuration architectures-/a/d-id/1325155?
  43. 43. An Era of Greater Openness and Collaboration
  44. 44. Join the conversation #DevSecCon Thank you