Automated Evil Driven Development

Includes behavior driven development, creation of evil user stories, definition of security baselines and how we can embed them in the CI/CD pipelines in an automated way. Presents some security tools that can help us, their pros/cons and how we can use them to create security tests. The demo focuses mainly on BDD-Security from "Continuum Security".

Transcript

1. NOVEMBER, 2017 Automated Evil Driven Development Sérgio Serrano @serranos Valmiky Arquissandas @kayvlim
2. Security at fast-paced environments Agenda 2
3. Security at fast-paced environments Empathy and behavior driven development Agenda 3
4. Security at fast-paced environments Empathy and behavior driven development Being Evil Agenda 4
5. Security at fast-paced environments Empathy and behavior driven development Being Evil Evil utility belt Agenda 5
6. Security at fast-paced environments Empathy and behavior driven development Being Evil Evil utility belt Automating Evil Agenda 6
7. Agenda 7 Security at fast-paced environments Empathy and behavior driven development Being Evil Evil utility belt Automating Evil Let’s do it with BDD-Security
8. Agenda 8 Security at fast-paced environments Empathy and behavior driven development Being Evil Evil utility belt Automating Evil Let’s do it with BDD-Security Demo
9. “ Security at fast-paced environments Automated Evil Driven Development
10. Too many challenges Security at fast-paced environments 10
11. Too many challenges DevOp”ish” organizations promote self-service Security at fast-paced environments 11
12. Too many challenges DevOp”ish” organizations promote self-service Let’s all deploy to production! Security at fast-paced environments 12
13. Too many challenges DevOp”ish” organizations promote self-service Let’s all deploy to production! Clash of cultures Security at fast-paced environments 13
14. “Human sacrifice. Dogs and cats living together. Mass hysteria.” Security at fast-paced environments 14 Dr. Peter Venkman, end of the world, Ghostbusters, 1984.
15. Security at fast-paced environments 15 Developers... let’s write down their names… Death Note Manga series by Tsugumi Ohba and illustrated by Takeshi Obata
16. Security at fast-paced environments 16 Product people... let’s write down their names… Death Note Manga series by Tsugumi Ohba and illustrated by Takeshi Obata
17. Security at fast-paced environments 17
18. The Amazing World of Gumball TV series from Cartoon Network. Created by Ben Bocquelet. Security at fast-paced environments 18
19. Let’s all try not to become John Pesche, the alcoholic Security Guy... Security at fast-paced environments 19
20. We can actually do better Empathy and behavior driven development 20
21. Disclaimer: no kumbaya singing is required Empathy and behavior driven development 21
22. Empowerment of teams Security at fast-paced environments 22
23. Empowerment of teams Reusable security Security at fast-paced environments 23
24. Empowerment of teams Reusable security Automation Security at fast-paced environments 24
25. Empowerment of teams Reusable security Automation Risk driven decisions Security at fast-paced environments 25
26. “ Empathy and behavior driven development Automated Evil Driven Development
27. All stakeholders should be called to participate Empathy and behavior driven development 27
28. All stakeholders should be called to participate A common language to describe features is key Empathy and behavior driven development 28
29. All stakeholders should be called to participate A common language to describe features is key All in all, everyone is interested in the same end goal... Empathy and behavior driven development 29
30. A sustainable and successful product Empathy and behavior driven development 30
31. Goto is not your friend and the security team should handle it with care Empathy and behavior driven development > consistency 31
32. Goto is not your friend and the security team should handle it with care Bake security concerns in the Software Development Life Cycle (SDLC)* * not really something new... Empathy and behavior driven development > consistency 32
33. Goto is not your friend and the security team should handle it with care Bake security concerns in the Software Development Life Cycle (SDLC)* Scale security with security champions * not really something new... Empathy and behavior driven development > consistency 33
34. Goto is not your friend and the security team should handle it with care Bake security concerns in the Software Development Life Cycle (SDLC)* Scale security with security champions Scale security by providing self-services for teams * not really something new... Empathy and behavior driven development > consistency 34
35. Goto is not your friend and the security team should handle it with care Bake security concerns in the Software Development Life Cycle (SDLC)* Scale security with security champions Scale security by providing self-services for teams Develop product features with security in mind * not really something new... Empathy and behavior driven development > consistency 35
36. Empathy and behavior driven development > teams 36 We still need to find a better way to get everyone working as a team
37. Empathy and behavior driven development > teams 37 We will get to that later in this talk...
38. “ Being Evil Automated Evil Driven Development
39. Stephen King, The Rolling Stone Interview, 2014 Evil is innate Evil is inside us. The older I get, the less I think there’s some sort of outside devilish influence; it comes from people. “
40. Being Evil 40 Source: https://www.flickr.com/photos/mquest/699159895/
41. The usual approach goes something like this: Being Evil 41
42. The usual approach goes something like this: 1. Develop the product Being Evil 42
43. The usual approach goes something like this: 1. Develop the product 2. Hire an external company to do the pentesting (if you're lucky) Being Evil 43
44. The usual approach goes something like this: 1. Develop the product 2. Hire an external company to do the pentesting (if you're lucky) 3. Fix whatever was found (if you're REALLY lucky) Being Evil 44
45. This inevitably leads to … DOOM! Being Evil 45
46. Being Evil 46
47. User stories are short descriptions of a feature Descriptions are from the point of view of the customer The customer can be external or internal Being Evil > User Stories 47
48. As a <type of user>, I want to do <an action> so that <consequence> As an authenticated admin of an Internet Forum I want to export the database to do a backup Being Evil > User Stories 48
49. Evil Stories are User Stories for Evil which by definition are: • Used to express threats from a bad actor perspective • Incorporated in Agile development • Used in the product backlog for including security concerns Being Evil > Evil User Stories 49
50. As an unauthenticated evil user of an Internet Forum I want to export the database so that I can request a ransom to the Internet Forum owners Being Evil > User Stories 50
51. 1. Know your system 2. Select a security topic 3. Create Evil User Story 4. Add Evil User Story to the Product Backlog Being Evil > How to create one 51
52. Authentication Session management Access control Input validation Output encoding/escaping Cryptography Being Evil > Security topics 52 Error handling Logging Data protection Communication security HTTP security features
53. • As an Evil Duck, I want to send bad data in HTTP headers, so I can access data and functions for which I'm not authorized • As an Evil Duck, I want to access multiple ports in the webserver other than port 80 or port 443 • As an Evil Duck, I want to use a revoked token to access protected resources Being Evil > Examples 53
54. Being Evil > Examples and Gherkin 54 http://gauntlt.org/
55. OWASP Application Security Verification Standard (ASVS) Project Being Evil > Get inspiration 55
56. Being Evil 56
57. “ Evil utility belt Automated Evil Driven Development
58. • Mittn • Gauntlt • BDD-Security Include all of the above in CI/CD pipelines Evil utility belt > BDD testing frameworks 58
59. Evil utility belt > testing frameworks > Gauntlt 59 • Uses Ruby and Cucumber • Cucumber is a BDD test framework that uses Gherkin as its language • Tools: ◦ Attack tools: curl, nmap, sqlmap, Garmr ◦ TLS: SSLyze • Source code: https://github.com/gauntlt/gauntlt • Last commit: December 10th 2016
60. Evil utility belt > testing frameworks > BDD-Security 60 • Uses Java and Cucumber • Cucumber is a BDD test framework that uses Gherkin as its language • Tools: ◦ Selenium/WebDriver ◦ Attack tools: ZAP (included in the package), Nessus ◦ TLS: SSLyze • Source code: https://github.com/continuumsecurity/bdd-security • Last commit: July 14th 2017
61. • Uses Python and Behave • Behave is a BDD test framework, cucumber-like for Python • Tools: ◦ Attack tools: Burp Suite, radamsa ◦ HTTP API fuzzing ◦ TLS: SSLyze • Source code: https://github.com/F-Secure/mittn • Last commit: August 11th 2016 Evil utility belt > testing frameworks > Mittn 61
62. • Include the security features in the source repository • All stakeholders can see the product security features • Validate security features and avoid non-compliant code to be deployed to production Evil utility belt > Evil BDD 62
63. • Reuse the stories for other systems • Extend current test frameworks: ◦ add new features ◦ add new scenarios ◦ add new tools • Community: contribute to common set of security features Evil utility belt > Evil BDD 63
64. “ Automating Evil Automated Evil Driven Development
65. Integration with CI/CD pipelines consists of adding another testing framework, during the integration testing stage. Automating Evil > integration with CI/CD pipelines 65 DEPLOY Commit Continuous Integration tests OK? Yes No
66. Failure of security tests is equivalent to a failure in integration tests: the application should not be deployed until issues are resolved. Automating Evil > integration with CI/CD pipelines 66 DEPLOY Commit Continuous Integration tests OK? Yes No
67. “ Let’s do it with BDD-Security Automated Evil Driven Development
68. Let’s do it with BDD-Security > Structure 68 Feature Scenario 1 Scenario 2 Scenario 3 Scenario 4
69. Let’s do it with BDD-Security > Structure > Feature 69 Authentication Scenario 2 Scenario 3 Scenario 4 Scenario 1
70. Let’s do it with BDD-Security > Structure > Scenario 70 Authentication Receive login form over an HTTPS Scenario 2 Scenario 3 Scenario 4
71. Let’s do it with BDD-Security > Structure > Scenario 71 Authentication Receive login form over an HTTPS Send auth credentials via HTTPS Scenario 3 Scenario 4
72. Let’s do it with BDD-Security > Structure > Scenario 72 Authentication Receive login form over an HTTPS Send auth credentials via HTTPS Throttle user after N failed logins Scenario 4
73. Let’s do it with BDD-Security > Structure > Scenario 73 Authentication Receive login form over an HTTPS Send auth credentials via HTTPS Throttle user after N failed logins Passwords should be case sensitive
74. Feature: Session Management Scenario: Issue a new session ID after authentication Scenario: Invalidate the session when the user logs out Scenario: Invalidate the session after a period of inactivity Scenario: Set the 'secure' flag on the session cookie Scenario: Set the 'httpOnly' flag on the session cookie Let’s do it with BDD-Security > Example > Natural language 74
75. Let’s do it with BDD-Security > Example > Gherkin 75
76. Let’s do it with BDD-Security > configuration 76
77. Let’s do it with BDD-Security > configuration 77
78. “ Demo Automated Evil Driven Development
79. Continuous Security in the DevOps World by Julien Vehent from Mozilla https://jvehent.github.io/continuous-security-talk/ Continuous Security Testing in a DevOps World by Stephen de Vries https://www.youtube.com/watch?v=M_uZPArkln4 References 79
80. “ Questions? Automated Evil Driven Development
81. @serranos Sérgio Serrano @kayvlim Valmiky Arquissandas