Welcome to NBlog, the NoticeBored blog

I may meander but I'm exploring, not lost

Jun 14, 2017

NBlog June 14 - the periodic table of atomic controls

Many information security controls are multi-purpose, hence they could be specified in several places, several policies plus procedures and standards and guidelines etc. That multiplicity creates a nightmare for the ISO/IEC JTC1/SC27 project team trying to generate a succinct version of ISO/IEC 27002 without duplications, gaps or discrepancies in the control catalog. It’s also a potential nightmare for anyone writing corporate policies, or an opportunity depending on how you deal with it. 

My current pragmatic approach is to mention [hopefully] all the important controls in each topic-specific policy template, with a reference section that mentions other related policies, creating a kind of policy matrix. I’m still wary of gaps and discrepancies though: with 60+ policies in our matrix so far, it’s fast approaching the limit of my intellectual abilities and memory to keep them all aligned! It’s an ongoing task to review and revise/update the policy templates, without breaking links, creating discrepancies, or missing anything important.

My mention of ‘control catalog’ hints at a more rigorous approach: a database where every control is listed once, definitively, and then referenced from all the places that need to describe or mandate or recommend the controls. That in turn requires us to be crystal-clear about what constitutes a control. User authentication, for instance, is in fact a complex of several controls such as identification, challenge-response, cryptography, biometrics, enrolment, awareness, logging, compliance, passwords/PINs and more. Some of those are themselves complex controls that could be broken down further … leading to the ultimate level of ‘atomic controls’ or ‘control elements’. The control catalog, then, would be built around a kind of periodic table of all known atomic information security controls, which can be used individually or assembled into 'molecular controls' mitigating various information risks.  
Extending the analogy, it would be helpful if our periodic table (or 'information security elemental control catalog' or whatever we end up calling it) had a rational structure, some sort of logical sequence with groupings of related atomic controls in much the same way that, say, the 'noble gases' are clustered together on the real periodic table, giving the colored regions. Also, the atomic controls would need to be rigorously specified, with equivalents for the atomic number and other chemical parameters. Right now, though, I can only guess at some of the parameters that might be used to group related atomic controls: I suspect a structure might emerge once the complex controls are decomposed, the constituent atomic controls are identified, and they start piling up in a big unsightly heap. These are just some of the complexities that SC27 is currently grappling with in the ongoing revision of ISO/IEC 27002.It’s also, by the way, something where we might help out SC27 by compiling our periodic table. At the SC27 meeting in Hamilton, I tried unsuccessfully to persuade one of the project groups to set to work on that, instead of what they were proposing to do (yet another revamp of the glossary). It’s really a sizable research project, an idea for some enterprising academic, MSc/PhD student or research team maybe. It's entirely possible that someone out there is already on to it. If so, I'd love to hear about or from them. Do please get in touch.Regards,
Gary (Gary@isect.com)
PS  I published this blog item on LinkeDin to reach a wider spectrum of readers. Michela Liavaag kindly pointed out that NIST SP800-53 has a controls catalog ... but the controls listed in Appendix F are compound or complex controls, not elemental. I'm proposing to take the analysis down to the lowest level, to the building blocks from which practical controls are assembled.