I’m a huge fun of threat modeling. It’s a very powerful tool, that can find a lot of security issues. If you’re not familiar with it, check out my earlier post on the subject. For the past few years, I was struggling with one simple question: when should we conduct threat modeling? After all, threat modeling has a price – it takes time to conduct it, and usually involve a few peoples. We can’t conduct a full threat model for every feature – we need to find a way to identify the “interesting” features that require a threat model.
One very interesting solution to this hard problem was proposed by Izar Tarandach in this talk. In short, he proposes to tag features as “threat model worthy”, and once in a while go over all the features with this tag and review them. This is a really interesting approach, and I highly recommend you to watch the entire talk. However, from my experience, it’s not a silver bullet for this problem, and I want to propose an alternative approach.
We almost always build the same thing. Usually, some kind of REST API that do CRUD operations over a database. So, even if the feature we’re working on is very sensitive (collect credit card information, for example) the software we’re actually building could be the same as the other 200 services we already have. If it’s exactly the same, do we still need to conduct a threat model? Maybe there is a better way.
Scaling Threat Model
Let’s take the common pattern we have, conduct a threat model for it, and document it (maybe using source control). Then, we can create templates, libraries, and boilerplates for the developers to use – based on the threat and mitigations we discussed.
Instead of saying “a database should not be accessible from the internet”, we can create a template with Pulumi or Terraform for databases. Each time a developer needs a database, she can use it to create a database – and she’ll get the most secure database we can. We can even write unit tests for our infrastructure. Let’s unleash the power of infrastructure as code and use it to scale threat modeling.
Instead of implementing authentication and authorization logic in each service we write, we can write generic policies using tools like Open Policy Agent. All the services can use the same policies without the need to re-implement them each time. Authentication can be solved using proxies like Envoy or Airbag. No need to review the same implementation over and over again.
Now, instead of asking “do we need to conduct a threat model” we need to ask “what are we building”. Do you use common templates and libraries? You’re probably safe. Do you use new technology? A new kind of database? A new protocol? Adding a new authorization policy? Let’s talk. It’s probably better to conduct threat modeling and update our templates. Scaling threat model was never easier.
What do you think? Is that something that can work for you? Or maybe there is something I missed? I’m looking forward to hearing you’re thoughts about it!