AppSec US 2018 (Please, make sure you register to attend)

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.