GDPR 101 — It’s All about the Data

With the General Data Protection Regulation (GDPR) taking effect in 2018, it seems that everyone is finally coming to the realization that they have to take it seriously. As I spend time talking to CISOs across the globe, there is a clear delineation between those who are in the EU and those who are outside of it. The EU CISOs are clearly focused on what solutions will help them solve GDPR security requirements. Everywhere else, CISOs are still grappling to understand what GDPR is and what needs to be done from a security perspective.

At the same time, a myriad of vendors have come up with a variety of GDPR approaches that are starting to rise to the top of PowerPoint and two-page data sheets. Hardware companies are talking about perimeter security and threat detection, while software companies are taking an “encrypt everything” approach. Although a solid perimeter and encryption are applicable in any proper security-conscious environment, what is that really telling you about the role that data security has to play within GDPR compliance initiatives?

What does GDPR actually mean for data?

The simple answer is: not much. To understand the required security for GDPR, let’s start by looking at the actual requirements:

Security – GDPR requires processors and controllers to take into account the “state of the art” and “implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk.” This includes risks that arise with the processing of information that could lead to “physical, material or non-material damage.”

Consent – User opt-in consent is the “new normal” under GDPR. Users (data subjects) must give clear consent for data controllers to collect and use their data. Data controllers and data processors are allowed to use the data subjects’ information solely for the purposes consented to. Data controllers can’t extend the use of a user’s data for more purposes than what they initially consented to. If data controllers ignore this, then the user can complain.

Notification – The local supervisory authority must be informed of any data loss within 72 hours, while users should be informed “as soon as possible.” This means there will be more data breaches that the affected users must be notified about, and each of these notifications should take place without delay.

Objection – Data subjects have the right to object to having their data processed for the purposes of marketing or profiling.

Erasure – Similar to the objection requirement, users have the right to be forgotten and have their information removed on demand. Any request for data to be deleted has to be complied with. Additionally, data should only be retained for the period that it is needed and then purged from all systems thereafter. According to the current understanding of the rules, this can include backup and archive copies of customer records.

Transfer – Transfers of data outside the EU should only be done if they are “necessary.” A transfer happens as soon as data leaves the current EU boundary of 28 countries, or goes outside any of the 11 countries that have “adequate” data protection mechanisms in place according to the EU requirements. If data has to be transferred outside the EU or the “adequate” countries, contracts that enforce data protection requirements must be in place down the chain.

The unifying theme throughout the GDPR requirements is the security of data. Organizations can effectively meet those requirements only if they can answer these three questions:

To ensure proper data mapping, does my organization have visibility as to where all our data lives?Can my organization protect and secure that data, so that our data processors and their subcontractors do not have access to it?Can my organization proactively apply policy to that data in all the places that it lives, up to and including data erasure?

What should business teams be doing, beyond what IT does?

In order to secure something, you have to be able to see it. This visibility comes from knowing where that asset lives, as well as all the authorized and unauthorized copies of that asset data. In legacy data center environments, that visibility was fairly simple to maintain.

Previously, when organizations deployed three-tier web apps with databases and storage, administrators could walk into their data center, go up to a massive Storage Area Network (SAN), and point to their data. Today, with the proliferation of Software as a Service (SaaS) applications and mobile edge devices that are constantly creating data, knowing where your data lives and understanding your overall data attack surface becomes very complex.

In order to solve this problem, organizations need to proactively collect information from all their IT assets — including fixed desktops and servers as well as mobile endpoints, — and external cloud services. Once you start collecting this data from every asset, it has to be stored in an environment that scales on demand, preferably with a palatable and predictable cost model. To date, the only platform that meets that requirement is the cloud.

As more line-of-business applications move into the cloud — and more users access their cloud apps from their phones or tablets as well as endpoint PCs — the spread of data represents a bigger risk. For long-term compliance with GDPR, it will be essential for an organization to be able to successfully track such data as it spreads so that the data can be protected and adequate records of where customer data is stored can be compiled. Cloud-based services can help an organization build these records and automatically keep them up to date, whereas internal platforms cannot.

Technology requirements

Given the current data explosion and scalability requirements, storing data in the cloud can be scary for organizations that have not used security and continuity services previously. A simple solution would be encryption, which is the only specific technology that the GDPR recommends in Article 32. What does that entail?

If you are moving data from endpoints and servers to the cloud, it has to be encrypted in flight via TLS or IPsec, and then the encrypted data must be stored using AES. But who controls the data keys? Your organization (rather than the cloud provider or the security product vendor) should maintain control of all your data, as well as any encryption of that data and the corresponding encryption keys to ensure no third party can access the information without authorization. This also ensures that third-party vendors can’t be forced to divulge the keys when the organization is not involved, because they won’t have access to or knowledge of those keys in the first place.

However, it’s not good enough to simply encrypt data and claim GDPR compliance. When data is stored encrypted in the cloud, organizations still need to have visibility into that data in order to respond to requests from EU citizens as well as EU authorities. Visibility into data is also required for export, transfer, and erasure requests.

Bringing it all together

From a security perspective, GDPR is mainly focused on the protection of the EU citizens’ data records and the application of best practices regarding data privacy and security by any organization, anywhere in the world, that processes these records. Whatever approach your organization takes to comply with GDPR, it’s critical to start with the data security requirements and work up from there. While there may be a lot of chatter about solutions and services that are available to help, there won’t be a single solution that will address all of your GDPR compliance needs. If you just focus on the data and then work on the right processes for handling that data securely, everything else will fall into place.