How does a hybrid infrastructure fit my accreditations?

What the auditor is looking for

In an ISO 27001 context, there is no one right answer. So while the auditor has a (very long) list of things to demand of you, many of those things have no prescribed form. So for instance you'll need to have an information security policy that you adopt and which your staff work to, but that policy must be (according to section 5.2): “appropriate to the purpose of the organization”.

The word “appropriate” comes up a lot in this realm, too. Many of the certifications you can obtain are based on the principles of risk management, and one of the key tenets of risk management is that you don't have to remove every last risk from your organisation – which is fortunate, because it's impossible to do so.

It's perfectly acceptable to accept that a risk exists and to let it continue, so long as you justify doing so and your approach is (here comes that word) “appropriate”. (Note at this point that you'll often take some action to reduce a given risk and then agree to live with the lower “residual” risk that exists as a result).

And even if you have some kind of adverse security incident, you won't simply lose your certificate as long as you can demonstrate that the controls you had in place were appropriate and that you've taken the appropriate action once it happened (there's that word again).

Going back to our public cloud example, you may decide to accept the risk of a cloud provider having a system problem and perhaps a delay in fixing it: this may be reasonable based on historic performance and the fact that the systems in question aren't so critical as to require absolute 100% uptime.

PCI-DSS is a much more prescriptive world to live in, though. It's very demanding and often has specific requirements such as: “Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers)”. It can be pretty technical too – for instance where it insists that you address vulnerabilities such as “Injection flaws, particularly SQL injection” and that you “Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws”.

One thing you do see when you read the PCI-DSS standard, though (it's only 139 pages – a bit of bedtime reading for you) is that it specifically mentions shared hosting providers – which in my book includes public cloud providers. Appendix A1 is entitled: “Additional PCI DSS Requirements for Shared Hosting Providers”, and when you get into what it says you'll find yourself thinking of a phrase beginning with “no” and ending in “Sherlock”.

Stuff like: “Restrict each entity’s access and privileges to its own cardholder data environment only” (translation: keep one customer's virtual world protected from the other customers) and “Enable processes to provide for timely forensic investigation in the event of a compromise to any hosted merchant or service provider” (provide the ability for investigation if it's required by the customer in the event of a breach).

Oh, and if you don't want to read the whole, thing, have a glance at pages 117-118, as this is where the service provider add-ons live.

When it comes to the public cloud provider in particular, one thing you can do will make the auditor a happy camper. We've already alluded to the key issue with public cloud providers – a lack of transparency of the underlying systems and the supplier's internal processes.

The auditor will want to be satisfied that all of the above are in order and won't cause adverse effect to your world. One approach is to carry out a risk assessment on each supplier, though for the larger ones this can be difficult as they'll probably tell you to bugger off.

Another is simple: pick a supplier that already holds the certificate in question. Trying to get PCI-DSS for your hybrid world? Pick a cloud provider that's already certified. Similar with ISO 27001: if you use a supplier and they're already holders of that accreditation the auditor will focus attention elsewhere.

Don't wait for the auditor

In the above examples, incidentally, you don't need an auditor to tell you what you need to do. To be fair, ISO 27001 is one of the less clear standards simply because you're left to decide for yourself what counts as a “reasonable” or “appropriate” control in each case; there are plenty of consultants out there who can steer you based on their knowledge and experience.

At the other extremity PCI-DSS is such a big document because it's really detailed on what to expect from the auditor in each section – so alongside each requirement it details how the solution for each requirement can be tested and also gives additional guidance notes.

And what all of the above give you is the ability to reassure yourself that there's nothing to say you can't use the public cloud, any more than there anything that says you can't use on-premise solutions.

The interconnect

In fact you'll probably find the bit that the auditor particularly cares about in each case is the connection between the two sides of the world. You'll be expected to apply the same controls to your private cloud and your public cloud, and

a single set of controls can be written to cover both worlds in one hit. Just be mindful that security auditors love to ask difficult questions about external connectivity, authentication, encryption and data storage – so there's every chance they'll look just as hard at the bits of electric string connecting each component to the world than they will to the technical aspects of the components themselves.

So does a hybrid setup fit with my accreditation aspirations? There's absolutely no reason, then, that a hybrid cloud setup can't fit within the certification regime to which you aspire or which you already hold. What matters is that you consider your infrastructure and systems as a whole, including the connections between them.

Your job can be made easier by picking suppliers that are already certified to the standard in question: it's a signal to the auditor that a similarly qualified peer has already done all the work for them on the third party, so they can focus on the specifics of your private components and the procedures and policies you've layered over the whole thing.

After all, a public cloud setup can be configured just as securely as a private cloud setup, and similarly it's just as easy to bugger up the security configuration of your private world as it is in the cloud.

What matters is that the whole thing, regardless of location, is subject to a regime that fits the requirements of the accreditation. And the auditors not going to write on your failure form that the reason you failed is: “Systems are partly hosted in the public cloud”. ®