The Vast Power of Certification!

I have a Dilbert cartoon stuck to my Novell CNE5 certificate (yes, I know, I’m sad about Novell’s demise too). Supertechie pushes Dilbert away from the server and cries “I Summon the Vast Power of Certification” – then says “well, this is embarrassing, that’s all I remember from the classes“….

But on a rather more serious note, “certification” is becoming important to a lot of companies as part of their marketing spiel—”trust us, were certified” seems to be the angle. But is this more than a Dilbert-style joke?

Well, yes it is, I think—sometimes. Sometimes it’s not even funny—there are companies claiming to be CMMI Maturity Level 5 on the basis of an appraisal of one process in one office many years ago (although the SEI has taken effective steps to address this lately); ISO 9000 became a bit of a joke in the last century for a while (“producing rubbish is fine as long as we say we’re producing rubbish and have the paperwork to prove it’s rubbish“). Sometimes companies seem to fling numbers with “ISO” in front them around as some sort of magic talisman. However, if you get taken in by such stuff, it’s probably your fault. If “certification” against some standard is playing any part in your decision making you should understand:

• The provenance of the standard: what body issues it, is it independent or merely an attempt to bestow legitimacy on a particular group of vendors?
• What the standard actually says: is this relevant to you or your customers?
• Scope: was the whole of the company claiming certification actually assessed or just a tiny part of it, and is this the part you’re dealing with?
• Currency: when was the company certified as compliant? If more than a year or so ago, why not more recently?

In the case of certification, it really is a case of “let the buyer beware”! Nevertheless, certification against a widely accepted standard can be useful, perhaps as a customer communication aid; perhaps as a way of showing management commitment and motivating people in a process-improvement initiative.

Let’s look at a couple of practical examples around security standards. Buying from someone certified to an accepted security standard, in particular, often makes people feel a lot more comfortable (or so many marketing teams hope).

Daniel Lowe, founder and managing director of UKSolutions (UKS), one of the UK’s largest privately owned datacentre facilities, for example, needs to convince his customers that the managed datacentre offers more data security than keeping data in-house. This really shouldn’t be too hard, as I’m fairly sure that data is safer being looked after by people with no particular interest in it, working to an SLA, than it is being looked after by people who have authorised access for business purposes but who may also have a significant dysfunctional interest in it (it may affect their wages or career opportunities). Obviously, data can be secured in the second case but this involves addressing more complex threats.

Anyway, Lowe doesn’t just need datacentre security; he has to be able to communicate the quality of his datacentre security to other people—and to do this, he makes use of ISO 27001 certification. It seems to me that there are two aspects of this—working to a ISO 27000 framework gives UKS an independent target to assess itself against; and it also gives customers a frame of reference within which to talk about their security requirements. And I have confidence that this isn’t just a cosmetic, marketing exercise, because Lowe places some emphasis on the holistic scope of his ISO 27000 initiatives—he says he certifies the whole organisation. There’s another scoping issue, of course, since customers can compromise the security of their data themselves but that is hardly UKS’ concern (although it might be an opportunity to sell training services).

IntraLinks has a similar but probably more complex need to communicate its security to its customers—it offers SaaS facilities for secure business collaboration used for financial transactions, mergers and acquisitions and so on. Its business depends on people trusting its security (to the extent that some 85 customers have commissioned independent security audits before using its services —the “network effect” of which is to increase IntraLinks’ own confidence in its security.

But IntraLinks doesn’t have ISO 27001. “It’s a business decision,” Bob Little, Product Marketing lead for the IntraLinks platform, says “and we think that the SAS 70 type II [see here and here] standard is more appropriate to most of our customers at the moment—although as we move into different industry sectors other standards will become important—such as for digital signatures in the pharmaceutical world“.

There are two types of SAS 70 (Statement on Auditing Standards No. 70: Service Organizations) service auditor reports in the USA. A Type I report assesses the service organization’s description of its controls and their suitability to specified control objectives. A Type II report goes further and also assesses the effectiveness of the controls operating in the period under review.

There are lots of standards and you need to understand which is appropriate to your needs (and you probably need to think about the cost of certification/recertification too). And, as Mush Hakhinian, IntraLinks’ security architect, agrees, certification against almost any accepted standard gives customers reason to have confidence in their supplier’s ability to manage its process (which doesn’t mean that the customer can ignore “due diligence” on what a given certification actually means, of course).

For IntraLinks, SAS 70 is a starting point. “Security has to be a holistic thing,” Hakhinian says, “and the customers of the ISO 27001 datacentre service you mentioned can’t claim ISO 27001 security levels themselves, just on the basis of using a certified service. Even users of our secure services can compromise their security if, say, they choose to not use digital rights management. Users could then remove documents from our secure environment and email them out over Hotmail to all and sundry”. People issues are, as always, a major factor in security—and sometimes made worse for business security by terminology and attitudes from areas where customer communication doesn’t matter (military-style security, for example, might have an adverse impact on people doing business out of proportion to threats it addresses).

A final warning from Hakhinian is that certification and standards are a useful tool in the security arena—but they look backwards. The need to invest in “good practice” processes and procedures to address known issues (which are what Standards are about) and to show that you’ve done so (certification) shouldn’t divert all your resources away from looking at emerging issues, that you haven’t met before. And this is an aspect of choosing what standards you certify to—standards (and this applies to more than just security standards) which have a process improvement component and which include “effectiveness metrics” as well as (or instead of) “check boxes” have a far better chance of coping with changing requirements and new issues going forwards.