Threat modelling and risk ownership

I’ve spent a fair amount of time over the past year or so looking at threat modelling as it applies to the product space. Threat modelling is a time consuming process but it’s an invaluable tool in helping us to manage risk and understand threats that are relevant to a specific system.

The best resource on offer is that provided by Microsoft here: In particular I recommend the book (“Threat Modeling” by Frank Swiderski and Window Snyder) and the associated free software. I could happily sit here and discuss how to do threat modelling and the value of doing so for hours but you can read about that in detail at the above mentioned resource. Instead I want to draw your attention to a quote that caught my eye when I first opened aforementioned book: “Ownership helps drive security processes so that the quality of applications can be improved.”

This is such an important concept and determining security ownership can be as challenging as addressing the risks. In my view, ownership means having some-one within the organisation who can take responsibility for a specific level of risk. For example, if I identify something risky then my role is to document that risk, identify the potential importance of it, and determine suitable mitigating actions. However, it becomes a business decision whether or not to take the action or to accept the level of risk. The information security group cannot – and should not – be taking ownership of the risk. That is a business decision. So, while we can provide guidance and ensure that risks are managed the constraints of the business must come first. If I’m doing my job correctly then I leave the relevant managers in no doubt as to what risks I think need to be addressed, the potential cost of doing nothing, and the time and cost for taking the various mitigating actions. It’s then their risk to own.

Clearly, if I believe an unacceptably high level of risk is being left unaddressed then I can try stamping my feet a bit harder.

So, where does threat modelling come in? Well, it’s another tool for “assessing and documenting security risks”, more critcally it helps generate an understanding of how a system might be attacked by taking into account the adversary’s goals, and therefore it becomes relatively easy to identify an applications weak spots. You can use the knowledge gained to feed into the scenario’s you’d want to describe when performing the final risk assessment (see previous blog entries here and here).

Here’s a couple of additional good resources: