Threat-Modeling-as-Code: ThreatPlaybook AppSecUSA 2018 Presentation
Threat Modeling is critical for Product Engineering Team. Yet, even in the rare event that it’s performed, its performed without actionable outputs emerging from the exercise. It is relegated to the status of what a “Policy/Best Practice Document”, which it shouldn’t be. I believe that Threat Models are playbooks of Product Security Engineering. I feel that the best way to do threat modeling is to integrate it into the Software Development Lifecycle (SDL). In addition, I believe that Threat Models should produce actionable outputs that can be acted up on by various teams within the organization. To address this lacuna, I have developed “Automaton” - An Open Source “Threat Modeling as Code” framework, that allows product teams to capture User Stories, Abuser Stories, Threat Models and Security Test Cases in YAML Files (like Ansible). With the help of Test Automation Frameworks (in this case, Robot Framework) Automaton allows the product engineering team to not only capture Threat Models as code, but also trigger specific security test cases with tools like OWASP ZAP, BurpSuite, WFuzz, Sublist3r, Nmap and so on. The benefits are three-fold. One - For teams to use Threat Modeling as a first-class citizen(with code). Facilitating Iterative and Updated Threat Models and Security Test Cases, as the product evolves (not a stationary document). Two - For Threat Modeling to become actionable. Product Teams can use this Framework to compose “Recipes” where User Stories (Functionality) leads to Abuser Stories (Threat Profiles) which lead to Threat Models (scenarios), that are used to create Security Test Cases (which kick off certain tools) based on the Recipes written for the Test Cases. Three - This approach leads to a convergence of Threat Modeling and Security Testing, allowing teams to improve both security testing and threat modeling based on results produced through this framework.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Threat-Modeling-as-Code: ThreatPlaybook AppSecUSA 2018 Presentation
Similar to Threat-Modeling-as-Code: ThreatPlaybook AppSecUSA 2018 Presentation (20)
Recently uploaded
Recently uploaded (20)
Threat-Modeling-as-Code: ThreatPlaybook AppSecUSA 2018 Presentation
- 1. Threat Modeling-as-Code with ThreatPlaybook Abhay Bhargav - we45 abhaybhargav
- 2. Yours Truly • Founder @ we45 • Chief Architect - Orchestron • Avid Pythonista and AppSec Automation Junkie • Speaker at OWASP and InfoSec Conferences worldwide • Lead Trainer - we45 Training and Workshops • Co-author of Secure Java For Web Application Development • Author of PCI Compliance: A Definitive Guide
- 3. Today's Session • Some Issues we see with Threat Modeling as it’s done today • The “as-code” movement and Threat Modeling’s role in it • ThreatPlaybook and philosophy behind it • Completing the Automation Cycle with ThreatPlaybook
- 4. Inspirations and Thanks • Adam Shostack and Brook Schoenfield for their inputs • Fraser Scott for his suggestions • Myriad twitter convos with Threat Modeling geeks (read: Robert Hurlbut) • Jonathan Marcil for Threat Modeling Toolkit • Chris Gates for metta (carnal0wnage) => MITRE ATT&CK Framework
- 6. And a few demos…. Demo Gods! Please let this work
- 7. Current Problems with Threat Modeling
- 10. Some Problems
- 11. Some Problems
- 12. Some Problems
- 13. What’s worse…
- 14. • Threat Modeling is usually undertaken at the beginning a project and then forgotten - Updated annually/not at all (usual case) What’s worse…
- 15. • Threat Modeling is usually undertaken at the beginning a project and then forgotten - Updated annually/not at all (usual case) • Not integrated with the Agile SDLC What’s worse…
- 16. • Threat Modeling is usually undertaken at the beginning a project and then forgotten - Updated annually/not at all (usual case) • Not integrated with the Agile SDLC • No link with user stories/functionality What’s worse…
- 17. • Threat Modeling is usually undertaken at the beginning a project and then forgotten - Updated annually/not at all (usual case) • Not integrated with the Agile SDLC • No link with user stories/functionality • Security teams often just do it themselves What’s worse…
- 18. • Threat Modeling is usually undertaken at the beginning a project and then forgotten - Updated annually/not at all (usual case) • Not integrated with the Agile SDLC • No link with user stories/functionality • Security teams often just do it themselves • (Unpopular Opinion alert): Threat Modeling (for many) has become largely about generating Diagrams and not actually modeling Threats What’s worse…
- 19. And Yet…
- 20. But….
- 21. The Result
- 22. Benefits of Threat Modeling
- 23. Security in DevOps Plan Code Build Test Release Deploy Operate Monitor Threat modeling SAST Security - Composition DAST IAST Security in IaC Security monitoring & attack detection
- 24. Security in DevOps Plan Code Build Test Release Deploy Operate Monitor Threat modeling SAST Security - Composition DAST IAST Security in IaC Security monitoring & attack detection Threat Modeling Inputs - Go here!
- 25. On the other hand….
- 26. “Spec” based Systems • Frameworks that allow users to define deployments/delivery without having to write complex code • Abstract the complexity away from the user • Increase Cross-Functional workflows • Make everything “As-Code”
- 27. Application Delivery by Spec
- 28. Our Philosophy for Threat Modeling • We see Threat Models as “Playbooks” for Security • More power to collaborative Threat Modeling • Iterative Threat Modeling • Manageable Threat Modeling
- 29. The Idea YAML Spec Based Orchestration Tools AppSec Automation Threat Modeling
- 34. Build Threat Model Functionality/User Stories
- 35. Build Threat Model Functionality/User Stories Abuser Stories
- 36. Build Threat Model Functionality/User Stories Abuser Stories Threat Scenarios
- 37. Build Threat Model Functionality/User Stories Abuser Stories Threat Scenarios
- 38. Build Threat Model Functionality/User Stories Abuser Stories Threat Scenarios Security Test Cases
- 39. Build Threat Model Functionality/User Stories Abuser Stories Threat Scenarios Security Test Cases
- 40. Build Threat Model Functionality/User Stories Abuser Stories Threat Scenarios Security Test Cases Invoke Strategic Automation
- 41. Build Threat Model Functionality/User Stories Abuser Stories Threat Scenarios Security Test Cases Invoke Strategic Automation
- 42. ThreatPlaybook (YAMLs) (define Threat Models) ThreatPlaybook Robot Library OWASP ZAP Robot Library Other SAST/DAST/SCA Robot Library Invoked in Robot Script (Automation) Target App
- 43. Process - ThreatPlaybook • Write Threat Models in YAML files: • Iterative and modular • Link (or not) to Security Test Cases • Run Automation • Generate Report with Vulnerabilities linked with Threat Models
- 44. Who can use ThreatPlaybook? • Engineering Teams: • Develop and scale Iterative Threat Models • Run a Security Pipeline with Threat Modeling included • Pentesting Teams: • Attack-driven Threat Modeling with Pentest Automation
- 45. Demo Time Demo Gods! Please let this work
- 46. Hard Problems & Questions?
- 47. Hard Problems & Questions?
- 48. Hard Problems & Questions?
- 49. Hard Problems & Questions? LOOK AT THE THREAT MODEL + Linked Vulnerability Assessment Results!
- 50. Hard Problems & Questions?
- 51. Hard Problems & Questions?
- 52. Hard Problems & Questions?
- 53. Hard Problems & Questions? Look at our Iterative Threat Model with this Feature in ThreatPlaybook!
- 54. Hard Problems & Questions?
- 55. Hard Problems & Questions?
- 56. Hard Problems & Questions?
- 57. Hard Problems & Questions? Our Threat Models have Security Test Cases + Automation of those Test Cases in CI/CD!
- 58. Hard Problems & Questions?
- 60. Robot Framework? Why? • Flexible Natural Language Syntax - FTW!
- 61. Robot Framework? Why? • Flexible Natural Language Syntax - FTW! • Easy to develop API for Tools
- 62. Robot Framework? Why? • Flexible Natural Language Syntax - FTW! • Easy to develop API for Tools • Modular
- 63. Robot Framework? Why? • Flexible Natural Language Syntax - FTW! • Easy to develop API for Tools • Modular • Comes with Reporting out of the Box
- 64. Robot Framework? Why? • Flexible Natural Language Syntax - FTW! • Easy to develop API for Tools • Modular • Comes with Reporting out of the Box • Python and Java Support 😁
- 65. Plus++ • Library Support for Selenium, Appium and Multiple test frameworks • Support for REST API Testing Frameworks • Support for OS libs, etc
- 66. Security Tools - API that we have developed • DAST • OWASP ZAP • BurpSuite Pro • Arachni • SAST • NodeJSScan • Brakeman • Bandit • Recon/Mapping • Nmap • Wfuzz (Directory Bruteforce only) • SubList3r • SCA • OWASP Dependency Check • NPM Audit • PyUp Safety • Snyk (In Development) • Cloud • Bucketeer • weirdAAL (Selected for Dev) • Mobile: • MobSF
- 67. The future • Objective: To make this the Kubernetes of Application Security • Add a CLI for user interaction => Happening in final release 1.2 • Add capabilities for Trust Boundaries • Look at a more comprehensive Diagramming API • Contributors Welcome :)
- 69. Thank you! Twitter: @abhaybhargav Twitter: @we45 LinkedIn: abhaybhargav Github: github.com/we45