Hey you, get off of my Cloud! Managing Cloud security, risk and controls

The sum of all wisdom regarding cloud security, risk, and control can be encapsulated in one phrase: “technology changes, but people don’t”.

One: Know your opponent

For all that the cloud is a new digital frontier, it’s still populated by the familiar old cast in terms of cyber threats: denial of service, malware, data loss, breach, phishing, and the rest.

Essentially, if there’s a storage device with everyone’s personally identifiable information in it, and someone leaves it lying around open to the internet, then that will always end badly, whether on a SaaS platform or in a data centre. It’s not that the baddies are getting smarter, it’s just that organisations can become lackadaisical.

As almost 25% of the data in the cloud contains personally identifiable information - with another 20% comprising intellectual property - that is a serious challenge. The cloud confers many advantages and benefits, but it is not inherently more secure since, as Gartner famously pointed out, 95% of cloud security failures will be the customer’s fault. Having cyber everywhere, in the form of cloud, allows your business to go anywhere, but it should do so safely and securely.

Two: All for one and one for all

Information security used to be a job for the IT department. It was all about spam filters and firewalls. Now it is much more about DevOps, code quality, and risk management - so it’s unfair to leave it all to the IT teams. Why should they carry the can? Cloud security and control cuts across risk management and governance too; in other words, it’s a multi-disciplinary model and each must play their part.

With migration to the cloud comes the need for fit-for-purpose identity and access management policies. Guardrails must be put in place that meet the demands of this new environment.

Three: The buck stops here (or here)

Ask any major Cloud Service Provider (CSP) and they will contend that cloud security is the joint responsibility of the client and the provider. The CSP is responsible for the security of the cloud while the client is responsible for the security of what they have in the cloud.

So, no matter which CSP you use, it’s down to you to protect your data and manage access to it. A plethora of regulatory controls from GDPR downwards apply to both on-premise and cloud infrastructure, and require you to: know what type of data you are putting in the cloud; have a firm handle on who is, and is not, allowed to access that data; and be clear about how exactly it is being protected.

That means having clarity, from a legal perspective, about how far your CSP is liable for security and, from an operational perspective, about doing proper due diligence on their capabilities. The more cloud native services you use, the more vendor responsibility increases. Different cloud services have different sets of security capabilities and features, “beta” services may not comply with your own security standards, etc. Do you have the organisational experience to know what you are looking for?

Four: One size does not fit all in cloud security

All good in theory but in practice that means having the necessary skills in-house to understand and manage this complex area. Not every organisation has this luxury, especially if the IT team is more comfortable and familiar with good old data centres. Mind the gap, in security terms, between legacy systems and cloud applications.

There is a real danger that, in the Klondike stampede to get in on the compelling benefits, organisations are migrating their data to cloud at too fast a rate for their security and compliance teams, and controls to keep up. Most organisations will readily admit that their on-premises data security is more tried-and-tested than their equivalent in the cloud.

Five: BYOC: step away from the cloud app

Then there is the risk within - your own people may be happily engaging in BYOC (Bring your own cloud) and BYOD (bring your own device) behaviours – the cloud equivalent of using an unencrypted USB stick in the mainframe.

Others may have decided to buy cloud services themselves without central visibility - such “Shadow IT”, to give it its ominous name, is a big problem. It can lead to the creation of all sorts of cloud accounts and applications that you may have no knowledge of, and therefore no control over.

You’ll need policies around data access and monitoring, and analytical tools to keep tabs on all this activity so that you can flag up any unusual behaviour and potential compromises.

Six: Access: one area

In such circumstances, it’s wise to adopt the Principle of Least Privilege: in other words, only give your people access to the functions they need to do their job and nothing else. The IT team used to be all-powerful in the data centre days, with omniscience and omnipresence; but that should not be the case anymore. Assign roles and responsibilities carefully and be clear about who does what. Isolate business lines from each other, for example: DevOps teams do infrastructure, app team do apps, and data teams do data. In cloud terms - lock down access to particular services, APIs, and geographies based on a user’s role.

Seven: Happy as a Dev in a sandbox

The issue of data egress can be addressed by letting your DevOps teams use sandboxes to play around with new technology in the cloud – because one of the main benefits of cloud is the ease by which you can use new services. Allow your teams to road-test applications and services without the risk of compromising client data by policies requiring that sandboxes only contain dummy data.

Ideally, sandbox teams should seek to minimise the amount of competing vendor software and cloud-native applications that are added to the governing architecture roadmap. This stops the Operations team getting application fatigue from having to manage too many different products. It should be on a need-to-have rather than nice-to-have basis.

Data centres used to be all about continuously patching legacy systems and that’s where errors arise. Now, in the cloud, infrastructure can be code and applications are code. Taking a DevOps and DevSecOps approach means better code - and better code means fewer vulnerabilities. In deploying infrastructure-as-code, we create more secure infrastructure, deploy faster, and reduce testing times.

Eight: All in this together

Working across the business in a multi-disciplinary way means that the organisation is right across issues rather than leaving it all for overworked operations teams. Involve the development teams, compliance teams, operations teams, and risk management teams at the start of your cloud projects. Nobody wants to hear the phrase: “We’ve been secretly working on this ERP deployment for the last 18 months and are going live next week - do you want to have a look at it now?”

Failure to do so can mean massive technical debt and huge amounts of rework – which cloud is meant to consign to the history books.

Automation, one of the cloud’s gifts to organisations, will be a key part of your security and risk response. The exponential growth in security threats set against the incremental growth in security teams means that machines can pick up the routine, mundane security tasks freeing up the expert human to focus on higher level issues.

Nine: Enterprise-wide view

It’s best to have a fit-for-purpose, bespoke security approach across services and providers. A lashed-up, creaky, Heath Robinson approach built up from a variety of different tools makes it much easier for something to go wrong.

The secret to addressing issues of risk, security, and control is to bring all your stakeholders on board at the outset, and to establish collaborative ways of working - which should extend to working in partnership with your CSP.

Your governance plan should identify the security controls you will need specifically for the cloud – such as multi-factor authentication, data encryption, and compliance oversight protocols – rather than just relying on existing data centre practices.

Ten: Building the guardrails

Finally, be clear that there is a compelling need for security rigour and review in the cloud. Protection may also be needed from your own organisation, which is where the danger can lie after you have spent a lot of effort delivering a highly secure cloud; so clearly identify risks and responsibilities. A solid approach is to build your system as if all the data it contains is personal.

Without sufficient guardrails, it’s very easy to do something wrong in the cloud. The main challenge is diving into cloud too quickly and not designing it from a security perspective from the start alongside relevant stakeholders. People may be your biggest risk in security terms, but they are also your biggest asset.

Summary

The cloud, when used in the correct way, can offer better security, agility, and productivity than is possible in your own bricks-and-mortar Data Centre. Thriving in the cloud means being secure, vigilant, and resilient in the face of the risks as well as exploiting the incredible upside opportunities.