Threat Modeling with Questionnaires
This post comes from a conversation I had on Linkedin with Clint Gibler.
This post comes from a conversation I had on Linkedin with Clint Gibler. He wrote:
One challenge I've heard from a number of companies is that, with say 3-5 AppSec engineers supporting 500 - 1000 devs, you can't TM every story, or even every epic. So what do you focus on?
The high risk / most critical things. But what are those? It's not always easy to have visibility or even awareness of everything being built in fast moving, complex, large environments.
One method discussed in a few talks (and I reference in mine) is having devs fill out self-service security questionnaires that provide some detail about the purpose of the service / new feature, what sensitive data it touches, potentially dangerous functionality it might have, etc. so that security engineers can do a meaningful TM of those high risk apps.
As always, I'm picking this up to learn, not to criticize Clint for what he wrote. It is worthwhile to start by illuminating Clint's mental model of technical threat modeling work, where he implicitly characterize threat modeling as a heavyweight consulting engagement by appsec engineers. In that model, there are probably deliverables like a DFD and a list of threats. And while that's one fine model, there are other models, such as every engineer threat models, and the approach is lightweight. (I say technical work because there's also the interpersonal and inter-organizational work, and I'm not focused on those in this post.)
Let's think about what's really meant by "devs fill out self-service security questionnaires..." They're answering questions about the first two questions in threat modeling: "what are we working on," and "what can go wrong?" If the answers reach a threshold, then they consider what they're going to do about it.
And so, they're threat modeling using a questionnaire. In fact, every engineer (or scrum master) is threat modeling every feature. They're just using different tools than were in that initial mental model.
And so the question we can ask is not "what do you threat model", but "how can we best use the time available?" and even add, "...when many threat modeling activities turn out to provide assurance but not discovery of interesting threats?" Before I get there, I want to briefly explain that I'm avoiding the phrase "the highest ROI approach," because higher ROI activities might involve a high minimum investment, and in this scenario, avoiding that is the price of the seat at the table.
So with that, I'm modeling all questionnaires as the same, but that's obviously wrong. It's more useful to characterize the questionnaires. How long do they take? Are they a quick check in, or a tedious waste? How often does each element trigger? What's the result of those triggers? Are the triggers avoidable with other mechanisms? For example, can you do static analysis grep checkins to find obviously risky variables like SSN, CCN or COVID? Can we do a risk bounty, where the person who points out the highest risk code in a unit gets a thing? Can we make what I'll call "Big Wall Map" threat models part of scrum planning?
By "Big Wall Map" I mean a way of addressing what we're working on. There's a large map of the code on the wall, and scrum feature discussion starts with showing where the changes will take place. Alice might say "My code will change the way we calculate the ads, but still sending the ad request to this module, so there's no new data flow, and no new type of data crossing the trust boundary." And she's done. Billie might have a different change that adds a new data flow, and so she'll know (or be told) that she needs to do deeper analysis of what can go wrong. This is somewhat similar to a questionnaire, but the compliance check is done by the team and the scrum master. The analysis is dependent on the team. There's less effort, less output, less evidence. But to the question: "how can we best use the time available?"
Big Wall Map is exceptionally fast in steady state. When you start with Big Wall Map, making of the map is technical debt. Maintaining the map can be expensive. But it has payoff in reducing rework that's bigger than security. The physical nature of the map is also important in the same way that physical kanban boards are important. They're visible when people are doing their day jobs, and there's only so much "good wall space." What it's spent on is important. And yes, many people are working from home right now, which makes that less visible.
Back to the goal, what is the goal of the questionnaire? Is it to ensure that nothing slips through the cracks? That there's enough security analysis of each story? That there's a record of the analysis so there's someone to blame? Is it to allocate work by security engineers? Engineering is all about tradeoffs. Crisply defining what we want will help us get there.
Agile folks I work with love to say "if it hurts, do it more." That's a great approach for threat modeling, and it's worth talking through how we can re-factor threat modeling to integrate better. I see a lot of success with developers owning security, Big Wall Maps, and threat modeling every feature in super-lightweight ways. But it takes each company time and work to get to that point. It has to be a cultural journey as well as a technical one.