ISO/IEC 27002 revision

It should be obvious from my previous comments here on this blog, on www.ISO27001security.com and on the ISO27k Forum, that the last revision of ISO/IEC 27002 was less than satisfactory in my jaundiced opinion. When released in 2013, the standard was already out of date (e.g. it pretty much ignores cloud computing, BYOD and IoT - all topical issues that were emerging at the time the standard was being revised) and had some serious flaws  (e.g. in the garbled continuity section). What may not be quite so clear is that the team responsible for the revision is a top-rate international group of experts in the field - experienced, intelligent, committed professionals. 

It wasn't the team that let it down so much as the tortuous revision process we had to follow.

The next revision of 27002 could easily go down the same muddy path but there's hope, now, for a different approach. A major stumbling block, to date, has been the structure of 27002, derived from the original donor security policy that became first BS 7799, then ISO/IEC 17799, then 27002. Things have moved on some way since the 1970's and 80s! It's high time to update the structure. The crucial question we are tackling right now is how to update it. 

Yesterday we considered and discussed seven proposed structures, plus an eighth straw-man option (i.e. no structure is perfect so we could forget about the structure to concentrate solely on the content). The favoured option, currently, is two-fold: 

1. The standard could be structured into the following 'themes' (categories or types of control): organizational security; behavioural security; technical security; physical security; and third party security. Most information security controls would fit quite naturally and easily into one or other of those categories (or 'themes'), leaving relatively few ambiguous or complex controls to be allocated arbitrarily between them (or simplified and perhaps split up). Few if any controls would be orphaned, being out of place in all those options. The explicit names for the categories are not cast in stone but the structure works better than the other options considered so far ... 
   
   
2. ... while those other structural options could be taken into account anyway in the form of 'attributes' or 'tags' for the same controls e.g. aside from where they are placed in the main structure, we could also tag the controls as preventive/detective/corrective, confidentiality/integrity/availability etc., reflecting the other classifications or structures considered.

If this proposal is agreed, the work to define, classify and tag the security controls can start as soon as the revision project is approved. Admittedly, there may still be disagreements about the classification and tagging, but hopefully most of the discussion will be more productive in connection with the controls themselves - what they are and how they are described - rather than where they should sit in the standard.

Offsetting the advantages, there would be additional work in this approach including:

• Carefully defining the criteria or rules for classification and tagging
• Classifying and tagging the existing controls 
• Reviewing and revising the existing controls
• Retiring controls that are no longer applicable
• Adding new controls in areas that are weak
• Addressing any anomalies, gaps and duplicates
• Dealing with controls that are already documented adequately in other ISO27k and non-ISO27k standards (e.g. ISO/IEC 27001, 27003, 27004, 27005, ISO 22301 etc.)
• Generating one or more appendices (possibly just a table) with the controls grouped by or referencing their respective tags 
• Mapping the controls from ISO/IEC 27002:2015 to the new structure, so current users can migrate more easily
• Coordinating and leading the overall effort to ensure that the end product is user-friendly, comprehensive, accurate, valuable, up-to-date, maintainable, fit for purpose and on time.  That's a tough job, whatever approach is taken!

ISO/IEC 27008 is close to being finalized. The standard concerns auditing or reviewing/assessing "technical" controls, a subset of all information security control - fair enough. There is a remaining issue to align and reformat an annex on auditing cloud services with the rest of the document, possibly in the form of a worked example illustrating the audit/review approach described in the main body of the standard.