Whiteboards are no longer adequate for modeling AppSec threats
UPDATED ‘Threat modelling as code’ is poised to supplant whiteboard diagrams as the definitive AppSec risk mapping paradigm, Black Hat USA attendees heard yesterday.
Used alone, says DevSecOps trainer and security architect Christian Schneider, classic threat modeling is unacceptably static in an evolving risk landscape, especially given the routine use of automatic security scans during pipeline-as-code development.
Therefore, Schneider implies, new tools are needed for agile threat modelling.
He unveiled such a toolkit, the open-source Threagile, during yesterday's arsenal track at Black Hat 2020, which was held online due to the coronavirus pandemic.
Read more of the latest Black Hat 2020 news
Publicly released on GitHub and Docker on Tuesday (August 4), Threagile models its architecture and assets as a YAML file directly inside the integrated development environment (IDE).
When the toolkit is executed, 40 built-in risk rules – and any custom rules created – are checked against the architecture model.
The upshot is reports on identified risks, their severity, mitigation steps, and the risk tracking state, as Schnieder explains in the video below, where he repeats his Arsenal session for DEF CON.
DevSecOps-ready
Threagile, which can be executed as a simple Docker container, is very much DevSecOps-ready, says Schneider.
Running as a command line or a REST server on-premises and generating JSON output simplifies the tool’s integration “into AppSec CI/CD-Pipelines”, he told The Daily Swig ahead of his presentation.
To achieve continuous modelling, Threagile adopts the threat-model-as-code paradigm by combining the “best of both worlds”, says Schneider.
“The declarative threat model data is just text” – a YAML file that offers “checking-in into GitHub along with the source-tree, diffing, collaboration, etc, plus being [more] readable than pure source code [is for] humans”.
Schneider added: “Major IDEs also have code-like features for YAML-like autocompletion and schema checking. Threagile also supports live editing templates and a schema for the YAML file for auto-completion and syntax checking in IDEs.”
Since risk-rules and model-macros are coded in simple-to-code ‘Go’ language, Threagile is readily extended to support custom risk-rules, for example for corporations with individual policies they’d like to check/enforce corporate-wide, and model-macros for wizard-style automation of common model tasks, says Schneider.
‘Visual feedback loop’
Threagile’s virtue lies in “continuously extending” the model.
Eschewing diagrams of boxes and clouds linked by lines, it starts “with a YAML file that declaratively describes your Data-Assets, the Technical-Asset (components), and their Communication-Links and the Trust-Boundaries”.
“The rest is auto-generated from that model by applying risk-rules and auto layout techniques,” he adds. “Even nice data flow diagrams are auto-generated, matching the declarations from the model file.”
RELATED KubiScan: Open source Kubernetes security tool showcased at Black Hat 2020
This retains “the visual feedback loop”, which alerts users to any key elements they have neglected to model, or anything modelled in the wrong abstraction altitude.
Security bods needn’t start with a diagram nor, more importantly, edit one as an agile project evolves, he adds.
Agile teams “simply extend the model YAML file in their IDE (not leaving their tools) in every sprint by simply adding what they’ve worked on in just a few lines of YAML”.
Threagile for beginners
Threagile ingenues should “start small”, he advises. “Simply collect the most important data-assets, technical-assets and their communication-links into Threagile, then evolve as you iterate in your sprints,” Schneider says.
Threat modellers are also urged to embrace Threagile’s auto-completion and live editing support to simplify model file editing.
Any risks identified during workshops can also be added to the YAML file.
“Architecture-inherent risks that no tool can identify” can be added to the model file, where they are processed like their automatically detected counterparts.
If users are unable to create a custom risk rule to detect these risks, they should “create a template to be able to quickly add it [to] other projects”.
Tracking and adding your risk mitigation state to the model file, meanwhile, “enables Threagile’s use inside DevSecOps pipelines, ensuring that no critical risks are left unchecked when rolling out”.
Schneider’s most important advice, he adds, is also the simplest to implement.
“Keep editing the YAML model file on every sprint,” he says. “It’s the same IDE you use while coding anyway, and mostly it’s just a few lines of YAML to add.
“Checked-in along with the source-tree, it’s a nice way of documenting how your project evolves. The more current the model file reflects the current project’s state, the more you’re doing continuous threat modelling in an agile way.”
A video of Christian Schneider's Arsenal session was embedded into this article on August 11
READ MORE Black Hat USA: Your guide to the top web hacking sessions in 2020
