Losing faith in ISO27k

ISO/IEC 27002 - a generic catalogue of commonplace information security controls - expands substantially on Annex A of ISO/IEC 27001. Each of the 93 single-sentence control statements in Annex A merits about a page of more detailed explanation and guidance in '27002 ... but those details mean more work for ISO/IEC JTC 1/SC27 to maintain the standard.

The committee is forever chasing after changes in the field such as the meteoric rise of generative AI since the release of ChatGPT at the end of 2022 ... shortly after ISO/IEC 27001:2022 and ISO/IEC 27002:2022 were published.

ISO/IEC's thorough and laborious processes for developing and maintaining international standards inevitably introduce substantial lag into the process, and here we are some 3½ years later, s l o w l y powering-up the committee's creaky machinery once again to review, reconsider and update '27002.

On past experience, SC27 will take years to update 27002 - at least a couple and perhaps as many as 5 years depending on the amount of debate, dissention and consensus within the committee. If, this time around, the wording needs to be markedly simplified to adopt ISO's version of plain English, even 5 years won't be enough.

In practice, the technical changes will be pretty much determined within the first year or so of the process, to be followed by further years of seemingly interminable debate, compromise, refinement and rewording, shoe-horning the standard into the ISO DIrectives and addressing concerns raised by national standards bodies around the globe. Following that critical first year, any further technical updates that are suggested after, say, mid-2027 are increasingly likely to be rejected out of hand by the editors as "out of scope", since if they were to be drafted, incorporated and then wordsmithed, the standard would take years longer to update ... during which time the need for yet more technical updates may well arise.

Spot the problem?

Therefore, any changes that occur in the information security field after mid-2027 are unlikely to be reflected in the standard when the next release of '27002 hits the streets in, maybe, 2029/2030. In other words, the shiny new standard will already be two or three years out of date before the ink has even dried.

The current hubbub about Mythos, Anthropic's software vulnerability-hunting tool, indicates a huge challenge for information security and SC27. The ability of AI robots to find and exploit vulnerabilities in our systems, at scale, within hours or days rather than months, years or decades dramatically increases the risks of delayed and inept responses. We need to be fixing or at least mitigating the risks much more efficiently than before, and in parallel revising the systems development and assurance processes to cut the number and severity of design flaws and coding bugs in the first place - in other words, dramatically boosting systems engineering and quality assurance. We can't make sufficient progress simply by increasing the efficiency of our existing processes. Maybe AI will help but that comes with its own security challenges: integrity is not the robots' most impressive feature.

For me, that all points to a systemic problem in a field as dynamic and important as information security ... to the point that (after 30 years' engagement and loyal support) I'm rapidly losing faith in ISO/IEC 27002. It and other information security controls standards are rapidly becoming irrelevant and unhelpful, of historical interest only.

Worse still, the Information Security Management System specified in ISO/IEC 27001 (as often implemented and certified) can be a ponderous, bureacratic and regimented compliance-driven approach. The governance and assurance arrangements may be worthwhile but are corporate security committees, policies and risk workshops really the most appropriate way to address the rapidly rising tide of information risks and security issues? I fear not.

We need speedboats, but we're still busy designing supertankers. With big heavy anchors. Unreliable engines. And inaccurate charts.

At this point, I'm not at all sure there's a solution to these ponderous delays within the current ISO27k framework. Even if the committee enthusiastically adopts ISO's collaborative working approach, the best we can reasonably hope for is a reduction by about a third off the standard development process, shaving roughly a year or so. Ironically enough, SC 27 is taking years just to shift to the 'new' Online Standards Development. I feel increasingly like one of those desperate dinosaurs sinking helplessly into a tarpit.

So, what then?

One option is to distinguish the relatively stable governance arrangements (ISO's "management system") from the relatively unstable information risks and security controls being managed. The ISMS provides board or exec-level direction and oversight, clarifies business objectives and provides a structure or framework ... within which a much more responsive, flexible, nimble, agile set of information risk and security management and operations processes are required, with extensive automation and rapid escalation paths. Devolving critical operational decisions to the professionals and robots slaving away at the coal face is risky, yes, but not devolving is also risky. This is a classic risk/security trade-off. ISO/IEC 27001 should, in my opinion, emphasise managing the strategic and business risks associated with the ISMS as a whole, rather than the information and cyber risks it currently addresses in clause 8: leave those to the specialists, I say, giving them the resources, tools and latitude to work effectively, efficiently, competently, professionally.

Drain the tar!

Aside from re-focusing and re-writing '27001 clause 8, I would also sever the umbilical cord to '27002 by removing Annex A and the problematic Statement of Applicability completely. In Gary's world, the Risk Treatment Plan would dissolve to be replaced in the ISMS by a strategy (currently misleadingly named the "information security policy") with a set of high level objectives and metrics rather than being an ISMS implementation project plan, as is usually the way at present.

'27002, in turn, could be re-cast as an overview/introduction promoting other ISO27k supporting standards for the details on the information security controls - carving up the security landscape into smaller chunks that can be maintained/updated much more readily, more responsively, more usefully. The information risk management standard ISO/IEC 27005 - not '27002 - would become the key linkage between the governance stuff in '27001 and the security controls in '27001 and its supporting raft.