ISO/IEC 27001 concerns at least* two distinct classes of risk - ISMS risks and information risks** - causing confusion. With hindsight, the ISO/IEC JTC1 mandate to require a main-body section ambiguously titled "Risks and opportunities" in all the certifiable management system standards was partly to blame for the confusion, although the underlying issue pre-dates that decision: you could say the decision forced the U-boat to the surface.
That is certainly not the only issue with '27001. Confusion around the committee's and the
standard's true intent with respect to Annex A remains to this day: some committee
members, users and auditors believe Annex A is a definitive if minimalist list
of infosec controls, hence the requirement to justify Annex A exclusions ... rather than justify Annex
A inclusions. It is strongly implied that Annex A is the
default set. In the absence of documented
and reasonable statements to the contrary, the Annex A controls are presumed appropriate and necessary ...
but the standard’s wording is quite ambiguous, both in the main body clauses
and in Annex A itself.
In ISO-speak, the use of ‘shall’ in "Normative" Annex
A indicates mandatory requirements; also, main body clause 6.1.3(c) refers to “necessary
controls” in Annex A – is that ‘necessary for the organization to mitigate its information
risks’ or ‘necessary for compliance with this standard and hence certification’?
Another issue with '27001 concerns policies: policies are
mandated in the main body and recommended
in Annex A. I believe the main body is
referring to policies concerning the ISMS itself (e.g. a high-level policy - or perhaps a strategy - stating
that the organization needs an ISMS for business reasons) whereas Annex A concerns
lower-level information security-related policies … but again the wording is somewhat
ambiguous, hence interpretations vary (and yes, mine may well be wrong!). There are other issues and ambiguities within
ISO27k, and more broadly within the field of information risk and security management.
Way down in the weeds of Annex A, “asset register” is an ambiguous
term comprised of two ambiguous words. Having
tied itself in knots over the meaning of “information asset” for some years, the
committee eventually reached a truce by replacing the definition of “information
asset” with a curious and unhelpful definition of “asset”: the dictionary does
a far better job of it! In this context, "register" is generally understood to mean some sort of list or database ... but what are the fields and how much granularity is appropriate? Annex A doesn't specify.
But wait, there’s more! The issues extend beyond '27001. The '27006 and '27007 standards are (I think!) intended to distinguish formal compliance
audits for certification purposes from audits and reviews of the organization’s
information security arrangements for information risk management purposes. Aside from the same issue about the mandatory/optional
status of Annex A, there are further ambiguities tucked away in the wording of
those standards, not helped by some committee members’ use of the term “technical”
to refer to information security controls, leading some top open the massive
can-o-worms labelled “cyber”!
Having said all that, we are where we are. The ISO27k standards are published, warts and all. The committee is doing its best both to address
such ambiguities and to maintain the standards as up-to-date as possible, given
the practical constraints of reaching consensus among a fairly diverse global membership
using ISO’s regimented and formal processes, and the ongoing evolution of this
field. Those ambiguities can be treated
as opportunities for both users and auditors to make the best of the standards in
various contexts, and in my experience rational negotiation (a ‘full and frank
discussion’) will normally resolve any differences of opinion between them. I’d like to think everyone is ultimately aligned on
reaching the best possible outcome for the organization, meaning an ISMS that
fulfills various business objectives relating to the systematic management of
information risks.
* I say ‘at least’ because
a typical ISMS touches on other classes of risk too (e.g. compliance risks,
business continuity risks, project/programme management risks, privacy risks,
health and safety risks, plus general commercial/business risks), depending on
how precisely it is scoped and how those risk classes are defined/understood.
** I’ve been bleating on for
years about replacing the term “information security risk”, as currently used but
not defined as such in the ISO27k standards, with the simpler and more accurate “information risk”. To me, that would be a small but significant
change of emphasis, reminding all concerned that what we are trying to protect - the asset - is, of course, information. I’m
delighted to see more people using “information risk”. One day, maybe we’ll convince SC27 to go the
same way!
No comments:
Post a Comment