A threat is not a hazard
Basic Terms, part 1: threat, vulnerability, hazard and risk build on one another in IT-Grundschutz and mean four different things. Plus the term the BSI abolished in 2017 that almost everyone still uses.
First in the series Basic Terms. We take words that get used interchangeably in meetings although they mean different things, and check what the sources actually say.
Threat, hazard, risk. All three come up in every security meeting, mostly as synonyms. In German IT-Grundschutz they denote three different things that build on one another, and the distinction decides what ends up in your risk register.
Threat: the circumstance that does not ask
A threat is a circumstance or event that can compromise confidentiality, integrity or availability. Fire. Theft. Malware. A threat exists regardless of whether it affects us. It is a statement about the world, not about us.
That is why a list of threats is worthless as a risk register. It looks the same at every organisation.
Vulnerability: the place where it reaches us
The vulnerability is the counterpart on our side. A technical or organisational weakness that can allow a threat to take effect in the first place. On its own it says little either: an unpatched system with no reachable attack surface is a defect, but not yet a case for risk analysis.
Hazard: only where the two meet
IT-Grundschutz speaks of a hazard (Gefährdung) where a threat meets a matching vulnerability and thereby acts on a specific target object. That is the point where a general statement about the world becomes a statement about your own organisation.
The IT-Grundschutz Compendium maintains a fixed catalogue for this: 47 elementary hazards, numbered G 0.1 Fire through G 0.47. They are deliberately worded in a "product-neutral and largely technology-neutral" way so they hold up across years and technology changes. A risk analysis under BSI Standard 200-3 works through this catalogue per target object and keeps only the hazards with direct relevance.
Risk: only with frequency and damage
Even a hazard is not yet a risk. BSI Standard 200-3 puts it this way: the assessment is made "via the expected frequency of occurrence and the level of damage arising when the damaging event occurs. The risk follows from these two components."
Only here do numbers enter, and only here does prioritisation become possible.
The term almost everyone still gets wrong
In the October 2017 edition the BSI explicitly replaced two terms. From the standard's change history: the terms "probability of occurrence" and "courses of action" were replaced by "frequency of occurrence" and "options for action" respectively. In the entire current standard the word probability of occurrence appears only at that one spot, the one documenting its removal.
This is not cosmetic. A probability presupposes a distribution you almost never have in information security. A frequency, by contrast, can be estimated and tied to experience: once a year, every five years, several times a month. Anyone still speaking of probability promises a precision they cannot deliver.
And another pair that tends to merge
The same edition split the risk rating chapter into two steps: risk estimation and risk evaluation. Estimating means determining frequency and level of damage. Evaluating means holding the result against your own criteria and deciding whether it is acceptable.
Anyone working internationally should be careful here, because the translation misleads. The annex of 200-3 maps the terms: Risk Analysis under ISO/IEC 31000 corresponds to Risikoeinschätzung (risk estimation), Risk Evaluation to Risikobewertung. The German "Risikoanalyse", by contrast, is the overarching procedure. Translate it as risk analysis and you mean something different from the person across the table.
What this changes in practice
A risk register listing "malware" and "fire" lists threats. It is interchangeable and carries no decision. A register recording, per target object, which hazard causes what damage at what estimated frequency is a statement about your own organisation. Only the second can be treated, and only the second holds up in an audit.
Next in the series: protection requirements and criticality, two words for supposedly the same thing that come from different procedures.
Sources: BSI Standard 200-3 and the IT-Grundschutz Compendium. How a risk register reflects this separation is on the risk register module page.
Questions about this update?
Talk to us – we are happy to show you this feature in a demo.