ISO 27001 certification doesn't guarantee security

A lot of people think an ISO 27001 certified service is completely secure. In my opinion, that’s not entirely true. I’m not trying to criticize this way of thinking, though, because I understand it can be difficult to grasp the idea behind this certification.

Below I’ve laid out some explanations and analysis with a few examples to help you see what this certification actually means and what myths are not to be believed.

a security management system

The goal of an ISO 27001 standard is to put in place an information security management system (ISMS). Mainly, you should remember that it involves specifying and implementing a system (people and processes) that manages information system security.

The security system should primarily maintain security controls (whether technical or organizational) and update or improve them over time.

say what you do and do what you say

ISO 27001 requires organizations to specify how they will manage information security. This implies a considerable amount of communication that organizations often gloss over due to cost issues and higher priorities.

Basically, organizations must put a control in place for any given procedure (or process). They have to do what they say and say what they do. If a certain process no longer works or is just plain wrong, organizations can (and must) update it and set up a control for the new process. Here we use the wonderful Deming wheel (PDCA – Plan, Do, Check, and Act), which guides all underlying models of ISO 27001 certification.

This means that ISO 27001 certification does not guarantee control efficiency, but instead ensures implementation conformity to pre-defined specifications.

no processes, no verification

Problems arise when organizations don’t specify a process for a given action. This will surely go unnoticed by auditors, because they only make sure that administrators follow processes already in place.

Example: if a process exists for the security impact analysis of any change (RFC – Request For Change) subject to the Change Advisory Board (CAB), then any change made with no official RFC will come in under the radar (for RFC and CAB, see ITIL processes).

As long as this “unofficial” change does not cause a security incident (managed by a specified and monitored process), it will go unnoticed. However, if the post-mortem incident report locates the “off-the-books” change, then administrators will correct it. This is the PDCA model’s good side.

security incidents welcome

Let me reiterate: a process is a process, and it must be followed. It’s not a problem if security incidents arise. However, management of these incidents should follow processes.

Some of you are probably thinking "oh really?” Yes. And I assure you, this system is much better than that of some companies or organizations where no incident management process exists.

the “black hole” between annual audits

To achieve ISO 27001 certification, an initial audit must be performed. Once that’s been done, annual control audits ensure correct system function.

Typically, there’s a mad dash six months before the audit date to troubleshoot and show the auditor that the system works (meaning that administrators monitor processes and launch/continue the upgrade plan).

Between two audits, a lot of things can happen—some great, some not. It all depends on the commitment, expertise, and professionalism of the ISMS teams in charge.

is ISO 27001 completely worthless?

No. Obviously, ISO 27001 is a good standard. A certified information system that complies with this standard relatively guarantees its structured and organized security management over the long term.

Moreover, a system certified each year for several years (about four or five) will certainly be more developed than a system that just received its first certification.

Whatever the situation, it’s important to understand the certification’s full scope (or reach), so as not to be taken in by overzealous believers in ISO 20071.

what else is in the works to take things a bit further?

As for cloud computing, the “continuous certification” approach is a particularly hot topic. To learn more, I recommend you check out the Cloud Audit and Cloud Trust Protocol (CTP) initiatives offered by the Cloud Security Alliance.

For questions about technical components, head over to NIST and check out their Security Content Automation Protocol (SCAP). SCAP is an XML “dialect” designed to automate security control information gathering.

Jean-François

This post was originally posted in French here.

photo: © S.John - Fotolia.com