Archive for August, 2017

A Deeper Dive Into GDPR: Breach Notification

Thursday, August 31st, 2017

In this instalment of GDPR Deeper Dive – Breach NotificationA Deeper Dive, let’s take a look at GDPR’s breach notification requirements. The old adage applies when it comes to security breaches, an ounce of prevention is worth a pound of cure. No organisation wants to be the victim of a data breach. The aftermath costs exorbitant amounts of money and has immeasurable affects to your reputation, not to mention the fact that it causes real damage to the individuals whose data was compromised. Yet, breaches happen every day. 2016 saw 1,792 reported breach incidents worldwide that exposed over 1.3 million records.

GDPR’s stance on this is clear. If you’re breached and it risks the rights and freedoms of those whose data is affected, your organisation will be responsible for notifying both the supervisory authority for your region, and the affected data subjects. Article 33 (Notification of a personal data breach to the supervisory authority) lays out this requirement. It states:

“1. In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.”

In short, in the event of a breach, the victimised organisation will have to notify their regulator within 72 hours. At first glance, this may seem a cut and dry requirement. However, the requirement isn’t absolute. The notification obligation is triggered only if the data breach jeopardises the subjects’ rights and freedoms. The following article (number 34) entitled ‘Communication of a personal data breach to the data subject’ goes further in describing the exemption starting in sub-point 3 which states:

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

(a) 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;”

In short, the combination of these two articles says that organisations can avoid their notification obligations – to both regulators and the data subjects – by adopting encryption and enterprise key management to keep their customers’ data safe.

To understand why encryption plays this role, we again return to its fundamental nature; it attaches security to the data itself. Only those that have access to the appropriate encryption key can read data in clear text. So, when a breach occurs, encrypted personal data will remain protected and unreadable to unauthorised users, rendering it unlikely that the rights and freedoms of those affected will be at risk.

Part of the challenge, though, will be in demonstrating to the appropriate regulatory bodies that, in the face of the data breach, these risks are unlikely. As the crux to any encryption deployment, the key manager will be the tool that lets organisations show minimised risk. Best practice dictates that key material should be stored separately from both where encryption takes place and where encrypted data is stored. The same key management functions that establish an organisation’s data control will be the ones that demonstrate to regulators that breached data is unusable and poses no risk to the subjects. (For more on this see last week’s post on GDPR’s data integrity and control requirements.) Since decrypting data requires a key, monitoring and recording who accesses the keys and how they are used gives a complete map of access to the data. Storing and managing those keys separately in a secure external key management appliance, centralises that oversight – with only one way in and out of the key management appliance, the corresponding logs serve as demonstrable proof that only authorised users accessed the keys, and consequently could access the data. In the event of a breach, a hacker or privileged user may abscond with encrypted data, but with proper key management in place, they won’t be able to use it for their gain. Without the corresponding key, it is highly unlikely, or even virtually impossible, that the data will ever be readable thus protecting the rights and the freedoms of the individuals concerned.

In this way, organisations can avoid GDPR’s breach notification requirements.

Encryption not only insulates organisations from the damage a data breach causes, it also helps them preserve their reputation in the eyes of their customers and the general public. Data breaches are more common than we like to admit and they affect organisations large and small – public and private. GDPR won’t let organisations off the hook. If an organisation is breached and the appropriate safeguards aren’t in place, then they will have to tell regulators and the world that they were unprepared. And, these consequences don’t even take into account the impending fines they will surely face. Fortunately, solutions are out there to mitigate those risks so no organisation should have to bear the indignity of that mea culpa.

Much like data integrity and control, breach notification is still only one piece of the larger GDPR story. Next week we’ll take a look at GDPR’s expectations around risk mitigation and due diligence for collaborative contractual relationships. Stay tuned!

Do you understand GDPR Compliance? Read The General Data Protection Regulation ebook.

View the original article by Gemalto.

A deeper dive into GDPR: Data Control

Thursday, August 24th, 2017

Last week we covered GDPR’s ‘Right to Be Forgotten’ – a subject that has been grabbing a lot of the GDPR related headlines lately. Perhaps overshadowed however has been much of GDPR’s core data requirements which focus on data control. These control requirements appear across a number of the mandate’s articles. However, Article 5 entitled “Principles relating to the processing of personal data” contains the bulk of the requirement. Edited to include the relevant sub-points, Article 5 states:

1. Personal data shall be:

(b) collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’);

(d) accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay (‘accuracy’); laying down a procedure for the provision of information in the field of technical regulations and of rules on Information Society services (OJ L 241, 17.9.2015, p. 1).

(e) kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) subject to implementation of the appropriate technical and organisational measures required by this Regulation in order to safeguard the rights and freedoms of the data subject (‘storage limitation’);

(f) processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’).”

Let’s translate this into plain language and break it down point by point to see what’s at stake. In essence, Article 5 says data:

(b) can only be processed for the reasons it was collected.

(d) must be accurate and kept up-to-date or else should be otherwise erased

(e) must be stored such that a subject is identifiable no longer than necessary

(f) must be processed securely.

Each of these requirements presents their own unique challenges. So, how does an organisation concerned about their data’s privacy meet all of these requirements simultaneously?

Encryption and key management, which by design attaches security directly to the data itself, gives organisations the level of data control that GDPR asks. Ultimately, with encryption, only key holders are capable of accessing data; the manner – both technically and organisationally – by which organisations restrict encryption key access will ultimately determine access to cleartext data. Many encryption solutions include policy-based access controls that layer with standard encryption/key management functionality to more finely restrict key access and consequently data according to roles, responsibilities, and/or context. Such controls, for example, could make sensitive information such as social security numbers only available at certain times of the day to specific applications using a defined set of rules and credentials. Such an approach minimises the time that subject information is exposed in clear text to comply with subsection e (that it must be stored such that a subject is identifiable no longer than necessary). When it is a question of securing the data during processing, format preserving encryption solutions can keep data secure while in use by the application without ever exposing the subject’s identity to satisfy subsection f (that it must be processed securely).

With this basic understanding in mind, the general GDPR picture becomes clearer. Encryption allows organisations to decide who or what accesses data, when they access it, and how. The byproduct of deciding the who, what, when, where and why is clear and transparent oversight of the data which in turn is the method by which administrators assure its integrity. Restricting data access ensures that the only modifications made to data are authorised ones. By controlling access to the key and monitoring its use, organisations know about all changes to the data, and more importantly, have a verifiable record for regulators. Emerging trends suggest that instead of simply stealing data hackers are now surreptitiously altering data and profiting from the disruption it causes. Why steal data when one can manipulate companies to then profit by trading legally on the stock market? Encryption prevents such secret manipulation to preserve data’s integrity in compliance with subsection d (that it must be accurate and kept up-to-date or else should be otherwise erased).

GDPR goes on to further mandate in Article 32, section 4 that “The controller and processor shall take steps to ensure that any natural person acting under the authority of the controller or the processor who has access to personal data does not process them except on instructions from the controller, unless he or she is required to do so by Union or Member State law.”

Whereas Article 5 outlines larger control principles, Article 32 gets into the types of relationships that organisations deal with in their day-to-day operations. For many data transfers are a regular part of business; those transfers can vary widely from internal collaboration across units to external partnerships with suppliers. In such instances, how can an organisation ensure that data transfer recipients – or even administrators responsible for core operations – only process data when permissible? Here encryption and key management saves the day again. Administrators can simply provide the encryption key when along with their clear instructions when data processing should begin. Until that point, data processors – whether internal or external – to the organisation won’t be able to proceed in using the data.

Alternatively, administrators could tie instructions to access control policies. Once instructions were given to the data processor, administrators could change the policy tied to a data set or a key so that the processor could proceed with their operations. For example, an organisation could set a policy defining a date, time and/or authorised user to assure that a partner processes their data only when instructed to do so.

The approaches here are flexible and can be determined based on whether the organisation wants to grant the key outright or just temporary access to the key. These straightforward methods work across the board and can apply wherever the data is located to comply both with Article 32 and Article 5 (b) (that data only be processed for the reasons it was collected).

Clear, verifiable data control is the common theme across all of these requirements. Encryption’s beauty is the simplicity of its approach. Security attaches directly to the data itself. It doesn’t matter if that data is backed up to the cloud or replicated to another data centre, only the appropriate key holder will be able to access it. It doesn’t matter if hackers bypass network perimeters or if administrators with privileged rights access sensitive systems, encryption can keep data safe. It makes sense, if an organisation is to protect their data’s privacy over an ever expanding global footprint while hacks and breaches are publicised daily, then they need to be in control of their data no matter the circumstances. That’s it for this week. Next week we’ll explore GDPR’s breach notification obligations and what you can do to protect yourself and your customers from breaches, fines and the public embarrassment that often accompanies them.

Need to learn more about GDPR Compliance? Check out The General Data Protection Regulation ebook.

View the original article by Gemalto.

A deeper dive into GDPR: Right to be forgotten?

Thursday, August 17th, 2017

Last week we went over the GDPR A Deeper Dive – 2changes that set GDPR apart from other mandates and data privacy legislation. One aspect of GDPR that has received a lot of attention is the ‘Right to be Forgotten’ which is outlined in Article 17 entitled “Right to Erasure (’right to be forgotten’)”. It states:

“The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies:

(a) the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed;
(b) the data subject withdraws consent on which the processing is based according to point (a) of Article 6(1), or point (a) of Article 9(2), and where there is no other legal ground for the processing;
(c) the data subject objects to the processing pursuant to Article 21(1) and there are no overriding legitimate grounds for the processing, or the data subject objects to the processing pursuant to Article 21(2);
(d) the personal data have been unlawfully processed;
(e) the personal data have to be erased for compliance with a legal obligation in Union or Member State law to which the controller is subject;
(f) the personal data have been collected in relation to the offer of information society services referred to in Article 8(1).”

In plain English this means that organisations need to fully erase a subject’s data from all repositories when that person revokes their consent; when the purpose for which the data was collected is complete; or when compelled by the law.

It is worth noting that this is not an absolute requirement and subjects do not have an unconditional right to be ‘forgotten’. If there are other legitimate, legal reasons – as outlined in the regulation – for the organisation to retain and process data, subjects are not entitled to be forgotten. However, exceptions are few compared to the multitude of data uses common in our daily lives.

So, in the spirit of GDPR, how do organisations ensure that data is deleted from all of the places that it is stored or processed? Full data erasure isn’t a straight forward proposition. Using a standard delete function doesn’t always fully remove data. While it may not appear in file registries or indexes, deleted data is often still recoverable. In these instances, despite best efforts, simply hitting ‘delete’ doesn’t achieve GDPR compliance. To complicate the issue, in 21st century business data is shared constantly between suppliers, partners, resellers and customers. When consent is revoked or a contract comes to term, how does an organisation guarantee that data is adequately deleted by all of these different players?

Encryption is one way to fully ensure that data is unusable per GDPR’s erasure obligation. Encryption alters data by using a specific secret – or key defined by an algorithm – to render data unreadable. The only way to return encrypted data into a readable state is by providing the corresponding key that was used to alter the data in the first place. If that key were to be deleted, it would be impossible to convert or decrypt that data back into a readable format. When it comes to GDPR’s ‘right to be forgotten’ encrypting data and deleting the key (also known as cryptographically erasing the data) is both an effective and convenient solution.

Such an approach gives organisations quite a bit of flexibility in deciding how to meet this obligation. Encryption is the kind of tool that organisations can apply at different levels of the data’s flow from creation to rest. If it were as simple as deleting a file, an organisation could use a file system-level solution to encrypt the file and delete the key. On a larger scale, say at the end of a project, an organisation could encrypt an entire database column – say of social security numbers, usernames, or family names – and delete the key. More advanced developers could even incorporate encryption into their applications and then delete the keys that the application uses. In any scenario, policy-based access controls allow organisations to finely tune their approach to data deletion for greater confidence in their approach to GDPR compliance. The permutations are many, but the fundamentals are the same.

As organisations consider their GDPR needs, they should place them in the context of their larger security needs. Adopting one-off encryption solutions to address discrete challenges is the quickest way to end up with a collection of burdensome security silos that complicate on-going management. Encryption is the tool that works on the data, but an organisation’s key management apparatus will eventually be the key (pun fully intended) to future security and compliance success. In choosing an encryption and key management vendor, organisations should consider the solutions currently in place in their data centre, their existing needs, and their future needs in order to find a solution set that will grow with them.

The ‘right to be forgotten’ isn’t as daunting a requirement as it may seem at first glance. A thoughtful use of encryption can help organisations respect data subjects’ wishes and preserve privacy in any scenario. Next week we’ll return to the pages of this blog to take a look at GDPR’s data control and integrity requirements. Stay tuned!

For additional information on GDPR, check out The General Data Protection Regulation ebook.

View original article by Gemalto.

A deeper dive into GDPR: What makes it different?

Thursday, August 10th, 2017

Taking place in May 2018, the Data Protection Regulation also known as GDPR sets a new standard for data privacy and security across the European Union (EU). Much has been made of the law establishing data privacy as a fundamental right, and its governance and security requirements.

Over the course of the next few weeks, we will be taking an in-depth look at the mandate’s articles and offering insight into how you can comply.

Today let’s take a look at what sets GDPR apart from other standards and regulations, namely its expanded scope and reach.

GDPR will affect any organization that offers goods or services, or whose activity monitors the behaviour of individuals in the EU; it doesn’t matter if the organization resides and processes data within the EU or not. Multi-national organizations across the world – from Australia to the United States – that collect EU subjects’ data will need to prepare for the new mandate. Additionally, as organizations collaborate and partner, GDPR holds them responsible for their data’s privacy even as it passes outside of their control. In effect, GDPR increases the number of stakeholders involved and the level of due diligence each party must perform to what can already be a complex web of relationships that span the globe.

What is more, GDPR broadens the definition of ‘personal data’. Any piece of information that can be combined with another data point (or collection of data points) to identify an individual must be protected following GDPR’s mandates. Such a broad definition includes pieces of information such as online identifiers, genetic data or location metadata – data that organizations are unaccustomed to protecting. This will certainly impact how organizations protect their data currently and will affect how they do business while protecting this data going forward.

For all of this data, GDPR asks that protection is by design as a default; that is data privacy must be a consideration from the moment an operation is conceived. Security in service of privacy must be incorporated into the very fabric and design of an organization and its operations as the default setting. Under GDPR, security is no longer an option; it is a requirement.

GDPR’s penalties are severe. In the event of a breach, organizations will be required to notify both the supervisory authority in their jurisdiction and the customers whose data was affected. And, when breached data poses a risk to data subjects’ privacy, organizations will be subject to fines that have the potential to rise to as high as €20 million or 4% of annual worldwide profit – whichever is greater.

The new penalty regime fundamentally changes the data security cost/benefit equation for any organization with a presence – real or virtual – in the EU.

For as daunting as it may seem, you won’t have to face it alone. On this blog, we’ve already shared how to break the process into manageable chunks via our 6 step approach to tackling GDPR. Our experts go into these 6 steps – in partnership with ISC2 – in a joint webinar entitled “6 Steps To GDPR Compliance”. Over the next few weeks, we’ll dig deeper into topics such as the ‘Right to be Forgotten’, data integrity obligations, due diligence requirements, and more. Stay tuned to this blog each week for a new instalment in our GDPR series.

That said, if you’re anxious to get started on your GDPR preparation, you can find more information, white papers and ebooks on GDPR compliance here:

View original article.

GDPR Compliance in Six Steps

Monday, August 7th, 2017

In less than a year’s time, a radical change to data protection and legislation will come into effect in the EU – the General Data Protection Regulation (GDPR). Aiming to help protect EU citizens’ data, the regulation will ensure that businesses are held accountable to their customers. While companies in the US must declare any data breaches they experience, the same can’t be said for businesses operating within the EU until GDPR comes into effect and changes this. In short, this means the already large number of records lost or stolen in Europe could be considerably larger.

With GDPR almost here, the data protection and privacy landscape of the EU is set to change in big ways. But how can a business ensure that it is compliant with the regulation, and how would they go about becoming compliant? Below are six steps every business should undertake:

Step one – Get to grips with GDPR’s legal framework

The first step that any business needs to take is to understand how each aspect of the legislation apply to them. By conducting a full audit against the GDPR legal framework, a business will need to understand what it needs to do and what the consequences for failing to do so are. As part of this compliance audit, a business should hire a Data Protection Officer (DPO), who will be responsible for ensuring the company adheres to the regulations. Ideally, a DPO would have a background in both law and technology, so they’re able to understand both the technical specifications and the regulatory framework needed to meet this. Every organisation is different, and so no GDPR journey will look the same – correct guidance from business leaders to employees is needed ensure the whole company understands how to be compliant.

Step two – Create a Data Register

Once a business understands the steps they need to take, it’s important that they keep a record of the process. This is best done with a Data Register – essentially a GDPR diary. The Data Protection Association (DPA) of each country will enforce GDPR, and be responsible for judging if a business is compliant when determining any penalties for being breached. In this event, the Data Register will be a crucial tool for demonstrating the progress the affected business has made in becoming compliant. If they have no proof, the DPA would be able to fine between 2% and 4% of the company’s turnover. The amount and speed of the DPA’s decision would depend on the sensitivity of the data.

Step three – Classify data

While understanding what protections, if any, are already in place is important, this step focuses on helping businesses understand what data they need to protect and how that is being done. First, a business must locate any Personal Identifiable Information – information that can directly or indirectly identify someone – of EU citizens. It’s crucial to know where this is stored, who can access it, who it has been shared with etc. It can then determine which data is more vital to protect. In addition to this, it’s important to know who is responsible for controlling and processing the data, and making sure all the correct contracts are in place.

Step four – Identify the top priorities

Next, a business needs to evaluate how that classified data is being produced and protected. Regardless of how data is collected, the first priority should always be to protect the user’s privacy. Businesses should ask themselves if they need the sensitive data they have collected – this data is worth a lot to a hacker, and has the greatest risk of being stolen. Businesses should complete a Privacy Impact Assessment and Data Protection Impact Assessment of all security policies. When doing this, it’s important to keep the rights of EU citizens in mind, including restrictions of processing and data portability. In particular, any data third parties use to identify someone must be deleted if requested by that individual and approved by the EU. It’s crucial that all this data is correctly and promptly destroyed and can’t be accessed. This process is known as the “right to be forgotten”.

Evaluating how the business protects this data comes next (for example, with encryption, tokenisation or psuedonymisation). The evaluation must explore: any historical data, the data being produced and any data that is backed up – either on-site or in the cloud. This data must be anonymised to protect the privacy and identities of the citizens it relates to. All data needs to be protected from the day it is generated to the day it is not needed.

Step five – Document and assess any additional risks and processes

Of course, there’s more to compliance than just protecting the most sensitive data – the next stage of the process is to assess and document any other risks, to discover any other processes or areas that might be vulnerable. While doing this, the business should update its Data Register, to show the DPA how they are addressing any existing risks. Only by doing this can a business demonstrate to the DPA that it is treating compliance and data protection seriously and with respect.

Step six – Revisit and repeat

Finally, the last step on the compliance journey focuses on revisiting the outcome of the previous steps and remediating any potential consequences, tweaking and updating where necessary. Once this is complete, businesses should evaluate their next priorities and repeat the process from step four.

Moving forward, every decision, plan and application a business makes needs to have security at its forefront. This is process is known as “privacy by design”, and ensures that any data that enters a business is located and protected from the moment it arrives. Any business that fails to demonstrate they have the right measures in place, or have at the very least begun the process of introducing them, will face severe fines and damage to its reputation. In less than a year, when businesses lose the ability to hide their data breaches, we’ll get a realistic picture of the state of cybersecurity in the EU.

View the on-demand webinar on the same content.

By Jan Smets, Data Security Expert at Gemalto, and qualified Data Protection Officer
View the original article.