Generic infosec controls

ISO/IEC JTC 1/SC 27 is in the early stages of updating ISO/IEC 27002:2022 - the generic set of information security controls generally worth considering, whether as part of a '27001 Information Security Management System or not.

Rather than leaping straight into the usual process of inviting then discussing and addressing comments and proposed changes, the revision project's editorial team is taking a different route this time around: the committee intends to decide what changes are required at a broader level before approving the revision and digging into to the nitty-gritty details of those changes.

So, the editorial team set out on the project with two calls-for-comment.

First, committee members were politely invited at the end of May to respond to these two specific questions (with a little warning about out-of-scope comments being, well, out-of-scope!):

• Are there any gaps in the current ISO/ IEC 27002 control set? Please provide justification.

• Is there a need for new controls in addition to the current ISO/IEC 27002 control set? Please identify these controls and provide justification why these additional controls are needed.

The responses just in from ~4% of the committee's ~800 expert members make fascinating reading - some 46 pages with a surprising amount in common. FWIW here's my decidedly unofficial summary:

1. Controls such as AI governance and security and Post-Quantum Cryptography were, of course, the most popular suggestions, and I'm sure the committee will 'enjoy' thrashing out the details.

2. Various other new controls (e.g. Software Bill Of Materials, testing incident responses and securing software development environments, cyber-insurance) were suggested.

3. Some wording changes to the existing text were suggested e.g. the information asset inventory in control 5.9 should note supplier dependencies; control descriptions should more accurately reflect the guidance beneath; infosec controls that are also information security management controls (e.g. infosec policies) should have consistent wording.

4. Some experts suggested referencing other standards for more information on specific infosec controls (plugging the gaping gap around business continuity, recovery and resilience, for instance, by referencing ISO/IEC 22301), plus broad control concepts such as secure-by-design.

5. Governance also merited a few mentions, albeit only at a high level so far.

6. Two experts (one of whom was me) pointed out that, since information security controls are intended to mitigate information risks, we would need to identify new/changed risks in order to justify new/changed controls ... which would be challenging given that risks aren't explicitly described in '27002:2022. The ransomware threat, for instance, is notably absent, along with fake news (disinformation) and others. Clarifying which information security controls are worth including in the standard should flow naturally from identifying and analysing the associated risks in a generic manner, distinguishing rare or obscure risks and controls (strip out) from the more common ones (keep in).

7. Concerns were raised re the committee's capability to maintain currency going forward, given the pace of change in information technology and cybersecurity versus the time needed by a large international committee to propose, discuss, agree and implement changes to the standard. Deciding on the changes needed is important but does it really need most of a year, and is it appropriate to refuse further changes?

8. Inconsistencies of depth and scope between the existing controls were also noted.

Of those 8, I suspect only #1 and #2 will be deemed in-scope to avoid scope-creep compromising the planned timescales as noted in #6 (a project risk and control in action!) but I may well be wrong on that, and I hope we will at least have the opportunity to discuss all the responses at the next meeting or before (see the note at the end).

The cross-over with other ISO27k standards is interesting. It could be argued that if '27002 is only to cover information security controls, then other relevant types of control could be covered by other, complementary standards:

• '27001 could explain controls relating specifically to the design, operation and oversight of the management system, omitting infosec controls (meaning no Annex A with changes to restrict clause 6 to the management of risks relating to the ISMS, not the 'information security risks' currently covered);

• Secure-by-design is an example of a control concept potentially worth incorporating into clause 6 of '27001 as general guidance, re-emphasising that organizations are encouraged to look beyond the Annex A controls;

• Other core ISO27k standards such as '27003-'27008 could expand on controls relating to ISMS implementation and change projects, management information, information risk management and assurance;

• '27014 on infosec governance could expand on governance controls such as:

  • Authorisations and approvals;

  • Clarifying who the ISMS stakeholders are and what are their objectives in order to gain their support for governance structures, approaches and changes;

  • Determining/clarifying ISMS-related requirements and objectives, preparing strategies and policies;

  • Justifying, monitoring and squeezing the most value from ISMS-related investments;

  • Prioritising, planning and monitoring all this stuff appropriately in relation to other business activities;

  • Clarifying ownership of various ISMS-related assets, approaches, objectives, risks, controls etc., along with roles, responsibilities and accountabilities, control over the associated resources and productive integration with all corporate functions plus supply chain partners.

Therefore '27002 should exclude all of those.

Alternatively, I have previously suggested that '27002 could become just a succinct high-level summary/introduction to information security control domains, referencing narrow-scope standards for the details in each domain (e.g. IT system security, network security, application security, cloud security, AI security, OT security, IOT security, privacy, intellectual property protection, safety and so on). That has the advantage of carving-up the detailed work across individual teams of specialists (some of which already exist), and minimising the time needed to maintain '27002 itself.

The project team intends to pose these further questions in the next call-for-comments, following analysis and discussion of the first responses at the committee meeting at the end of September:

• Is there a need for changes to the current ISO/IEC 27002 control set? Please identify the changes needed. [That could be interpreted as simply a rephrasing of the earlier questions about closing gaps with new controls, although it also presents an opportunity to discuss revising or dropping existing controls - the point I've just made.]

• Is there a need for changes to the guidance to the current ISO/IEC 27002 control set? Please identify the changes needed. [Presumably 'guidance' here refers to the guidance sections for the 93 listed controls, providing roughly a page of details expanding on each of the succinct control and purpose statements. However it could also mean commenting on general guidance in the standard, such as the introductory section, the control attributes and the annex about attributes. Furthermore, changing the guidance may mean updating the control descriptions and titles, with knock-on effects in '27001 Annex A.]

Responses to those questions would presumably be discussed at the following committee meeting in March 2027, leading onto several further years of drafting, reviewing, discussing, updating and finalising the changes by which time much of the above will be ancient history - and so the hamster wheel turns.

This is a fascinating topic for the global infosec community to discuss on the ISO27k Forum or elsewhere e.g. on LinkeDin and ISACA ENGAGE. What do you think? How would you respond to those 4 yellow questions? Is there a better way for the project team to herd us cats?