A Brief History of Cyber Essentials

 

Chris Ensor answers some common questions about the scheme

​

The Cyber Essentials scheme has grown a lot since its first launch in 2014. Together with the “10 Steps to Cyber Security”, it has become an essential part of our cyber security toolkit. But it’s now time to give the scheme a bit of a makeover, and we’ve started with the web site.

So as we take our first step, I wanted to take the opportunity to answer some of the questions I’m often asked, having been involved in the scheme since its inception.

​

Where did it all begin?

​

After we had published the “10 Steps to Cyber Security” in 2012 we started being asked for more specific advice on how to select appropriate security controls. People would say, “The 10 Steps are great but they’re a bit high level and we really need some more detailed guidance.” From that CE was born.

There is no right answer in security, as there are always a number of factors to take into account, such as the capability of threat actor, the business need, the risk appetite, etc. That’s why publications like the 10 Steps and ISO27000 offer ingredients (ie security controls) but leave it to individual organisations to concoct recipes based on their individual circumstances.

What we tried to do with CE was develop a common recipe based on evidence of the attacks we were seeing at the time. It was not intended to be a silver-bullet for all forms of cyber attack, but to offer organisations a first step in their journey to protecting themselves in cyber space.

Whilst CESG (as we were known at the time) was on the hook to deliver, this was a true government/industry collaboration, involving the likes of Cabinet Office, BIS, IASME, ISF, CREST, to name but a few.

​

How did we choose the risk scenario?

​

The recipe we developed was aimed at enterprise IT and based around a simple risk scenario.

We assumed the attacker had some technical knowledge, they were sitting somewhere on the Internet, and were using what we called ‘commodity’ attack tools. These were tools that anyone could freely download and use, such as Nessus, Metasploit, and NMAP (a good primer can be found at Common Cyber Attacks: How to Reduce the Impact).

This scenario was also one that we were dealing with weekly at the time, and we were able to use the results of our investigations into a number of corporate compromises to help us select the most effective controls, that were also practical to implement and relatively straight forward to test.

​

How did we select the controls?

​

Through using the risk scenario we were able to select and justify the 5 controls that we believed were the minimum needed to ensure an organisation was confident it was adequately protecting its system.

That’s not to say an organisation wouldn’t benefit from implementing other controls, but we wanted to keep things simple and focus on those that would directly and measurably mitigate the risk.

A good example where we had lots of discussion was education and training. Whilst it’s an important control, we decided it’s actually hard to get right and testing whether it’s effective is *really *challenging.

Organisations often have competing priorities for resources and therefore, we focused on a small number of technical controls that if implement consistently would make a tangible difference to an organisation’s cyber security, and would minimise the damage caused when someone opened a malicious attachment or clicked on a link. People will still do this whether trained or not!

​

Why don’t we allow ‘alternative’ controls?

​

Large organisations often cite patching as something they find difficult to achieve, especially within the prescribed time limits and would like to have other controls recognised as equivalent.

I have a lot of sympathy with this view, because enterprise patching on a large scale is not a mature engineering process, particularly where the patches might break existing business applications. However, without applying the latest patches, the systems quickly become vulnerable.

Patches are reverse engineered and exploits quickly developed that exploit the bugs the patch is intended to fix. It’s also clear that the time between patch release and commodity exploit development is getting shorter. So, the longer a system goes unpatched, the higher the likelihood of a successful attack.

If it’s not possible to apply patches quickly, then organisations have to find other ways to protect themselves. This can be hard, as deploying a patch gives you 100% certainty that the bug it fixes can’t be exploited, and it’s very hard to do things that will give you the same level of confidence. So, we have stuck firm to the patch requirement rather than putting the responsibility on the certification bodies to make that judgement during an assessment.

For those companies that struggle to meet the requirements, it’s for them to put forward an argument to whoever demands they hold Cyber Essentials Certification, explaining how the alternative measures they have put in place offer similar confidence.

​

Is Cyber Essentials designed for small organisations?

​

I’ve heard it often said that CE was designed for small organisations, but in reality it was designed to be size agnostic. The attacks we were dealing with at the time involved large corporates and our analysis showed that, had the controls defined by CE been implemented consistently across the organisation, the particular attacks witnessed would have been prevented (of course we can’t say whether the attacker would then have deployed more sophisticated techniques !).

Whilst it might be easier to implement and assess the controls in a small organisation, they are equally important to large organisations, as we found when we analysed the attacks.

​

Why do the different ABs operate in different ways?

​

Cyber Essentials has three levels of operation. At the first level are the companies (the Certification Bodies) that carry out the assessment and are approved to issue certificates. There currently are over 170 of these, many of which are SMEs and Micos businesses.

At the second level we have 5 Accreditation Bodies that each oversees a sub-set of Certification Bodies.

Finally, we have NCSC at the last level that oversees the Accreditation Bodies and runs the overall scheme.

Why do we have 5 Accreditation Bodies? When we set up the scheme we wanted to ensure we allowed for competition and innovation. Whilst it might have been a lot easier to select one organisation in the beginning, we decided to publish some criteria and allow any organisation that could meet them to become an Accreditation Body.

Whilst this approach has allowed different organisations to bring something new to the party, in terms of customer experience it’s brought more inconsistencies than we first imagined and certainly made the scheme a little harder to navigate. Decreasing the confusion around the scheme is certainly an area we want to improve in the future.

Those are the big questions I’ve been asked in the past, no doubt there are others and maybe they’ll be the basis for a future blog!

​

Chris Ensor, Deputy Director for Cyber Skills and Growth