# Securing innovation at speed and scale via DevSecOps

  • Devops growing faster than security - problem!
  • Cloud security is on the rise
    • security has to keep up with innovation pace of other engineering features
  • Get out of checklist mode; automate security testing
  • Problems
    • friction for the sake of it
    • manual process and meeting culture
    • point in time assessments
    • thought about outside the value creation process
  • Mission - “Target customer value through secure iterative innovation at speed and scale”
  • Red and blue team security testing - “find exploits day”
  • Security self service is important
  • Devsecops
    • Security engineering
      • experiment, automate, test
    • Ops
      • hunt, detect, contain
    • Compliance operations
      • response manage and train
    • Security science
      • learn, measure, forecast
  • Make it simple
    • reduce size of blast radios
      • smaller teams, services, failures, APIs
  • http://www.devsecops.org/

Transforming security from qualitative to quantitative

http://www.slideshare.net/sc0ttruss/chefdevseccon2015

  • Quantitative - can be coded, automated etc
  • Qualitative - just blah blah blah
  • Security as code is the key - it has to be quantitative
  • Security happens in tiers
    • Trim down the OS - remove what you don’t need
    • At check-in to source control
    • Running of orchestration jobs
    • etc
  • Security tests are needed at all steps of the pipeline, not just at the running prod node

  • 1 global firewall to 100s of virtual firewalls

Continuous Security Testing

Speaker: http://www.slideshare.net/StephendeVries2 Slides: http://www.slideshare.net/StephendeVries2/continuous-security-testing-devseccon

  • Traditionally - security testing happens after the product is built, via external experts
  • Security testing is where quality testing was 10 years ago
  • Automation tools
    • https://github.com/continuumsecurity/bdd-security
    • Selenium + OWASP ZAP (HTTP/S Proxy)
  • False positives from automation tools are important to remove
  • Security test ownership
    • Separate security team - nah
    • DevOps team owned, with consultancy from security team - maybe
    • DevOps + Sec team; one cross-skilled team - yeah
  • Manual security tests are still needed; but once a vulnerability is found via a manual test, feed it back to the automated txt suite
  • More tools
    • Mittn
    • ZAP-Junit
    • OWASP ZAP Jenkins plugin
    • Gauntlet (gauntlt.org)

# Making the Web Secure by Design with OWASP-SKF

## Security Knowledge Framework

  • OWASP ASVS checklist - application security verification standard, since 2011
    • levels 1-3
  • Training
    • OWASP security knowledge framework https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework

# Securing your infrastructure one unit test at a time

  • Devops - infrastructure as code
    • definitive
    • versionable
    • reviewable
    • shareable
  • Reiteration of BDD-Security framework and its usefulness
  • Github - search for “gitrob”
  • Next time you have a security issue, write a test
    • make it go green
    • keep it running all the time

# The Tao of security science

  • Security science
    • F.U.D to facts
    • What is your password policy?
    • How frequently do you need to patch?
    • Min length of password vs algorithm
  • Promoting security
    • Scoring/grades are powerful motivators

Securing your assets through devops delivery

  • Devops and CD principles
  • OWASP OpenSAMM (maturity model)
  • Security patterns exist - where?
  • What about your assets?
    • git / your code
    • CD server
  • Attackers circumvent, not break
  • How to secure your assets
    • obfuscation - really??!!
    • encryption of code in transit
    • audit your code footprint

An end to cargo cult security

  • Automated vulnerability scans not enough. Manual pen tests are needed
  • Can you detect a planned vulnerability scan from your monitoring tools / logs

Whats not to like?

  • Make your OS image part of your build
    • patching as a separate process disappears
  • Only use immutable and young servers
  • Don’t let anyone log onto production
    • always go via your CD and log monitoring tools etc
    • there will be exceptions, which is pl

Chain Reactions

  • ~ 90% functionality comes from dependencies
    • what about security testing of your dependencies?