+1.800.357.1019

+1.800.357.1019

Feel free to call us toll free at +1.800.357.1019.

If you are in the area you can reach us at +1.360.359.4400.

Standard support
6:30am - 4:00pm PST, Monday - Friday, Free

Premium support
If you own Townsend Security 24x7 support and
have a production down issue outside normal
business hours, please call +1.800.349.0711
and the on-call person will be notified.

International customers, please dial +1.757.278.1926.

Townsend Security Data Privacy Blog

GDPR - Do I have to Use Encryption?

Posted by Patrick Townsend on Apr 24, 2018 8:44:17 AM

As the date for the formal implementation of the EU General Data Protection Regulation draws near, many of our customers are struggling with the question of whether or not they have to encrypt sensitive data. Because the fines for violating the GDPR can be quite high, this question is taking on a growing urgency. So, let’s take a look at this question in more detail by looking at the actual GDPR source documents.

Download the EU Data Privacy White PaperThe most relevant part of the GDPR regulation related to encryption is Article 32 - “Security of Processing”. The actual text of the article is very readable and you can find a link in the Resources section below. Here is an extract from Article 32 (emphasis added):

“Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:

  1. the pseudonymisation and encryption of personal data;
  2. the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
  3. the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;
  4. a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.”

Well, it looks like we don’t really have to encrypt the sensitive data because we get to take into account the costs of the implementation and the nature, scope, context and purpose for processing. Along with some other potentially mitigating factors. If you read no further you might draw the conclusion that encryption is a recommendation, but it is not a requirements. Question answered, right?

Not so fast. Let’s dig deeper. The next point in Article 32 shines a brighter light on this question:

“2. In assessing the appropriate level of security account shall be taken in particular of the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed.”

In effect the GDPR is saying that your security controls must account for the risk of accidental, unlawful, or unauthorized disclosure or loss of personal data. That is a very broad category of potential violations of the protection of an individual’s data. Have you ever lost a backup cartridge? Do you really think your systems are secure enough to prevent access by sophisticated cyber criminals?

While on first look it seems that we have some leeway related to the deployment of encryption, GDPR quickly raises the bar on this question. Given the current state of security of data processing systems, no security professional should be absolutely comfortable with the security of their systems.

If you are still thinking you can avoid encrypting sensitive data, be sure to take a read of Recital 78, “Appropriate technical and organisational measures”.

It should be clear by now that if you decide NOT to encrypt sensitive data you should definitely document all of the reasons it is not feasible or practical to do so, and all of the measures you are actually taking to protect that data. Put this in writing and get senior management sign-off on your conclusions.

But there is more.

If you are wondering how serious GDPR is about encryption, be sure to read Recital 83 “Security of processing”. Here is an extract with emphasis added:

“In order to maintain security and to prevent processing in infringement of this Regulation, the controller or processor should evaluate the risks inherent in the processing and implement measures to mitigate those risks, such as encryption. Those measures should ensure an appropriate level of security, including confidentiality, taking into account the state of the art and the costs of implementation in relation to the risks and the nature of the personal data to be protected. In assessing data security risk, consideration should be given to the risks that are presented by personal data processing, such as accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed which may in particular lead to physical, material or non-material damage.

If you are getting the notion that the authors of the GDPR really want you to encrypt sensitive data, you would be right.

Where else does encryption come into play?

There are safe-harbors in GDPR around data breach notification IF you are encrypting sensitive data. The avoidance of notification is not absolute, but here is one relevant section of Article 34, “Communication of a personal data breach to the data subject” (emphasis added):

The communication to the data subject referred to in paragraph 1 shall not be required if any of the following conditions are met:

  1. the controller has implemented appropriate technical and organisational protection measures, and those measures were applied to the personal data affected by the personal data breach, in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption;

If the sensitive data of a data subject is lost and not encrypted, it will be difficult to argue that the information is inaccessible. The loss of unencrypted data will certainly require notification to the supervisory authority and the data subject.

There is one more aspect to the discussion of encryption and that relates to the management of encryption keys. Your encryption strategy is only as good as your ability to protect your encryption keys. This is reflected in Recital 85 “Notification obligation of breaches to the supervisory authority” (emphasis added):

“A personal data breach may, if not addressed in an appropriate and timely manner, result in physical, material or non-material damage to natural persons such as loss of control over their personal data or limitation of their rights, discrimination, identity theft or fraud, financial loss, unauthorised reversal of pseudonymisation, damage to reputation, loss of confidentiality of personal data protected by professional secrecy or any other significant economic or social disadvantage to the natural person concerned. Therefore, as soon as the controller becomes aware that a personal data breach has occurred, the controller should notify the personal data breach to the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless the controller is able to demonstrate, in accordance with the accountability principle, that the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where such notification cannot be achieved within 72 hours, the reasons for the delay should accompany the notification and information may be provided in phases without undue further delay.”

If you are not properly protecting the encryption key used for encryption, it must be assumed that the encryption can be reversed. Don’t use weak encryption keys such as passwords, don’t store encryption keys in files or in application code. Instead, use a professional key management solution to protect the keys.

Returning to our original question about the need for encryption of sensitive data, I hope you have arrived at Yes as the most responsible answer. The loss of unencrypted sensitive data will definitely trigger the need for data breach notification. And the improper protection of encryption keys will also trigger the need for breach notification. You are at more risk of financial penalties if you are not properly protecting that sensitive information with encryption.

The GDPR is complex and some parts are subject to interpretation. But if you control or process sensitive data you should not underestimate the serious intent of the GDPR to enforce protections for individuals. GDPR is revolutionary and disruptive - it is dangerous to ignore it.

Patrick



Resources
The General Data Protection Regulation (GDPR)
The GDPR Recitals
GDPR Article 32 “Security of Processing"
Recital 78, “Appropriate technical and organisational measures”
Recital 83, “Security of processing”
GDPR Article 34, “Communication of a personal data breach to the data subject”
Recital 85 “Notification obligation of breaches to the supervisory authority”

EU Data Privacy Protections and Encryption

Topics: EU GDPR, Enryption

GDPR, Right of Erasure (Right to be Forgotten), and Encryption Key Management

Posted by Patrick Townsend on Jan 22, 2018 11:11:28 AM

Download the EU Data Privacy White PaperThe European General Data Protection Regulation (GDPR) is a radical and transforming event in the information technology space. Due to go into full effect on May 25, 2018, it will require major changes to IT systems and they way organizations relate to their customers, employees, and external partners. It is hard to overstate the the impact of the regulation. Organizations of all sizes and types, and cloud service providers small and large, must adjust to the notion that people now fully own information about themselves - and companies outside of the EU zone are impacted, too.

Article 17 of the GDPR focuses on the “Right of erasure”, also known as the “Right to be forgotten”. Here is a link to that section.

Let’s talk about how we can use encryption and key management to help meet the requirements of the legislation. Since deploying encryption will also help meet the privacy requirements of GDPR, the same technology can be used to implement Right of Erasure.

First, let’s look at the technology landscape related to encryption:

Encryption is one of the most well understood mechanisms for data privacy. There are well-established, mature standards for encryption and the related key management technologies. Most companies will use encryption to meet GDPR privacy requirements, and will be deploying encryption key management to protect the keys. There are mature encryption technology solutions available on all major enterprise operating systems and on all major cloud platforms. Protecting encryption keys is also well understood. Many organizations have already deployed encryption in some parts of their organizations, and GDPR will speed this process and extend protections across all parts of the data landscape.

The hardest part of getting encryption right has to do with creating, protecting, and deploying encryption keys. It is probably the hardest part of getting an encryption strategy right - and there are a lot of ways to get key management wrong:

  • Storing the unprotected encryption key with the protected data
  • Using weak protection methods to secure encryption keys
  • Storing the encryption key directly in application code
  • Using a weak encryption key - a password is an example of a weak key
  • Not using strong, industry standard methods of generating an encryption key
  • Not providing separation of duties and dual control around key management

There are lots of ways to get encryption key management wrong - and bad key management practices will result in GDPR compliance failures.

Fortunately, it is fairly easy to deploy good encryption key management that is affordable, easy to install and configure, and easy to integrate with your encryption strategy. A number of professional key management solutions are available to serve every enterprise operating environment. We have one (Alliance Key Manager), and others are available.

Now that we have a good encryption and key management strategy in place, let’s use it to meet the GDPR Right to Erasure.

Under GDPR Article 17 a need to erase personal information can be triggered by a number of events:

  • A Data Subject (usually a person) can request erasure of personal information
  • The personal information is no longer relevant from a business perspective
  • A Data Subject withdraws consent and there is no overriding need or requirement to retain the data
  • A Data Subject withdraws consent for processing their information
  • Personal data has been unlawfully obtained or processed

That covers a lot of ground! It is not as simple as just responding to a request for erasure, we have to be aware of our actual need for information. And erasure triggers some secondary requirements:

  • The Data Controller must attempt to remove data that has been made publicly available
  • The Data Controller must inform third party Data Processors of the need to erase data

We have a lot of responsibilities under GDPR Article 17. How can we use encryption and key management to meet this requirement?

A key management approach:

Imagine that you assign a unique encryption key to each Data Subject (employee, customer, and so forth) and that you encrypt that person’s personal data in your databases with that unique and specific key. The time comes when must meet your obligations under Right of Erasure. Rather than go through every database table and storage server to delete the data, you could just delete the encryption key. Assuming you have strong encryption keys and industry standard key deletion processes, the deletion of the key is an effective way to zero the protected data without actually modifying the database. Data that is encrypted is unrecoverable if the key is no longer available.

There is one more added benefit to this approach - it effectively erases all of the data on your backups! Managing compliance with GDPR is especially difficult when it comes to off site backups of sensitive data. The ability to effectively erase data by erasing the encryption key without having to pull those backups out of storage is a huge cost and administrative saving!

The strategy described above is only defensible if you are encrypting the Data Subject’s information, if you are assigning them a unique encryption key, and if you are using an encryption key management solution that provably meets industry standards for key zeroization. Our key management solution does and you can get more information here.

We’ve touched just one aspect of GDPR. We will be talking more about GDPR in the days ahead.

Patrick

EU Data Privacy Protections and Encryption

Topics: Compliance, EU GDPR

What Does the EU General Data Protection Regulation (GDPR) Mean to You?

Posted by Patrick Townsend on May 4, 2016 1:58:00 PM

The new European Union General Data Protection Regulation (EU GDPR) has now passed both the EU Council and Parliament and replaces the earlier Data Protection Directive (Directive 94/46/EC). Unlike an EU directive, this regulation does not require individual countries to pass legislation and it goes into effect immediately. Organizations have a two-year transition period to comply with the new data protection regulations, but it would be unwise to delay. Smart organizations will start work immediately so that there are no gaps upon the arrival of the deadline, and so that their public reputation is preserved. A good overview of the regulation can be found here and it contains a link to the full regulation.

eBook The Encryption GuideThere are many aspects to the new GDPR, and if you are required to meet the regulation you should take a very close look at the entire publication. Let’s look at a few of the elements of the GDPR with a focus on data protection.

What information must be protected?

The regulation uses two terms that are important to understand. The term “data subject” means an individual person. The term “personal data” means any data that either directly identifies an individual person, or which can be used indirectly to identify an individual. A few examples of data that indirectly identify an individual would include a medical identification number, location data such as an IP address, or social identity such as an email address or Facebook account.

The definition of personal information is quite broad. It would be a mistake to narrowly focus on just a few fields of data in your database, you should look for all information about a person that you store. If any information uniquely identifies a person, or if information can be combined to identify a person, it should be protected.

What constitutes a data breach?

The definition of a data breach is much broader than defined in the US. It certainly includes the the accidental loss of data or the loss of data in the course of a data breach by cybercriminals. But it also includes other activities including the accidental or unlawful:

  • Destruction of personal information.
  • Alteration of personal information.
  • Unauthorized disclosure of information, even without criminal intent.
  • Access to personal information.

In other words, assume that the data you store about an individual belongs to them exclusively, and is valuable. You are holding it in trust, and you have a fundamental responsibility to preserve and protect that information! This will be a conceptual challenge for organizations more familiar with US data protection rules.

Non-EU organizations should pay special attention to this definition of a data breach. It goes far beyond what typical regulations in the US define as a data breach.

What are my breach notification requirements?

The data breach definition applies to all personal information that is transmitted (data in motion) or stored (data at rest) or in any other way processed by your organization. In the event you experience a data breach you must notify the appropriate authorities and the individuals who are affected. There are stringent time constraints on the notification requirements and this will require special preparation to meet those requirements.

Important note: If your data is encrypted you may be exempt from some notification requirements (from Article 32):

The communication of a personal data breach to the data subject shall not be required
if the controller demonstrates to the satisfaction of the supervisory authority that it has implemented appropriate technological protection measures, and that those
measures were applied to the data concerned by the personal data breach. Such
technological protection measures shall render the data unintelligible to any person
who is not authorised to access it.

Who is covered by the regulation?

The GDPR uses the special term “Controller” for an organization that transmits, stores, or processes personal information. You are a Controller of personal information if in any way you transmit, store or process personal information. This applies in equal measure to service organizations that receive personal information in a secondary capacity.

The GDPR also uses the special term “Processor”. You are a Processor if personal information flows through a system that you control. This applies to information you provide to other organizations and to third party computing service providers such as cloud service providers (CSPs).

Are non-EU organizations covered by the EU GDPR?

Yes, if you are located outside of the EU but are doing business in the EU or operating in the EU (you are a controller or processor of personal information of EU citizens), you fall under the requirements of the EU GDPR. This will surprise many organizations who do not have offices or employees located in the EU zone.

Are there any special categories for protection?

The EU General Data Protection Regulation establishes some special categories of individuals and information that come in for additional controls. Information about children and the information of medical patients require special attention on the part of organizations who process this type of information.

What are the penalties for non-compliance with data protection requirements?

While there is some flexibility in how fines are levied for unintentional non-compliance to the GDPR and depends somewhat on which rules you are out of compliance with, the penalties can be quite severe. The failure to protect sensitive data with encryption with appropriate technical controls is considered a severe violation. No one should ignore the potential impact of these fines. For example, an enterprise that fails to protect data can be subject to fines of up to 1,000,000 EUR (1 Million Euro) or up to 2 percent of annual worldwide revenue. You can see why this new regulation is getting a lot of attention in the European Union!

See Article 79 of the GDPR for more information about fines and penalties:

Is encryption a mandate?

This is from the GDPR recitals:

(23) The principles of protection should apply to any information concerning an identified
or identifiable person. To determine whether a person is identifiable, account should
be taken of all the means likely reasonably to be used either by the controller or by any
other person to identify the individual. The principles of data protection should not
apply to data rendered anonymous in such a way that the data subject is no longer
Identifiable.

The most common way of making data anonymous is encryption with good encryption key management.

And you should know this from Article 30 of the GDPR:

1. The controller and the processor shall implement appropriate technical and
organisational measures to ensure a level of security appropriate to the risks
represented by the processing and the nature of the personal data to be protected,
having regard to the state of the art and the costs of their implementation.

2. The controller and the processor shall, following an evaluation of the risks, take the
measures referred to in paragraph 1 to protect personal data against accidental or
unlawful destruction or accidental loss and to prevent any unlawful forms of
processing, in particular any unauthorised disclosure, dissemination or access, or
alteration of personal data.

It is likely that in almost all cases the only appropriate technical measure to ensure anonymization and security appropriate to the risk of loss is encryption with appropriate key management controls. When encryption is not specifically required we sometimes call this a “backdoor” mandate - you are not required to implement encryption, but in the context of a data breach anything else will be deemed inadequate, and subject the organization to fines. You don’t want that to happen to you.

I hope this helps you understand the basic data protection requirements of the new EU General Data Protection Regulation. I know that the regulation is complex and there remain some ambiguities. In future blog posts I will go into more detail on various aspects of the GDPR and how our solutions at Townsend Security are helping EU organizations meet the data protection requirements.

The Encryption Guide eBook

Topics: EU Data Privacy Protection, EU GDPR

 

 

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all