Franklin Heath Ltd

Recently we’ve taken on a client with immense experience of IT product development but not so much experience with computer security.  A report I am writing for them starts by defining terms, to avoid possible confusion; I thought I’d also write this article to discuss more generally why “threats”, “risks” and “vulnerabilities” deserve specific definitions in that context.

The English dictionary definitions don’t help much, as the words represent abstract concepts and have multiple possible meanings depending on context.  Even computer security sources don’t agree on a single meaning and can be infuriatingly vague (ISO 27000 includes the spectacularly unhelpful “risk: effect of uncertainty on objectives” 😯), so I’m just going to explain the usage that works for me in the context of a product development life cycle.

One of the dictionary definitions of threat is “A person or thing likely to cause damage or danger” (this is often more specifically referred to in computer security circles as a “threat actor”).  For our purposes, we need to define a broad concept of threat which includes why they would be aware of, or interested in, our product and what their capabilities are.  This is similar to the concept of threats in business Risk Management, that is, external factors that you cannot control.  In the product development context, threats should be the principal factor which determine the product requirements relating to security (there may also be market requirements arising from customer perceptions and expectations).

A typical definition of risk in business Risk Management (and the CISSP syllabus) is

risk   =   likelihood of adverse event   x   cost of adverse event

Aside from the effective impossibility of measuring either of those factors in advance, it’s not really useful in a product development context, as you don’t usually know the environment in which your customers will be deploying your product, or have much of an idea of the value of any assets they will protect with it.  What I find much more useful is what Cigital are referring to in their term Architecture Risk Analysis although, confusingly, Microsoft generally call this same concept a threat, as in their SDL Threat Modelling Tool.  Microsoft’s STRIDE categories are useful, so we will define risks to be all the potential attacks on the security of our product which could result in spoofing, tampering, repudiation of action, information disclosure, denial of service or elevation of privilege.

Finally, vulnerabilities.  Some people assume that this is what computer security is all about (usually in articles referring to “cybersecurity” 😦) as finding vulnerabilities is the easiest way for a security researcher to get a journalist excited.  Penetration testers, software developers and organisations such as PCI focus on lists of vulnerabilities such as the OWASP Top Ten, as a way to quantify the security of an implementation, but that misses the point that the best way to ensure security is to design your product properly in the first place! (and why are developers still using SQL, a 40-year-old, seriously flawed, database query language in this day and age? but that’s an article for another day…)  For our purposes, we define vulnerabilities as design or implementation flaws which allow security mechanisms to be defeated or bypassed.

Combining the terms with these definitions, a threat actualizes a risk by means of a vulnerability so, for example, large foreign corporations wanting to steal trade secrets (the threat) might be able to extract database records (the risk of information disclosure) using SQL injection (the vulnerability).

Relating these definitions back to the product development life cycle, it should become clear that each of these three concepts are of most interest at different stages:

 
Some of the above may be debatable, particularly the definition of “Risks” as it varies from a CISO or Enterprise Architect’s typical use of the word (they might consider size of exposure to financial losses to be an essential part of it) but I hope this is useful in presenting things specifically from a product perspective. If I could think of a better word than “Risks” for that concept, I would happily use it; do please let us know in the comments if you have any ideas!