I spent a large portion of 2019 figuring out how to do threat modeling at my company. After failing twice, I finally constructed something that my devs seemed to like enough to actually use. I generally don’t like talking about my ideas that haven’t been proved out, but the pilot was so successful that I am going to talk about it. I didn’t invent anything special, I just stole a bunch of other smart people’s ideas and glued them together.
What is Threat Modeling?
Threat modeling is the process by which potential threats can be identified and enumerated sometime during the SDLC and mitigations can then be prioritized. I say sometime during the SDLC because, even though we would like to do it during the design phase, let’s be real and stop pretending. We are happy if devs do it at all.
A little background
At the beginning of 2019, I told my boss I was going to roll out threat modeling, and that was a mistake. I thought it was going to be super easy: I had my copy of the Threat Modeling Bible by Adam Shostack, I went to Avi Douglen’s talk on Value Driven Threat Modeling at AppSecUSA 2018, and the work was basically going to do itself. Right?
Inspiration
The next few sections are the things that inspired my path down the hole known as Threat Modeling.
STRIDE, Attack Trees, Data-Flow diagrams, and those four questions
These are the four questions for threat modeling that Adam Shostack came up with and they are:
What are we working on?
What can go wrong?
What are we going to do about it?
Did we do a good job?
This is threat modeling. Answer these questions and you are gold.
Value Driven Threat Modeling
This was a great talk by Avi Douglen at AppSecUSA. I really wanted this to work; my company used gherkin to document their business requirements so the devs are basically already doing this shit. We ultimately ran into the problem of functional vs non-functional requirements. Functional requirements define what an application does. For example: “I need to be able to upload important business documents to this app.” A non-functional requirement is how it works. So in the example above, a non-functional requirement would be: “Must only accept pdf and docx files under 50Mb.” So it turns out that a lot of security requirements are actually non-functional requirements and not functional requirements. So gherkin basically is for functional requirements (at least how we use it). For those of you that do not know what gherkin; it is a cucumber that has been pickled. Cucumber is “a software tool that supports behavior-driven development.” Gherkin is the syntax used in cucumber to describe behaviors (business requirements).
Threat Modeling Lite Process
This is meant to be a super light-weight process. Threat modeling is dialog not discussion (someone said this, I just stole it); a quick brainstorming session to think up possible threats. The point of this exercise is to get devs thinking about possible security threats in the design phase. The purpose is not to create a full threat model.
Who should be Threat Modeling?
At least 3 people are needed to do threat modeling:
A Facilitator - The facilitator’s job is to document the threat model and to ask questions if threat modelers get stuck or run out of ideas.
The developer of the service or feature.
Someone else familiar with the product or the feature (could be another dev, a dev manager, product owner, etc).
I suggest 3-6 people including the facilitator. Having too many people might stop someone from engaging, especially at first. The facilitator should be encouraging, there are no bad ideas in a brainstorming session. Everything that is written down can just as easily be deleted.
How to Threat model
Step 1
The facilitator will ask “How would you attack your application/service?” or “How could your application/service be attacked?”.
Step 2
The threat modelers answer the question the facilitator asks.
The facilitator may use the sample questions (below) if the session gets stuck.
Step 3
Document the threats in the secure.yaml file.
Push the file to the code repo.
Step 4
Relevant threats should have tickets created for them.
Some things to note when threat modeling:
Even though you might not be in a Zero Trust environment, threat model like you are.
You should spend no more than 1 to 5 minutes per feature, and no more than 30 minutes at a time when threat modeling a full service or application.
Remember that: “All threat models are wrong, but some are useful” (thanks Avi). Keep the threat model on the useful side and remember, we are not trying to threat model everything, we are trying to document the important things.
Sample Questions
I was super impressed with the Autodesk Continuous Threat Modeling questions. So we use these questions as things to ask when the dialog stops and we need to get the brain juices flowing again.
How we document
We came up with the secure.yaml file. The secure yaml has 4 sections. First the service section, this is where we document the service, its owners and a few key properties. The second is the metadata, free form text to add whatever useful information we want. The third is the dependencies section, this is where we add our external and internal dependencies. External would be external to the company and internal would be external to the application but internal to the company or system. The last is the threat model for the service.
secure.yaml
service:
# Name of service being documented
name: my_service
# Owner of service
team: team_a
# Type of service: {"site", "rest", "soap"}
# For now, no restrictions
type: site
# Free-form name of host location
location: azure
# Boolean
external: true
# Boolean
production: true
# Array of data classifications
# Free-form
data_identifiers:
- fname
- lname
- ssn
# Optional metadata about service
# This section is freeform, and below is just an example
# This section is not validated
metadata:
# hostnames of service. Array
hosts:
- qa1.internal.xyz
- qa2.internal.xyz
# location to acce
url: https://prod.example.com:888
docs_url: https://mydocs.example.com
repository: https://git.example.com/my_service
# Resources this service consumes
# The more data the better, but fields are optional
providers:
external:
- name: salesforce
# url is optional
url: my_service.salesforce.com
- name: adwords
# url is optional
url: adwords.com
internal:
- name: auth_service
# (below isn't needed because we can pull from other files)
# url: auth.site.com
threat_model:
- threat:
title:
status:
risk:
cwe:
description:
mitigation:
tags:
Next Steps
We are working on some open source scripts/apps to ingest these secure.yml files from github and gitlab to give useful data and insights.
References:
About the Author
Ray is a Life Coach and Conspiracy Theorist. He does AppSec in his non-spare time for money. Twitter