Thursday 23 February 2023

Unnecessary control example

A couple of days back, I said I'd offer an example of an 'unnecessary control' in the context of ISO/IEC 27001. So here goes.

Picking one at random, I'll lay into ISO/IEC 27001:2022 control A.5.28 "Collection of evidence". 

The control text reads "The organization shall establish and implement procedures for the identification, collection, acquisition and preservation of evidence related to information security events".

How can anyone possibly justify excluding such an eminently sensible control from their ISO27001 Information Security Management System?

Reading and interpreting that control literally, word-by-word, one could certainly argue that:

  • The control text goes well beyond collecting evidence. The control title is therefore misleading. 
  • "Establish" is a distinctly ambiguous word. Does it mean document, prepare, commission, name/identify or something else? 
  • Likewise for "implement". Does simply publishing a procedure in a shared area qualify as 'implementation'? If not, what else is involved?
  • "Procedures" typically support and elaborate on/explain policies in pragmatic terms ... but policies are not even mentioned, nor are other supporting materials such as guidelines and training courses which are important in the case of forensic evidence. 
  • "Procedures" is plural: why shouldn't we develop a single procedure covering all the areas stated?
  • Just how much detail is needed in the procedure/s? Would the single sentence "Evidence related to information security incidents is to be identified, collected, acquired and preserved" suffice? Seems unlikely!
  • "Identification, collection, acquisition and preservation" is poorly phrased (collection and acquisition are synonymous) and incomplete (what about analysis? Protection/security?).
  • "Evidence related to information security events" is vague and incomplete. For one thing, 'events' are generally less significant than 'incidents', hence the need to collect evidence is stronger for incidents. For another, collecting evidence involves determining which evidence is or is not relevant and valuable. Again the control text is misleading.
  • Who should be collecting evidence? When? How? And why? ISO/IEC 27001 makes no attempt to explain the rationale for this control, more specifically explaining the information risk/s that it mitigates or the consequences of not instituting such a control.

In summary, control A.5.28 - as worded in the standard - is incomplete, inadequate and misleading.

But wait, there's more. An organisation that employs forensic specialists for this kind of thing need not 'establish and document procedures' since the specialists will presumably have done so, and in a lot more detail than the control text suggests. Selecting and contracting with said specialists, commissioning investigations and overseeing their activities, as well as acting on their findings, are important aspects that, once again, are not even mentioned by the control as stated.

Management may legitimately prefer not to proceduralise these activities in order to remain flexible, relying on its competent, well-trained and experienced workers to do whatever is actually needed under the specific circumstances of an incident, with strong leadership and direction from management. If events and incidents are rare and mostly minor (thanks to effective preventive and detective controls), the suggested control may not be cost-effective. 

Incidents such as fraud and impropriety involving insiders are generally investigated discreetly so as not to alert the alleged perpetrators: discretion can be an important factor, along with professional competence, diligence and personal integrity of the investigator/s. This is all missing from the control text.

Yet another aspect is the business context and the organisation's other priorities. A small greenfield startup seems unlikely to be particularly concerned about "information security events", preferring to concentrate on various other activities - not least, getting the business up and running first. A mature bank, on the other hand, could hardly just accept the risk, nor could a company that had just suffered a serious incident, revealing a big hole in its incident management policies and procedures - and yet, preventing incidents is still likely to be an even higher priority. Control A.5.28 may not be "necessary" right here, right now.

Finally, the ISMS scope need not necessarily include incident management, for instance if the organisation has a separate Internal Audit function, Security Operations Centre, Forensics Team, Investigations Unit or whatever that would handle events and incidents, outside of the ISMS - perhaps even a completely different business unit (such as HQ or Group). The ISMS would probably need an effective working relationship with them, complete with various administrative controls, but control A.5.28 may be irrelevant and inappropriate.       

OK, that's more than enough cynical critique from me!  I hope you get the point.

Using arguments along those lines, management could readily justify determining that A.5.28 is "unnecessary", whether in order to replace it with a similar but better worded information security control (such as the expanded and better described control 5.28 in ISO/IEC 27002:2022, or a variant control worded to suit the organisation's particular circumstances and needs), or to drop the control completely and simply accept the [unstated] information risks.

No comments:

Post a Comment

The floor is yours ...