Threat Model Thursday: Github's Approach
A bunch of people recently asked me about Robert Reichel’s post 'How We Threat Model,' and I wanted to use it to pick up on Threat Model Thursdays.A bunch of people recently asked me about Robert Reichel's post "How We Threat Model," and I wanted to use it to pick up on Threat Model Thursdays, where I talk about process and practices. My goal is always to build, and sometimes that involves criticism.
So let me start by saying I like the way that they frame it: "At GitHub, threat modeling isn’t necessarily a specific tool or set of deliverables—it’s a process to help foster ongoing discussions between security and engineering teams around a new or existing system. A threat model is a collaborative security exercise where we evaluate and validate the design and task planning for a new or existing service. This exercise involves structured thinking about potential security vulnerabilities that could adversely affect your service." I think they probably have many useful conversations in that frame.
I did want to point out and discuss four aspects of the post: three that are there and one that's not. They are reviews, meeting and process, universality, and the one that's not: specific steps.
The first thing to say is that their process is centered around review meetings ("our security team will provide documentation and examples to the engineering teams on effective threat modeling. We typically ask each engineering team to generate a model in advance, covering a significant part of a system to review"). Note that the product team is generating documentation and bringing it for review. That often leads to threat modeling happening at the end, after decisions have been made. (More on reviews in threat modeling.) Later in the post, they do talk about shifting left, so I think they may have avoided this trap.
Second, they state "Every threat modeling conversation should have at least the following goals." One of the three is "holistically evaluate the entire surface area and develop the most likely points of compromise." This is at odds with a lot of agile practices, such as "threat model every story."
Third, in 'bringing it together,' they have 5 steps in "a quick summary of our process." Three of those steps relate to meeting hygiene and effective project management. I have no doubt that 'following up' and 'leaving with specific action items' are important. Similarly, we could have 'don't call the other team idiots' on that list. It's excellent advice, often violated by security teams who are getting started threat modeling. (This, by the way, is why I wrote my Jenga white paper, talking about how we have technical skills, soft skills and organizational disciplines.)
And that brings me to what threat modeling specific steps are they following? I would love to hear more about the documentation and examples they provide. They mention using the MS TMT or OWASP Threat Dragon, and then have an hour-long conversation about STRIDE threats to it. Are development teams expected to provide just a system model or do they also do a preliminary analysis?
All of this said, they're getting value from the process, and they're clearly thinking about 'what goes wrong' as they threat model, which is crucial. Each organization that succeeds with threat modeling has some commonalities, and a lot of adaption to how they deliver products.
I'm glad to see Github sharing how they're threat modeling, and I hope that they, and you, find this constructive and helpful in understanding where they are.