Frameworks, Bloody Frameworks

Last night a friend sent me an email drawing attention to the UK Government’s new cyber security scheme. This one is called “Cyber Essentials“. So what’s new? And what does it offer?

The answer is very little. It contains no new advice or controls. It’s incomplete and insufficient. And it’s not mandated by regulators. In fact it’s nothing more than a restructuring of advice already covered by more important standards.

It’s unfortunate that governments and institutes insist on publishing their own versions of standards at a time when many enterprises are forced to address specific ones. The most widely enforced standard at present is the Payment Card Industry Data Security (PCI DSS) standard. But this important standard is not even mentioned in the Cyber Essentials guide.

The unfortunate truth is that cyber security standards are a nightmare for enterprises of all sizes. Big companies are required to provide annual evidence of the existence of hundreds of control requirements. Small retailers are forced to employ expensive consultants to translate technical standards into action.

It’s not advice we need, but consistency. In a world awash with standards, where tick-box compliance has replaced security, what matters is structure more than content. This perhaps explains why the Cyber Essentials contains an appendix mapping the new standard onto several others. Unfortunately it doesn’t cover the 220 controls in the PCI DSS so it’s no use to the millions of retailers out there.

There’s no benefit in having all the rights words, but not necessarily in the right order. Any framework is a means to an end, not an end in itself. If that end is to complete a questionnaire, then the questionnaire structure is the sequence you require. If it’s to design a compliance workflow system, you need a framework structured around organisation responsibilities. If it’s just for use as a reference document, you simply need a good index.

There are more than a dozen ways of structuring a security standard. I know because I experimented with all of them when drafting the original BSI Code of Practice back in 1993. You can do it around process, services, life cycles, technology, job function, subject areas, etc. Or you can simply pluck headings out of the air, as many standards do. 

The COBIT 5 standard is structured around organizational processes. The ITIL standard around IT services. ISO 27000 was originally structured around ten “natural subject areas” as might be encountered in enterprise security manuals. The ISF Standard of Good Practice is structured around six areas of IT Security responsibility, mapped onto several dozen individual topics. In contrast ISO management systems tend to follow a “Plan, Do, Check, Act” life cycle.

Other standards are more arbitrary. The PCI DSS follows an unusual structure of twelve broad control requirements grouped into six overall headings, which collectively define more than two hundred individual, prescriptive requirements. A further complication in navigating PCI DSS requirements is the fact that the standard is also enforced through a “Prioritized Approach” which sets out the controls in a completely different order, reflecting the urgency of their implementation.

Further security standards published by governments and specialist circles such as The Cloud Security Alliance have only added to the navigation challenge facing CISOs. The Cyber Essentials standard adds a tad more confusion by adopting a new structure of five subject areas pointing to “Ten Steps to Cyber Security”. Will the madness ever end?