Threat Model Every Story: Practical Continuous Threat Modeling Work for Your Team

Izar Tarandach, Lead Product Security Architect, Autodesk twitter, linkedin
abstract slides video

Threat Modeling Goals

According to Izar, threat modelling is:

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

1. Build a baseline, involving everyone.

   • Use whatever technique works for your team, it doesn’t have to be perfect.

2. Designate one or more “threat model curators,” who will be responsible for maintaining the canonical threat model document and the findings queue.

   • These people don’t have to tech leads, they just need to mind the queue and make sure issues get the appropriate attention.

3. 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.

4. 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.

So they created a Continuous Threat Modeling Handbook that lists the functional areas security will generally care about (e.g. authentication, authorization, crypto, etc.) as well as a Secure Developer Checklist - Continuous Threat Modeling that can be used by devs to verify that the principles have been followed at implementation time.

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.

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.

Here’s a video demo of running ThreatPlaybook, and an example repo. Abuse cases are listed in YAML, for example:

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.

Useful Threat Modeling Links

• Check out the #threat-modeling channel in the OWASP Slack

• OWASP Application Threat Modeling page

• SAFECode “Tactical Threat Modeling” whitepaper