How does a hybrid infrastructure fit my accreditations?

Security-related certifications such as ISO 27001 and, more particularly, the Payment Card Industry Data Security Standard (PCI-DSS), have stringent requirements regarding the controls on infrastructure, how data is routed and stored around it, and so on.

Particularly in the cloud components of a hybrid setup, the control you have over the lower-level elements of the infrastructure is limited. So can a hybrid setup and your required accreditations live in harmony?

Incidentally: I know I should be saying “ISO/IEC 27001:2013”, but life's too short and you'd get fed up with me. Hence I'll refer to it as “ISO 27001”.

The purpose of the accreditations

The first thing to remember is that the likes of ISO 27001 don't exist to tell you how to implement your hybrid infrastructure. They don't insist that you use, say, Windows rather than Linux, so why would they dictate whether you should have on-premise systems rather than cloud systems (or, for that matter, vice versa)?

Neither does any of them claim to be the be all and end all of systems and information security: for example ISO notes that: “Using this family of standards [the ISO 27000 range] will help your organization manage the security of assets such as financial information, intellectual property, employee details or information entrusted to you by third parties”. Note use of the word “help” there – it's just one tool you can use as a framework for the security of your organisation.

This said, though, many companies go to the trouble of obtaining certifications because it's demanded of them by either their suppliers or their customers. So it'd be no surprise to have your bank on your back until you obtain PCI-DSS accreditation, for instance, and there's an increasing number of customers who insist on ISO 27001 certification before they'll buy services from you. And in both cases you'll find that cyber security insurance premiums will reduce if you're able to wave some certificates under the nose of the broker.

Do I actually need the accreditations?

Continuing this train of thought, then, none of these certifications is actually obligatory in the legal sense (unlike stuff like Data Protection registration) or the regulatory sense (eg, the rules imposed by the regulator of your industry if you're a telco, a power company or some such).

In many cases when your suppliers or customers ask for a particular certification, they're actually saying: “We want to see that your systems are configured and managed to sufficiently rigorous standards, and that you have strong policies and procedures in place, such that we can have a good degree of confidence that our data is safe with you.”

In many cases it's enough to show yourself to be “compliant” with the requirements of the standards – basically to self-certify that you conform without an external auditor stating that you do so. To quote ISO again: “Some organizations choose to implement the standard in order to benefit from the best practice it contains while others decide they also want to get certified to reassure customers and clients that its recommendations have been followed.”

Personally I don't really see a great deal of point in being compliant without going the extra step of having the audit. Unless you're a very small company, getting yourselves to the stage where you're genuinely aligned with the requirements of the standard is a huge task, and if you're confident that you've got that far then the cost of the audit (a few days out of the schedule of a lump of your team, plus a few thousand quid) is a modest one.

Either way, we'll assume if you're reading this that you've decided that yes, you do need the accreditations, whether self-cert or officially audited.

Public versus private components

Moving on then, let's look at the difference between the worlds on each side of the hybrid infrastructure.

Looking at the on-premise aspects for a start, we have a collection of systems that are connected to a LAN, are almost certainly connected to the Internet, and which have people sitting at computers accessing them.

There's some kind of user database (probably Active Directory in a Windows world), and perhaps a few systems that have their own authentication mechanisms because they can't integrate with the central directory service for one reason or another.

Technical staff, either in-house or outsourced, manage the systems and underlying networks, and there will be some kind of regime, either ad-hoc or rigorous, for applying updates to systems – both trivial (eg, standard Windows Update functionality) and complex (eg, major version upgrades for your core database or finance system).

What do we have when we look at the public cloud aspects? Well, pretty much the same actually. There's nothing fundamental in the public cloud that doesn't exist in some form in the private cloud: really the only difference is the level to which they apply in each world.

Internet connectivity's the first obvious one: the nature of the public cloud is that unless you're loaded and can afford direct private circuit connectivity into the back end, you're going to be managing it over the internet.

Hence the default level of Internet access into the public cloud installation is much greater than that into the on-premise components, which might not allow any inbound management connectivity at all. Turning this on its head, though, the reason you don't have inbound connectivity to the on-premise components is that you put a firewall in the way to prevent illicit access – which of course is precisely what you'll do on your public cloud too. Yes, there'll be a little more access in the latter case but this will be controlled by strong encryption and certificate-based authentication and you'll only permit it from your own on-premise IP ranges (you will, won't you?).

Then there's the geographical aspect: you have absolute control over the geography (and hence the applicable data protection laws and other associated legislation) of your on-premise installation. But realistically the same applies to the public cloud too: in the multi-region providers you have control over which region your data sits in, and you can be sure it remains there unless you move it. So geography's not a problem either.

The other difference is the level of control you have over the underlying infrastructure in each side of your hybrid cloud. In your private setup you have access to everything from the bare metal upwards, which gives you absolute control over its operation.

In the cloud you don't have this: you have to rely on the service level agreement from the cloud provider, and if something goes pear-shaped then you depend on the provider's techies to fix the problem. But there's a flip-side: a cloud provider's infrastructure is likely to be much better protected against disaster than the average on-premise installation, and they've probably got far more access to spares and engineers than you have internally. So what you lose in absolute control you probably make up for in speed to fix in the event of a problem.