Izar describes the attributes required by threat modelling approaches in order to succeed in Agile dev environments, how to build an organization that continuously threat models new stories, how to educate devs and raise security awareness, and PyTM, a tool that lets you express TMs via Python code and output data flow diagrams, sequence diagras, and reports.
Threat Modeling Goals
According to Izar, threat modelling is:
A conceptual exercise that aims to identify security-related flaws in the design of a system and identify modifications or activities that will mitigate those flaws.
In traditional waterfall development processes, there could be a large upfront threat modellinng session performed upfront during the design phase, which would accurately model the system to be built. With Agile, this approach is no longer effective.
Izar determined the following goals he needed from a TM approach for it to be effective at Autodesk:
-
Accessible: can a product team do it independently after a brief period of instruction? Can they keep doing it?
-
Scalable: can the same thing be done over many teams and products? In a short time?
-
Educational: can it teach instead of correct?
-
Useful: are the results found useful for both product and security?
-
Agile: is it repeatable, does it negatively impact the product team’s velocity?
-
Representative: how does the system being modeled compare with the model?
-
Unconstrained: once the “known suspects” are evaluated, is the team led to explore further?
Existing Approaches Didn’t Cut It
Izar ranked several current approaches against these goal criteria and found they were all lacking in some respect, ranging from not being scalable (requiring SMEs), being too heavy-weight, overly constraining the process (discouraged participants from imagining other threats), and more.
Continuous TMing: How to Threat Model Every Story
-
Build a baseline, involving everyone.
-
Designate one or more “threat model curators,” who will be responsible for maintaining the canonical threat model document and the findings queue.
-
Have devs evaluate every story: “Does this have any security relevance?”
-
If not, continue as usual. If it does, either address the issue and document it as a mitigated finding, or add it as a “threat model candidate finding” for the curator to review.
-
At Autodesk, they track these via labels on Jira tickets.
-
-
Make sure your curators are on top of the TM finding and candidate finding queues.
How do Devs Know What has Security Relevance?
Here Izar takes inspiration from Richard Feynman, who said to teach principles, not formulas.
Do your own homework. To truly use first principles, don’t rely on experts or previous work. Approach new problems with the mindset of a novice. Truly understand the fundamental data, assumptions and reasoning yourself. Be curious. -Richard Feynman
Example topics that are security-relevant
We are training our developers wrong. We are providing huge amounts of information that do not correspond to huge amounts of useability. We are doing the busywork of teaching people how the RSA algorithm works without focusing on the aspects of choosing the right key length, algorithm and secret protection scheme that their system needs.
Principles Checklist
Autodesk’s principles checklist follows a “if this then that” model – devs only need to review the items relevant to what they’re currently working on.
Example items from the checklist
Importantly, all of the description used is written in terms devs understand, rather than security jargon, so they can easily determine if an item is relevant.
The checklist is small, ideally no more than one double sided printed page so it can be printed and kept at hand.
The “then that” side is not prescriptive. It pushes the developer to search for info relevant to the environment or framework they’re using. This is done on purpose to: keep the list short, make it somewhat open-ended, and to tickle most dev’s innate curiosity. The checklist gives pointers but not “absolute solutions.”
The checklist is backed by further documentation and live support by the security team.
Limitations
Izar has found that a primary challenge is convincing dev teams that the Subject List is not a threat library and that the Checklist is not a requirements list: these are starting points, not an exhaustive list.
Following this process won’t yield perfect TMs, and that’s ok – it’s a process that evolves over time. As long as the TM is better than it was before, that’s valuable progress.
An SME or security team is still necessary for education, and with anything, the resulting TM is only as good as the quality of the data informing it.
Current TM Approaches
Some tools start with a questionnaire (“What do you want to build?”) and generate a list of requirements that the developers must follow. Others get a description of the system and generate threats based on characteristics of the design.
But developers write code, why not let them define a threat model in code?
3 “Threat Model as Code” Approaches
ThreatSpec by Fraser Scott is threat modeling IN code: as code is written, the threat model is described in comments inline with the code. For example:
// @accepts arbitrary file writes to WebApp:FileSystem with
// filename restrictions
// @mitigates WebApp:FileSystem against unauthorised access
// with strict file permissions
func (p *Page) save() error {
filename := p.Title + ".txt"
return ioutil.WriteFile(filename, p.Body, 0600)
}
ThreatPlaybook by Abhay Bhargav is threat modeling FROM code: deriving previously identified threats from other tools, validating or discovering those threats present in code, and providing a proper language to talk about these threats. You build a library of threats, run your tools, and marry findings with the threats you built before. Abhay discussed ThreatPlaybook in his AppSec Cali 2018 talk Robots with Pentest Recipes.
login_user:
description: |
As an employee of the organization,
I would like to login to the Customer API and manage Customer Information
abuse_cases:
external_attacker_account_takeover:
description: As an external attacker, I would compromise a single/multiple user accounts to gain access to sensitive customer information
threat_scenarios:
sql injection user account access:
description: External Attacker may be able to gain access to user accounts by successfully performing SQL Injection Attacks against some of the unauthenticated API Endpoints in the application
severity: 3
cwe: 89
cases:
- sql_injection_auto
- generic_error_messages
- database_hardening_check
PyTM by Izar and a few friends, is threat modeling WITH code; using code to express the system to be modeled.
PyTM – Creating a Threat Model
In PyTM, you create a threat model in Python code, describing the relevant boundaries, actors, and servers using Python objects.
from pytm.pytm import TM, Server, Datastore, Dataflow,
Boundary, Actor, Lambda
tm = TM("my test tm")
tm.description = "another test tm"
User_Web = Boundary("User/Web")
Web_DB = Boundary("Web/DB")
VPC = Boundary("AWS VPC")
user = Actor("User")
user.inBoundary = User_Web
web = Server("Web Server")
web.OS = "CloudOS"
web.isHardened = True
my_lambda = Lambda("cleanDBevery6hours")
my_lambda.hasAccessControl = True
my_lambda.inBoundary = Web_DB
tm.process()
Once the threat model has been defined, PyTM can be used to generate data flow diagrams, sequence diagrams, or a report.
PyTM – how is it being used?
Currently Autodesk is using PyTM during team meetings to create an initial TM diagram.
It facillitates discussions and rapid iteration with product teams, as you can easily review the generated diagrams: “is it missing this attribute?”, “why is this a threat?”, “what if… ?”
PyTM allows you to keep threat models in version control, together with the code it describes, and you can generate automated, standard threat model reports.
Is keeping these TM files up to date feasible?
I love all of these properties, but you still have the fundamental challenge of keeping these TM files up to date with the architecture and current feature set of the code, which seems like it’d be a burden on dev teams or at least hard to maintain at scale. I’d be curious to hear Izar’s thoughts on the successes and challenges of this approach after a year or two.