CHAPTER 4: SECURITY OF PROCESSING

Security is one of the most important safeguards in preventing harm to individuals, as reflected in Article 32 of the GDPR, which mandates “appropriate technical and organisational measures to ensure a level of security appropriate to the risk”.

Specifically, it requires organisations to identify and mitigate “risks that are presented by [data] processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed”. Such ‘appropriate’ measures may include:

‘Organisational’ security measures should always include attention to people and processes. Human error and process failures are regularly significant underlying causes for data breaches.⁸ The data protection liability, however, rests with the organisation.

Confidentiality, integrity and availability

The requirements in Article 32 of the GDPR to prevent unauthorised destruction, loss, alteration or access closely mirror the three standard aims of best-practice information security: confidentiality, integrity and availability.

Confidentiality is concerned with setting limits on who may have access to specified information, based on their need to know. In a personal data context, ‘need to know’ means that the data should only be processed for the purposes specified by the data controller to the data subject. As the Cloud provider is likely to not have any reason to even need access, data should be protected, e.g. by client-side encryption, before it even enters the Cloud provider’s physical infrastructure. Any breach of confidentiality in respect of personal data is likely to be unauthorised access, which the measures outlined in Article 32 should aim to prevent.

In maintaining confidentiality, it is unwise to rely on the probity, conscientiousness or common sense of all those who may handle or have access to data, even if they know the confidentiality boundaries.

Technical security measures to prevent unauthorised access should therefore be concerned with not merely preventing deliberate external intrusion; they should also aim to limit access by authorised users to just the information they actually ‘need to know’. Segmentation of data supported by a robust system of access credentials is one of the key controls in this respect.

Data integrity implies that once data has been entered into the system, it should not be modified in an unintended or unauthorised way. This is a very straightforward element of preventing “alteration” – which, if unauthorised or unintended, constitutes a data breach under the GDPR.

Availability relates to loss and destruction. The concept, however, goes beyond the permanent non-availability that would result from loss of data, to include the requirement for the information to be available whenever it is needed.

Data in transit and at rest

Data ‘in transit’ is always more vulnerable than data ‘at rest’. It is inherent in Cloud computing that data will spend more time in transit than it would if it were being processed on an in-house system. Processing personal data in the Cloud therefore automatically exposes it to greater risks than it would face behind securely run perimeter defences of an on-site installation.

That is not to say that the data faces no risks if held on site: it would still be vulnerable to misuse by authorised users, to loss or damage if the backup regime is inadequate, or to external intrusion. In some respects, the Cloud provider may actually offer greater protection against a backup failure or a poorly implemented firewall.

However, the IBM X-Force Threat Intelligence Index 2018 survey found that misconfigured Cloud servers were responsible for almost 70% of all compromised records tracked by X-Force in 2017.⁹ This included some extremely sensitive data, which was stored in the Cloud without the users’ knowledge.

There are also regular reports of large amounts of personal data being stolen from online locations. Websites are likely to be particularly vulnerable because, by their very nature, they are designed to have at least an element of public exposure. A website is often the gateway to a large online database of site users, and an integral part of an organisation’s relationship with its customers or service users.

Cloud applications that are not intended to be publicly accessible avoid one obvious avenue for compromise, but that does not make them immune to security risks. Intrusion is still a possibility. Technical problems could also cause a loss of integrity if the interruption occurs while data is in transit, and any loss or corruption of data is not detected and rectified.

Security in the Cloud

Security has to be present throughout, from the device through which the user accesses the application, to the depths of the Cloud provider’s system – for which the entire responsibility lies with the data controller. Normally, as discussed above, the data controller is the customer, with the Cloud provider acting as a data processor or third party.

It is emphatically not enough for the data controller to make assumptions about the security measures that may – or may not – have been taken by the Cloud provider. One clear example of this is the case of the British Pregnancy Advisory Service (BPAS). In February 2014, BPAS was fined £200,000 (about €230,000) by the UK’s ICO after its website was hacked.¹⁰ It is interesting to note that the BPAS considered the fine “out of proportion” at the time, although it is now well below the significantly higher maximum fines of the GDPR.

In the breach, highly confidential messages from almost 10,000 people, sent via the website to BPAS, were stolen – a task made relatively easy by basic security weaknesses on its website. This exploit was intended to undermine BPAS but could also have placed many of the individuals at considerable personal risk if, as was threatened, the messages had been made public by the criminal hacker.

In imposing the penalty, the ICO made it clear that it was the responsibility of BPAS to instruct the web designers and web hosts to implement adequate security, and check that they did so – not just to rely on the assumption that it would be done. BPAS failed to replace the default administrator password, therefore clearly not meeting its responsibilities as data controller, even though it felt the fine was “out of proportion”, as BPAS considered itself “a victim of a serious crime”. That may well have been the case, but – if anything – is even more reason to ensure the security of any processors and third parties it uses.

Additional risks from ‘bring your own device’ (BYOD) – or ‘application’ – policies

One of the clear benefits of Cloud computing is the possibility of easy (and cheap) access anywhere that you have an Internet connection. This is often an ideal solution for mobile workers, remote offices and home working. However, users may find reasons for wanting to gain access from personal devices rather than company ones, and the number of devices capable of gaining access has increased rapidly. Desktop computers, laptops, tablets and smartphones all bring their own risks.

It is not within the scope of this pocket guide to provide an exhaustive list of all the issues to address in a BYOD policy, but those particularly relevant to Cloud computing include:

Actions that can be taken to mitigate each of these risks are discussed in the next chapter.

Even where the data controller officially makes no use of Cloud applications, a BYOD policy must address the issue of whether the device owner is permitted to use personal Cloud-based accounts to transfer data to and from the device, or to work on material that is held on the device. Personal accounts, especially if they can be signed up to at no charge, may well not provide the same levels of security or service availability that business-oriented and paid-for accounts can offer. Surveys regularly suggest that this type of ‘shadow’ Cloud use is widespread. Where the data controller has corporate accounts with more secure applications, these should be used in preference.

The experience of Aberdeen City Council is instructive.¹¹ In 2011, a social worker was permitted to work from home. She had attended a case conference and was typing up the report on her home computer. She was apparently unaware that the folder in which she stored the document on her computer was set up to synchronise automatically with a Cloud-based location.

A colleague who had attended the same case conference happened to search for his name and job title on the web several months later, only to find that the document appeared. There was no security in place to prevent anyone accessing this highly confidential material.

The Council was fined £100,000, even though neither the computer nor the Cloud service was directly under its control. When the employee was authorised to work on confidential material at home, the Council should have ensured that appropriate security measures were in place.

⁸ The supervisory authority in the UK, the Information Commissioner’s Office (ICO), publishes quarterly figures of reported breaches at https://ico.org.uk/action-weve-taken/data-security-incident-trends, which show this pattern.

⁹ IBM, “IBM X-Force Threat Intelligence Index 2018 – Notable security events of 2017, and a look ahead”, March 2018, http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=77014377USEN.

¹⁰ BBC News, “Abortion provider BPAS fined £200,000 for data breach”, March 2014, www.bbc.co.uk/news/health-26479985.

¹¹ Warwick Ashford, “Aberdeen City Council gets £100,000 penalty for IT security failings”, Computer Weekly, August 2013, www.computerweekly.com/news/2240204497/Aberdeen-City-Council-gets-100000-penalty-for-IT-security-failings.