Threat and Risk Modelling - from elementary modelling to sophisticated mathematical analysis.
For many years, some of the most notable names in the Information Security space have maintained that Information Security is far too complex a subject to be amenable to proper modelling. I fundamentally disagree with them. I do not claim risk modelling is always easy, but I do believe there is enormous value to be gained from the pragmatic modelling of threats and security risk.
I think part of the issue revolves around what people mean when they say 'proper modelling'. I take it to mean modelling threats and risks based on a proper and deep understanding of the dynamics involved. There are a number of technology companies that have developed large software systems that claim to model risk. Many of these fall under the heading 'GRC' or 'Governance, Risk and Compliance'. I have assessed a number of GRC systems for several of my clients and found them wanting. They can be quite sohisticated pieces of software but they don't model risk. Typically they assign values to one or other component of risk and then aggregate these values over 'attack trees' or similar structures, ending up with results that they display in a Dashboard format.
There is value in these GRC products and they can serve a useful purpose. It is just that they do not model risk 'based on a proper and deep understanding of the dynamics involved'. So what do I do that is different? At my core, I am a theoretical physicist. My Ph.D. was based on modelling a particular high-energy physical system. To do that, I had to understand the dynamics behind that physical system and then how to analyse and model those dynamics. In the process, I had to learn how to start with a high-level model and then build progresively deeper and more sophisticated models, each providing the next level of insight into the problem I was trying to solve. I also had to learn how to interpret the results at each level correctly so I didn't claim there was more meaning in the results than the model could justify.
Though I couldn't have known it at the time, that training has served me well in my second career, Information Security.
♦ My scientific training gave me the analytical skills to see beneath the surface and understand the dynamics of risk, i.e. to understand the way that threats engage with a system under attack, and with its vulnerabilities and countermeasures, to create risk. Then to see how different countermeasures intercede in different places within that dynamic, each in its own way contributing to the reduction of risk.
♦ My research training gave me the skills to formulate models that, to varying degrees of approximation, model that dynamic and produce results that are meaningful. These results can be used to inform risk management decisions, allowing security professionals and the Executives they serve to make more-informed decisions about the risks they face and the measures they can take to reduce those risks.
There is an enormous amount of work that can be done in this area, and most of the modelling work I have done for clients to date lies towards the 'elementary' end of the modelling spectrum. But again, I must stress, there is a lot of value to be gained by modelling at this level. For most of the modelling I do, I use nothing more sophisticated than spreadsheets (admittedly, they can be quite large spreadsheets!). At this level, modelling doesn't need Monte Carlo algorithms or simulators or sophisticated statistical tools. It does, however, need data, and in every case, my modelling work leads to my client getting a better understanding of the data they need to collect if they are to manage risk better.
For those who want a little more detail, let me explain.
There is lots more I could say about each type of modelling, especially about the more sophisticated levels of analysis. Please contact me using the details below if you would like to discuss these things in more detail.
The idea behind threat modelling is to build a transparent method for assessing the potential for causing harm that a range of threats can have, and identifying which are the largest or key threats. By transparent, I mean a method where the assumptions going into the model are explicit, and any changes made to those assumptions are immediately and visibly reflected in corresponding changes in the results.
When talking about threats, I am talking about threats at a high level, the types of threat Executives understand and that cause the types of harm Executives worry about. I am talking about archetypal threat actors (e.g. privileged staff, hackers, foreign government agencies) and broad classes of attacks (e.g. abuse of user privileges, network intrusion attacks, exploiting concealed back doors). I do not work at the level of specific computer security attacks (such as those described in Microsoft's STRIDE) and specific software vulnerabilities (such as those listed in Mitre's CVE dictionary). I am also dealing with the result of threats being harm done to an organisation's mission and operations, not corruption of a specific software function. This is not to say that technical threats and software attacks are not important, just that they operate at too low a level to keep most Executives awake at night.
There are a small number of threat taxonomies that operate at this higher level. There is one used by HMG (described in IS1), an equivalent used by civil government in the USA (described in various NIST documents), one developed by Intel and one developed by Verizon. The Verizon scheme is the one they use for their annual data breach reports and it has been developed specifically for that purpose. But the other three can, to one degree or another, be used as the foundation for building threat models. As the two clients I have built threat models for recently have both been UK companies, I have started in each case from the HMG threat taxonomy.
In each case, I have built a threat model that covers all the threats the client considers relevant, and all the types of harm their Executives worry about. The model works through the dynamics logically and ends up assigning a relative score to the potential of each threat to cause each type of significant harm. Those threats that come out with the highest scores are the key threats that that client needs to worry about the most. Those key threats then get carried through to the Risk Model.
The idea behind risk modelling is to build a similarly transparent model for showing the level of risk the client faces from each of those key threats. By understanding how threats gain traction, and how countermeasures intercede in that dynamic, I build a model that shows the level of risk the client faces as a function of the degree to which the client has implemented relevant countermeasures. If the risks the client wants to model are IT Security risks, then the countermeasures will be technical security countermeasures implemented in their IT applications and infrastructure. If the risks the client is interested in are business process risks, the countermeasures will be physical and procedural controls implemented in their premises and operational systems.
The client can then either build a compliance assessment programme to gather data describing their implementation of countermeasures, or can input data from their existing compliance assessment programme. The model shows them how large their main security risks are and where they are coming from. The client can then use the model for "What-if" analyses, working out how much risk reduction they would achieve from each security action plan they might devise. They can choose the plan that gives them the best risk reduction return for the effort and expenditure involved. This takes a lot of the guesswork out of risk mitigation and leads to better-informed and more cost-efficient risk management decisions.
Importantly, and perhaps most importantly for the people I work with, this also allows my client's Information Security function to demonstrate to the business management they work with the value they provide for the investment the business makes.