Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Continuous Security Testing with Devops - OWASP EU 2014

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Chargement dans…3
×

Consultez-les par la suite

1 sur 22 Publicité
Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Similaire à Continuous Security Testing with Devops - OWASP EU 2014 (20)

Publicité

Continuous Security Testing with Devops - OWASP EU 2014

  1. 1. Continuous Security Testing In a DevOps World
  2. 2. About Me • Stephen de Vries – CTO ContinuumSecurity – 60% Security consultant 40% Developer – Author: BDD-Security project
  3. 3. About Me DevOps is a means Continuous Delivery / Continuous Deployment is the end • Don’t wait for a release before deploy • Deploy individual features • Get business value to production as fast as possible
  4. 4. Plan/Code/Build/Test Continuous Delivery Continuous Integration Agile Int. Test QA Testing Continuous Deployment Deploy DevOps
  5. 5. DevOps is a tool to operate a continuous delivery pipeline
  6. 6. The DevOps challenge to security • Our project requirements are visible to dev and ops • Our build, test and deploy process is entirely automated • Developers can deploy to prod directly • We deploy to prod multiple times per day • Amazon: deploy every 11.6 seconds • Etsy: deploys 25+ times/day • Gov.uk: deploys 30 times/day How can we do this securely?
  7. 7. Traditional Security approach • Dead documents • Reliance on manual processes • Tools don’t fit the deployment pipeline • Tool results don’t translate to business requirements
  8. 8. What can security learn from DevOps? • Security Testing is quality testing • Continuous monitoring (See OWASP AppSensor) • Automated all the things
  9. 9. Security Testing > Security Scanning • Scanners don’t test functional security • Tests have an expected outcome • Comprehensive tests ARE the requirements • Tests are code: stored by SCM
  10. 10. @Test public void change_session_ID_after_login() { First attempt: driver.get("http://localhost:9110/ropeytasks/user/login"); Cookie preLoginSessionId = getSessionId("JESSSIONID"); login("bob", "password"); Cookie afterLoginSessionId = getSessionId("JESSSIONID"); assertThat(afterLoginSessionId.getValue(), not(preLoginSessionId.getValue())); } public void login(String u, String p) { driver.findElement(By.id("username")).clear(); driver.findElement(By.id("username")).sendKeys(u); driver.findElement(By.id("password")).clear(); driver.findElement(By.id("password")).sendKeys(p); driver.findElement(By.name("_action_login")).click(); } • Navigation logic is embedded in the test • Selenium does not expose HTTP • Excludes non-developers
  11. 11. BDD-Security Testing Framework https://github.com/continuumsecurity/bdd-security • Tests written in JBehave • Automated Functional Security Testing • Non-functional security testing • Wraps security tools in tests: • OWASP ZAP • Nessus • Port scanner (built in)
  12. 12. BDD-Security example
  13. 13. BDD-Security Testing Framework • Must be able to automate manual security testing • Selenium + OWASP ZAP API • Tests must be understandable by all stakeholders • Behaviour Driven Development (BDD) with JBehave • Must fit into dev workflow and continuous integration pipelines • Runs in IDE, cmd line • Runs in Jenkins • Test results in JUnit wrapper +HTML in Jenkins • The logic of the security tests should be independent from navigation code • Provide a baseline of ready-to-use security tests
  14. 14. Demo • Ropey Tasks • Initial configuration • BDD wrappers around scanning tools • BDD tests of functional app security • Automated access control tests
  15. 15. Integration with Jenkins
  16. 16. Limitations • Email: Not implemented yet • Needed for self-reg • Account Lockout • Access control not Anti-CSRF aware • Test Maintenance • Use error checking wherever possible • When extending try to find generic solution • E.g.: ISomeBehaviour
  17. 17. Traditional Security approach
  18. 18. • Self verifying requirements • Automated testing • Testing inserted into CD pipeline
  19. 19. Resources: • https://github.com/continuumsecurity • OWASP ZAP Pure Java client API • Resty-Burp RESTful API into Burp Suite • Nessus Java Client • SSLTest Java SSL analyser • Related projects: • Gauntlt BDD wrapper for sec tools: https://github.com/gauntlt/gauntlt (Ruby) • Mittn Burp Integration: https://github.com/F-Secure/mittn (Python)
  20. 20. Questions? @stephendv

Notes de l'éditeur

  • Security is playing catchup with development practices again and although there’s a lot of hype around devops, I think there’s a lot security specialists can learn from it.
    What I’d like to focus on is how we can leverage current tools to provide continuous security testing at devops speeds.
  • I’d like to frame devops as a tool. So if devops is the means, then Continuous Delivery or Continuous Deployment is the end.
    What CD says is that instead of collecting our features into a batch release and then deploying into production.
  • As you ramp up from just Agile to Continuous Deployment, the amount of DevOps you’re doing needs to increase.
    Continuous delivery goes one step further than continuous integration in that you have a deliverable product. At the end of a Continuous delivery cycle you have a shippable product that can be delivered to staging environment or to user acceptance test environment.
    Devops starts becoming important when you move from CI to CD, because you need to delivery a working product in a realistic environment.
  • The continuous delivery practioners talk about a pipeline where
    Without tight integration and open communication between dev and ops, and without a lot of automation, it is not possible to operate a continuous delivery pipeline.
  • Given that Dev and Ops are working together in harmony they can operate this pipeline and deploy to production multiple times per day.
  • The answer of a traditional security team, would be more along the lines of a continuous annoyment model.

    Answering no to everything:
    You can’t have automated security tests at the frequency you want
    And you definitely can’t deploy without a pentest
  • If we want to fit security into a devops process we don’t have to start from scratch.
    Security is not special. I’d go as far as saying that software security should really be treated as a type of QA.
    And those tests should include security testing.
  • And when I say security testing, I’m talking about more than just automated scanning. Sure you need to use the static and dynamic analysers to find security bugs.
  • Junit and Selenium.
  • Taking these testing principals that are already used to test other aspects of software and putting them to use for security was the reason for the BDD-Security project.
  • This specification is executable.
  • Show ropeytasks
    Config file
    Show app_scan story change Medium to Low, create navigate method with selenium IDE.

    Show authentication stories, implement interfaces and run. They’re primarily functional

    Show nessus_scan story Better consistency than a manual process because the story is just a file, so version control

    Automated Access control tests by using three variables: the authorised user, the actions to get to a restricted page, and the sensitiveData that’s contained on that page.
    Explain @Restricted and the two authorisation tables that can be created.
    Implement viewBobsProfile
    Then show authorisation story

  • Because the framework is based on other standard technologies, it integrates quite easily with jenkins

×