… the cloud?
CP: What should be considered when developing a cloud security strategy?
MB: Many issues should be considered when developing a cloud security strategy, but the first should be, “Why are you moving to the cloud?” This is not to suggest that you shouldn’t, but rather to expose the thinking behind the decision in the first place, to ensure that any security-related thinking is integrated with that. Whether the answer is for CapEx or OpEx savings, ease of deployment, faster response times, better collaboration or one of a myriad of other reasons, if your security strategy is not aligned, you’re like to discover significant tensions within your organization as you proceed with any deployments.
The next question is probably, “Who will have security responsibility for all the different parts of my deployment?’ Which “aaS” you choose – PaaS, IaaS, SaaS – will impact this decision. What can easily happen, though, is for components to fall through the gaps, and to end up with no owner to monitor, upgrade, patch or replace them, leaving an entire deployment at risk.
Then there is the question of “What goes where?” Although this is, at root, an architectural question – ensuring that sensitive data is kept inside the corporate boundary or applying appropriate API controls, for instance – there is a broader question: “Should you go public cloud only, hybrid cloud – part public, part private – or multi-cloud, using private and several public clouds?” [See insights on that from this year’s Red Hat Summit here.]
Here you need to consider costs of availability — and not just up-front cost. It may be cheaper on paper to go with a single public cloud and no private cloud, but can you protect your sensitive data adequately? Again, what happens if the public cloud suffers an outage? Could you move core functionality internally in time? Is there a danger that you will suffer cloud “lock-in,” and be unable to migrate to a different provider – or back in-house – in the future?
A final question to consider early in the process is how can you manage risk throughout the data cycle. Any application will need to be creating and collecting data, using it, sharing it and disposing of it. Where should all of these functions live, how can they be monitored, automated, and, crucially, audited? Frameworks such as GDPR, for instance, require that data destruction includes removing data from backups, so if you don’t know where backups reside, or who is responsible for them (see above), you will have problems with your applications and their data in the future.
CP: There have been many data breaches in the press recently. What cloud security mistakes were made?
MB: It’s important to understand that IT security as a whole, not just cloud security, is complex and ever-changing. This is in direct correlation to the expansive, complex and heterogeneous nature of modern data center landscapes, from mixing legacy and emerging systems together to adding raw innovation in the form of Linux containers or microservices to an established architecture.
One thing remains clear, however: Good hygiene is always important. “Hygiene” as it relates to security means …