In the information security world nothing is more fun than using confusing terms. This isn’t done intentionally of course, but it happens. It happens often, I might add. In fact, one set of ideas that is constantly subject to debate is the notion of risk and threats. This isn’t because people enjoy arguing, but it is due to the context from which various people are approaching the subject. Who would have though that information security could be so post-modern? The variety of experiences lead many to define terms quite differently. I try to approach these individual elements not as linguistic islands, but as part of a system that must be coherent. If it does not pass this test, then I’ve gone wrong somewhere. So, I will now present my version. Keep in mind this is probably too specific for physical/environmental risks. It can still be mapped to these definitions, but there will be duplication. You’ll see what I’m talking about. I will try to avoid formalized dictionary definitions. Hopefully that will help.

Risk: This is an abstract concept or placeholder for some loss, damage or event that would adversely affect information.

Threat: This is where the wheels usually fall off so let’s see how we do. A threat is a concrete instance of a risk. For those OO programmers out there, think of this as an instance of the Risk class with the relevant instance variables that uniquely identify it. This is different than those with a military background where a threat is more like an entity, actor or agent that bears some responsibility for an event. I’ll talk more about this in a minute.

Vulnerability: This is a weakness that allows a threat to be realized. This weakness could be missing controls, implementation errors or a variety of conditions that make a threat move from possible, but not realizable to possible AND realizable however difficult it may in fact be.

Attack: This is the mechanism by which a vulnerability is exploited or used. There is usually some activity that must be performed to do something with a vulnerability. A vulnerability must be exploited by an attack. Without the attack component a vulnerability just remains a weakness of some sort. No event (see risk) has occurred until an attack is launched against vulnerability.

Threat Agent: This is the entity that is ultimately responsible in any measure for the realization of a threat. I would say particular threat, but threats are already particular, but I digress.

Now, these are working definitions, but let’s see how they all fit together:

A threat agent uses an attack to exploit a vulnerability in order to realize a threat.

This seems to work. But where does risk fit into all of this? Our above definition does not cohere with the rest of the system. I think we need to revise this a bit. Risk in this situation is particular and not abstract. It is concerned with communicating the impact and possibility of the above systematic statement mapped to a specific instance (I know it sounds funny to me too). Risk then must be anchored in some way to a particular. In order to communicate impact and likelihood you must be acquainted with the threat agents, attacks, vulnerabilities and threats. If you skimp on any of these you have not accurately measured risk. So, a risk assessment is concerned with understanding these particular threats and how they can be realized. I think this works.

In a bit I will break it out even more and show how the various components can be manipulated, measured and rated (and the challenges with each). Again, once we do this, we have to see if the system is still coherent when taken together to ensure we’re getting everything right.

UPDATE: In my haste I seem to have forgotten the most important element of all. I completely omitted assets. Assets are the objects that are threatened. Without them, all the other concepts seem to float around. An asset-centric approach is necessary to give realism to the risk analysis process. This keeps one from dreaming up threats and/or vulnerabilities that cannot be tied back to an asset.