Encryption’s role in GDPR compliance and cloud data security

null

Security of data in the cloud is a hot topic, especially with so many data breaches occurring during 2017 and the introduction of GDPR being just months away.

The field of security is so broad, it can be difficult to know where to start. In the last twelve months, I’ve had one friend who has had her cloud servers hacked and crypto ransomware installed, forcing payment of a two bitcoin ransom. Another friend had her cloud email server hacked, with the attacker modifying the bank account details of outgoing invoices and redirecting payments from the company’s bank account to the hacker’s. Both instances were security breaches and data breaches, resulting in direct financial loss.

To try to break down this broad topic and provide a how-to guide tailored towards GDPR compliance, I’ve devised four actionable steps across two categories:

Let’s examine each step in turn.

1a. System level security: fully understand the limits to the security provided by your cloud service

Are your machines fully patched with the latest operating system security updates? Are your firewall rules in place? Do you find it strange that I’m asking these questions in a discussion about cloud security? The first step to security is understanding what you’re responsible for, and what your cloud provider is responsible for; failure to do so can be catastrophic.

It’s very commonly argued by vendors that cloud services have a higher level of security than achievable by an average system administrator. For example, if you host your email on Office 365, compared to running your own email server in your basement, it’s likely to be more secure against hacking attempts. After all, if you run your own server, you are responsible for managing the entire security of your server, from setting up your firewall rules, to monitoring intrusion attempts, patching and installing security updates, backing up data, ensuring 24x7 power supply and internet connection, and everything else in between.

“Therefore the cloud is safe!” – This can easily be the impression you’re left with after attending enough cloud marketing presentations. But you have to be very cautious about getting complacent or completely misunderstanding the cloud provider’s security claims. For example, when you fire up a virtual machine in a public cloud like Amazon or Microsoft Azure, this does not mean that this machine is secure and that your cloud provider will provide security and monitoring services. In this situation, you’re consuming a platform-as-a-service (PaaS), which means that you are responsible for whatever you put on that platform, including the operating system.

Therefore it is critical for you to know what’s in your service contract and to understand what is your responsibility.

It’s also critically important to remember that when you use cloud services and store data in the cloud, you are in effect implicitly granting your cloud provider access to that data. Inevitably, selected employees of the cloud provider will have access to that data, so you are relying on the hiring policies and security procedures of the cloud provider to ensure that the cloud provider stays friendly and does not “go rogue”. Thus, many people fail to realise that outsourcing storage and services to the cloud reduces one set of risks but increases another. From 2015 to 2017, the Swedish Government and its agencies suffered massive data breaches after moving data to the cloud. Not only were the details of most Swedish citizens leaked, foreign IT workers from Serbia, Romania and the Czech Republic were given varying access to the data - a clear breach of data sovereignty that risked national security.

1b. Access level security: keep your access credentials and access controls secure

Assuming that you understand the limits of the cloud-provided security, the next step is to keep your access credentials secure.

This sounds basic, but recent large scale data breaches at Deloitte, Accenture, Uber, and (more recently) the Australian Broadcasting Corporation (ABC), clearly show that insufficient security practices are in place.

In the ABC data breach, around 1,800 daily MySQL database backups were leaked, alongside emails and login credentials to other data repositories, from a poorly secured public-facing AWS S3 bucket.

Some basic tips are:

2a. Data level security: encrypt your data wherever possible

High quality encryption technologies, properly used, will deliver the highest levels of security for your data. Many security experts argue that using client-side encryption is the only way to safeguard data when it’s stored on other people’s infrastructure such as the cloud.

The beauty of encryption is that it can be an extremely effective last-line-of-defence that stops a security breach from becoming a data breach. Not only is encryption a good cyber-defence practice, it’s specifically referenced in the EU’s General Data Protection Regulation (GDPR). Article 32 (1)(a) of GDPR guidelines calls for the “pseudonymisation and encryption of personal data”, taking into account the state of the art and implementation costs.

When the Australian Red Cross Blood Bank leaked the personal details of 550,000 blood donors (including names, addresses and details of sexual behaviour) it was done from an unencrypted database backup. Had this backup been encrypted, the server misconfiguration would have resulted in a leak of encrypted data and not a full data breach. Under the rules of GDPR, a leak of encrypted data is unlikely to result in a risk to people’s rights and freedoms, and therefore does not need to be mandatorily reported.

However, because encryption is perhaps the most misunderstood area in cybersecurity, it is most often not implemented, or is implemented so poorly it is ineffective. Being a highly specialised field full of confusing acronyms and marketing hype, buyers (and even vendors) often fail to comprehend what security they’re actually getting. This frequently leads to the “tick the box” mentality where people don’t understand what they’re buying, but because it’s advertised as “military grade”, it must be good. This is of course, a logical fallacy, but reflects the situation that buyers often have little idea if they are purchasing real security or merely ‘snake oil’.

The ideal encryption system should meet a number of requirements:

2b. Take local backups of critical cloud data

The final procedure for security revolves around backup. If the cloud contains your only copy of important data, you run the risk of suffering permanent data loss, even if you think your cloud provider has been taking backups.

In 2014, SaaS provider Code Spaces and all of Code Spaces’ customers learnt that lesson the hard way. Code Spaces provided source code management tools such as Git to its customers – in effect the company was a “safe haven” and repository of data for its customers, offering what it advertised as a robust cloud service, fully backed up and with the security of being hosted on Amazon AWS.

However, a hacker managed to gain access into Code Spaces’ AWS control panel account, and subsequently started to cause chaos. After a melee with Code Spaces’ engineers and a failed ransom attempt, the hacker proceeded to delete all of Code Spaces’ AWS objects: S3 buckets, EC2 machine instances and all the backups. This led to permanent data loss, and without a local copy of the data, it subsequently put Code Spaces out of business. Worse still, their customers also faced permanent data loss, unless of course they were savvy enough to have kept their own backup of their data instead of relying on Code Spaces.

The lesson here is clear: ultimately, you are responsible for your own data. If you choose to delegate that responsibility, you will suffer the consequences if your provider gets hacked or otherwise fails to meet their obligations.

There are two ways in which you can backup your cloud data – to take a cloud-to-cloud backup, or a cloud-to-local backup. The former has some appeal, in that an organisation can be fully in the cloud without running any local infrastructure. However, as all of the examples of security breaches mentioned here has shown, hackers can and do regularly compromise access-level security, and when they do, they can cause permanent data loss.

The cloud-to-local backup option is more secure in that sense. If you regularly download your data to a local storage device such as a hard drive (of course, securely encrypted), and then air-gap that hard drive by disconnecting it and placing it in a safe or cabinet, it becomes immune from hacking. It’s simply a cheap, low-tech solution that’s better at preventing remote hacking attempts than the world’s most expensive firewall.

Conclusion

We’ve seen that there is no single magic pill for data security, and that migrating to the cloud is absolutely not a silver bullet. Despite the marketing hyperbole and mantras regarding how safe the cloud is, history clearly demonstrates that organisations must still take careful steps to safeguard their own data.

By breaking down security into four broad areas, and focusing on those areas, organisations can shore up their cybersecurity defences and use the cloud securely. Encryption and backup are two ways in which you can take responsibility and control for your data – because ultimately while you can delegate some level of system level security to the cloud provider, the data is always yours to take care of.

Especially now, with unprecedented levels of cybercrime and the May 2018 GDPR date just around the corner, it has never been more important to review all IT security practices and avoid becoming a statistic.

Linus Chang, CEO & founder, Scram Software
Image source: Shutterstock/Wright Studio