Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

8

Share

Download to read offline

Continuous and Visible Security Testing with BDD-Security

Download to read offline

This presentation makes the case for adapting security requirements and processes to those used by developers. Specifically, it advocates the use of BDD (Given/When/Then) specifications to create self-verifying security requirements.

You've heard of infrastructure as code, with the BDD-Security framework, we can now write security-processes-as-code.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Continuous and Visible Security Testing with BDD-Security

  1. 1. Continuous and Visible Security Testing with BDD-Security Stephen de Vries @stephendv
  2. 2. About me • CTO Continuum Security • 16 years in security • Specialised in application security • Author of BDD-Security framework
  3. 3. Security testing still stuck in a waterfall world • Feedback from security testing is too late • Rely on outside security “experts”
  4. 4. Security is not something you add… …it’s something that’s build in, just like quality, scalability and performance
  5. 5. • Everyone is responsible for quality quality security • Move testing closer to the code security • Continuous automated testing ^
  6. 6. Difference of degree, not of kind Quality testing Security testing
  7. 7. Why What How Business Context Architecture App Features Threat Model Non-Functional Security Requirements Functional Security Requirements Security Tests
  8. 8. Security Requirements BDD-Specs (Given/When/Then) Visible Testable • Actionable • Up-to-date • Automated • Security Testing > Scanning
  9. 9. BDD-Security Testing Framework https://github.com/continuumsecurity/bdd-security BDD-Security = JBehave + Selenium + OWASP ZAP + Nessus + Internal security tools + Pre-written baseline security specifications
  10. 10. Examples: Infrastructure specifications
  11. 11. Security specifications for application itself Authentication: • Passwords should be case sensitive • Present the login form itself over an HTTPS connection • Transmit authentication credentials over HTTPS • When authentication credentials are sent to the server, it should respond with a 3xx status code. • Disable browser auto-completion on the login form • Lock the user account out after <X> incorrect authentication attempts
  12. 12. Manual Application Security Testing with OWASP ZAP HTTP/S Proxy
  13. 13. Manual Application Security Testing with OWASP ZAP HTTP/S Proxy ^ BDD-Security
  14. 14. Configuring BDD-Security for in-depth testing - Edit config.xml with app specific values - Create Java class that defines Selenium methods for: - openLoginPage - Login - isLoggedIn - Logout
  15. 15. Demo
  16. 16. Application Security Scanning with ZAP
  17. 17. Testing Access Control Can Alice see Bob’s data?
  18. 18. Demo
  19. 19. Part of Continuous Integration process • Ant job in Jenkins • Run job after deploy to test environment • Fail the build if tests fail
  20. 20. Demo
  21. 21. Summary • Security testing doesn’t need special treatment: it differs from software testing in degree, not in kind • Automated Security tests can be integrated into a CI/CD model • Automated Security tests should include more than just scanning • BDD tools provide self-verifying specification • BDD-Security project to jump-start your own security specs
  22. 22. Similar tools • ZAP-JUnit (Java) https://github.com/continuumsecurity/zap-webdriver • Guantlet (Ruby) http://gauntlt.org/ • Mittn (Python + Burp Intruder) https://github.com/F-Secure/mittn
  23. 23. Thank you I’ll be at Office Hours 13:45 Today Room: 211 @stephendv
  • matthewskelton

    Jun. 11, 2018
  • murenfeng

    Dec. 17, 2017
  • MichaelWang125

    Feb. 25, 2017
  • MarioAndrsAlvarezIre

    Dec. 7, 2016
  • wassila_hamila

    Sep. 13, 2016
  • NealFu2

    Apr. 2, 2015
  • kfealey

    Apr. 2, 2015
  • luissaiz

    Mar. 16, 2015

This presentation makes the case for adapting security requirements and processes to those used by developers. Specifically, it advocates the use of BDD (Given/When/Then) specifications to create self-verifying security requirements. You've heard of infrastructure as code, with the BDD-Security framework, we can now write security-processes-as-code.

Views

Total views

4,100

On Slideshare

0

From embeds

0

Number of embeds

82

Actions

Downloads

128

Shares

0

Comments

0

Likes

8

×