Lack of control is not a vulnerability [LONG]

Another of those apparently simple but profound questions came up on ISO27k Forum this morning. Juan from Peru said:

"Well, I am pretty confused about how to correctly describe a vulnerability. I´ve seen many sheets/registers (even a topic in this group) where a vulnerability is described as a "LACK OF A CONTROL" For example if I say that a VIRUS is a threat agent, my vulnerability would be a "LACK OF A VACCINE FOR THAT SPECIFIC VIRUS", this is quite redundant, I think but in a certain way, has sense. Now, I´ve also read that a Vulnerability CAN NOT be described as "LACK OF A CONTROL" because a Vulnerability is AN INHERENT WEAKNESS OF THE ASSET, which I think has more sense than the vaccine´s example. But, there is a problem, I could not find any official literature (I mean and ISO 27k) that supports that definition. I searched in ISO 27000 and 27005, and those Standards just say that a vulnerability is a weakness that can be exploit (Nothing about INHERENT). Also in ISO 27005 I found many examples of vulnerabilities (In the annex, I think) and they are described as "LACK OF CONTROLS". This is really confusing for me."

“Inherent weakness” is my succinct working definition of vulnerability. I use the word “inherent” to refer to issues within or integral to the system of concern (not necessarily an "asset"), in contrast to threats which (again, as I use the term in practice) are outside the system and impinge upon it. Furthermore, by ‘system’ I mean a coherent collection of things acting in concert - not just, say, an IT system (the computer hardware, firmware and software plus the data) but also the associated processes involved in using and administering it, and the users and administrators, the managers overseeing it, its owners/stakeholders … and so forth. I use 'system' in as broad a sense as “information security management system".

So why does my working definition of 'vulnerability' differ from that in ISO/IEC 27000:2018? Why don't I just use the formal definition? Good point ... but my reasoning is complicated to explain. Bear with me.

I'll start with the formalities. Among other terms, ISO/IEC 27000:2018 defines:

• Control as “measure that is modifying risk (3.61)” plus 2 notes: "controls include any process (3.54), policy (3.53), device, practice, or other actions which modify risk (3.61)" [and] "it is possible that controls not always exert the intended or assumed modifying effect." [sic*]
  
  
• Vulnerability as “weakness of an asset or control (3.14) that can be exploited by one or more threats (3.74)”. That definition is a little ambiguous* but I understand it to mean that a weakness of a control would constitute a vulnerability if it might be exploited;
  
  
• Threat as "potential cause of an unwanted incident, which can result in harm to a system or organization (3.50)"; and
  
  
• Risk as "effect of uncertainty on objectives (3.49)" plus 6 notes: "an effect is a deviation from the expected — positive or negative; uncertainty is the state, even partial, of deficiency of information related to, understanding or knowledge of, an event, its consequence, or likelihood; risk is often characterized by reference to potential “events” (as defined in ISO Guide 73:2009, 3.5.1.3) and “consequences” (as defined in ISO Guide 73:2009, 3.6.1.3), or a combination of these; risk is often expressed in terms of a combination of the consequences of an event (including changes in circumstances) and the associated “likelihood” (as defined in ISO Guide 73:2009, 3.6.1.1) of occurrence; in the context of information security management systems, information security risks can be expressed as effect of uncertainty on information security objectives; information security risk is associated with the potential that threats will exploit vulnerabilities of an information asset or group of information assets and thereby cause harm to an organization."

Unfortunately, there are numerous issues and ambiguities in those four definitions: 

• Only a few of those words are explicitly defined in the standard - the ones that are used in a particular way within the context of the ISO27k standards ('terms of art' you could say). I believe we are meant to refer to the Oxford Dictionary definitions for the rest although this is not actually stated anywhere in the published standard: it is merely a convention, possibly stemming from ISO's directives to the drafting committees;
  
  
• As formally defined, control distinguishes two concepts: controls ‘modify’ risks and hence (I would argue) are not part of them. You could consider them to be optional extras, add-ons that you may or may not want to use – at least that’s how I think of them although the definition doesn't actually say so;
  
  
• The definition of vulnerability is ambiguously worded in the first clause. Does it mean "weakness of an asset, or weakness of a control" or "a weakness of an asset, or a control,"? I believe it is the former but that's just my interpretation - and ideally there should ideally be no room for interpretation in a formal definition;
  
  
• Threat seems quite straightforwardly defined (aside from referring to "system or organization", implying that they are distinct ... but one could argue that an organization is one type of system, a social system, often with a legal basis; 'system' is undefined). However, as Juan noted, even ISO/IEC 27005 misinterprets the term. A lack of control may modify the risk compared to its presence, but does not actually cause an incident: it is simply an omission. Incidents are caused by circumstances or acts - the commission of something, not omissions;
  
  
• The definition of risk is particularly awkward and unsatisfactory. It is the product of a committee of people holding differing views, hence its extraordinary length. The definition part is so vague as to be almost meaningless, while the notes compound matters by mashing up several separate concepts. What a mess! It might not be so bad if 'risk' were peripheral to ISO27k but in fact quite the opposite. Risk (or rather, as I would prefer to put it, "information risk") is absolutely central. 

I personally do not consider lack of a control to be a vulnerability for several reasons:

1. It makes it easier to consider and evaluate the underlying risks in a situation, deliberately ignoring any current or proposed controls during the analysis. It helps us distinguish risks from controls (as per the definition), and simplifies the risk analysis.
   
   
2. Some existing or proposed controls may be unnecessary and unhelpful (e.g. periodic password changes), but we are less likely to consider that if we always take them for granted and assume they are present and working as intended in our risk analyses. Periodic password changes, for example, are a costly control incorporated into many systems for years without good reason other than habit or convention. In any given system, there may well be other controls that serve little to no purpose, perhaps even some that are counterproductive (they actually weaken rather than strengthen the system, perhaps opening up new avenues for attack or failure: antivirus software and automated software updates are two possible examples of this).
   
   
3. The list of potential controls is unbounded. Aside from the large variety of possible types of controls, each control has many variants, and there is a huge (possibly infinite) variety of possible combinations and sequences of controls. So how are you going to determine which controls to add to, or exclude from, the list of missing/ineffective/inadequate controls? Answering that question presupposes that you understand the risks, in other words it is a circular or self-referential issue. 
   
   
4. It allows/encourages us to figure out which controls we require according to the risks we have identified and evaluated. It also suggests a natural priority or ranking of the controls, since those controls mitigating the most significant risks are clearly important (‘key’) controls. This has substantial implications that are not widely considered, at present e.g. resilience, effectiveness and assurance are likely to be strong requirements for key controls.
   
   
5. Controls are not 100% reliable – in other words, there are risks associated with the controls themselves, as implied by the second note to the '27001 definition of control. This again complicates the risk analysis and (in my experience) is usually ignored … but that’s a mistake, particularly in the case of key controls. The possibility of key controls failing to operate as intended or as required means significant risks might be insufficiently mitigated in practice. Now you might say that this means 'control reliability' therefore ought to be part of the risk analysis, in addition perhaps to 'control suitability', 'control value' and maybe other considerations. Personally, I prefer to address this separately in the risk management process, particularly in the phase following the decisions about how to treat the identified and evaluated risks, plus in the ongoing management, measurement and assurance activities once the controls are in use.

Another way to look at this is that a missing, weak, inadequate, failing or inappropriate control, exposes or fails to compensate for a vulnerability ... but 'exposure and 'compensating control' are ambiguous and confusing concepts too. Maybe I'll come back to that another day.

So, that's it for today. Sorry to be so anal about the words and definitions, but Juan is certainly not the only confused soul - even ISO/IEC JTC 1/SC 27 has trouble with this stuff! 

* The second note is missing a word. It should be "it is possible that controls do not always exert the intended or assumed modifying effect.", I think.