Assessing security risks: selecting the right tool for the job

The security risk assessment, or security vulnerability assessment, can be a useful tool, but its misapplication is also one of the bigger long-term problems I’ve observed in security management. The reason for this is that many security practitioners don’t understand what methodology to use in different circumstances. 

Another related problem is that an SRA is a fairly complex undertaking if it’s done properly. But too often it’s used when a more compliance-oriented process like an audit would be more suitable, with the end result being that the SRA is treated as a box ticking exercise.

These two problems combined have led to some of the thorniest problems I’ve encountered in security risk management. 

SRA processes like ANSI 780 were originally intended for use in the design phase of large infrastructure projects in the USA. The basic idea was that the process would use detailed information about threats to build attack scenarios, then apply pathway analysis to identify vulnerabilities for each scenario. Mitigation options would then be developed to reduce the indicated risk to an ‘acceptable’ level. I’m aware there’s a lot more to it than this, but that’s the basic idea.

One key point at this stage is that the mitigation options generated by the SRA form the ‘minimum standards’ that must be complied with in future audits. If the minimum standards are coming from somewhere else, then what is the link between threats and mitigation? That’s a separate but important question that I’ll set aside for now.

Let’s take a step back. If we’re not designing critical infrastructure in the USA, when should we use an SRA? Thinking about the question in terms of the RIBA design stages is a good way to understand this. RIBA Stage 2 is the concept design stage, which is arguably where the answers generated by an SRA are going to be most useful. There’s even an argument for doing some SRA work in RIBA stage 1 in support of feasibility studies. But…

I’ve lost count of the number of times I’ve been asked to help unravel problems that occurred because Security wasn’t included in a meaningful way in the concept design stage of a development project. Or, alternatively, Security considerations were treated somewhat separately to other concerns. In an international arbitration I advised on a few years ago, the ‘SRA’ focused on hotel security but made no mention of the proposed export pipeline that was to run through 700 km of insurgent dominated terrain. A thoroughgoing SRA might have raised some questions about viability.

The second reason for doing an SRA would be when the threat environment changes significantly. Novel threats tend to expose latent vulnerabilities, hence why SRAs are sometimes called SVAs. In these circumstances a risk assessment process needs to generate new information about the threats and the new mitigation required to match them, and a compliance process isn’t designed to do this.

In most other routine circumstances, an audit or a gap analysis is fine. But let’s revisit the question I raised earlier about where the minimum standards are coming from. A few years ago I reviewed an incident for a fine art gallery in England. To summarise the incident, local scrotes broke into the gallery with a diamond cutter chainsaw and stole a priceless tiara, all within about 180 seconds (none-British readers can consult urbandictionary.com for a definition of ‘scrote’). The gallery’s security measures were ‘compliant’ with the standards advised by an oversight body, but the problem was that the standards hadn’t been tested for specific scenarios using an SRA methodology. In this case, the ‘compliant’ standard was three or four levels below the resilience needed to defeat scenarios that were already prevalent in England, using techniques available to low-level criminals.

So, different organisations have different vulnerabilities and different corporate security governance obligations, and this will tend to influence what risk assessment process is preferred. But the problem here is that a process that is quick and efficient might be preferred because it lightens the load on managers who are struggling with capacity in the face of heavy workloads, not because it provides the best answers about risk and vulnerability in the face of uncertainty. An SRA is always going to be the start point in setting minimum standards in a complex and high-energy risk environment with a high level of uncertainty, or when an operation has unique vulnerabilities to security threats. On the other hand, in a stable environment where the threats are routine and there is a lot of certainty, a compliance-oriented approach might be acceptable. In my own experience, the best systems are flexible and use both processes at different points in a project’s lifecycle.

Back to Insights

Share this insight