Threat Modeling and Operations
One very important question that’s frequently asked is “what about threat modeling for operations?” I wanted to ensure that Threat Modeling: Designing for Security focused on both development and operations. To do that, I got help from Russ McRee. For those who don’t know Russ, he’s a SANS incident handler as well as a collegue at Microsoft, where he beat me about the head and shoulders made the case for the importance of threat modeling for operations. Those conversations led to me helping out on the “IT Infrastructure Threat Modeling Guide.”
Russ had an official role as “Technical Proofreader,” but that understates what he did. What he did was make sure that infrastructure and operations got a full and fair treatment, and the book is better for his help.
There’s an important interplay between threat modeling for developers and threat modeling for operations. The threats are the same, but the mitigations are functionally different. There are mitigations which are easy for developers which are hard or impossible for the operations, and vice versa. The simplest example is logging. It’s really hard to add logging without changing the source. But reading the logs? There’s no way for a developer to ensure that that happens. Someone in operations has to decide what logs are important and relevant. Good threat modeling can elicit the threats, and lead to the early creation of a security operations guide, making explicit who needs to do what.
(I don’t mean to ignore the rise of devops, but even in that world, it can help to think of different types of mitigations.)