What GDPR Means for Application Teams

You’re likely aware of the European Union (EU) General Data Protection Regulation (GDPR) that strengthen’s the rules regarding user data and privacy. This regulation applies not only to data processors operating in any EU member country, but also to non-EU companies that process data concerning EU citizens. Given the global nature of modern commerce, the potential impact of GDPR is far-reaching.

I will refrain from going into yet another “Myths or Facts about GDPR” post, as such an approach is often aimed at creating fear, uncertainty and doubt (FUD). Instead, in this post I’ll focus on what GDPR compliance means from an application development team perspective.

Data Owner Rights under GDPR

GDPR lists several actions that can be taken by a “data subject” (i.e., customer) as respects his or her personally identifiable information (PII) that is persisted in a storage medium hosted or controlled by a service provider. In so doing GDPR makes it clear that the data subject is the owner of his or her personal data.

As respects the rights of a data owner, GDPR requires organizations that come under the law to have the following policies and processes in place when it goes into effect on May 25, 2018:

  • Right to Erasure — The ability of the data owner to request to be forgotten and have his or her personal data removed (deleted) from the system.
  • Right to Restriction of Processing — The ability of the data owner to request that his or her data be marked “restricted” and cannot be accessed or processed without express consent from the data owner.
  • Right to Data Portability — The ability to export personal data in a machine-readable format so it can be transmitted between service providers (at the request of a data owner).
  • Right to Rectification — The ability to get errors in personal data corrected, and the ability to be notified in a timely manner of a breach of a data owner’s personal data.
  • Right to be Informed — The ability to provide a data owner with access to his or her personal data under your control in human readable and understandable form (layman’s terms, not legalese).

Compliance begins with Knowing What PII Is

To be in compliance with GDPR, it is critical to know what PII is. PII is any piece of data that can be used to uniquely identify a person, or data that concerns an already identified person. It is important to note that PII is not only data that a user has explicitly provided, but also data that a service provider has collected about an individual, including activities taken using the application (pages viewed, actions taken, purchases made, places driven, music listened to, etc.), as well as personal data collected from third-parties.

It is imperative to understand that GDPR updates previous EU regulations regarding data privacy. Under the customary interpretation of previous EU data protection rules, PII was classified as two or more data elements that, when coupled, could be used to uniquely identify an individual, such as a person’s name and SSN. Under GDPR, any single data item that is personal to the user is classified as PII. As a result, only one data element that is sensitive, such as a person’s name, is now considered PII, as is anything that can be tied back to that sensitive data element. Whether you interpret this as an expansion or clarification of EU law as respects the types of data that must be classified as PII, it is clear that the rules are changing.

Implications of GDPR for Application Teams

To give data subjects (owners) the ability to exercise their rights under GDPR, application developers must account for a slew of new requirements in both the design and update of their applications, including (but not limited to) consent management, data minimization and pseudonymization.

The data security requirements strengthened by GDPR have vast implications for application developers, DevOps, and security staff. As more and more development teams adopt agile methodologies, the ability to deliver and maintain applications that are both “secure by design” and adhere to the “privacy by design” philosophy espoused by GDPR will be a challenge for security and DevOps teams.

Let’s look at some of these challenges in detail.

Data Knows No Bounds

Data does not understand boundaries; it permeates through every crevice of an organization and its infrastructure.

Data goes through a life cycle. When a company creates and processes information, that data is in motion. Then, that data passes through the system to its new home on a storage media somewhere, becoming data at rest.

Often, tools to enforce and measure compliance are applied to data at rest. While data at rest is sometimes considered to be less vulnerable than data in motion, attackers often find data at rest more valuable than data in motion. For protecting data at rest, enterprises can encrypt sensitive files prior to storing them, or encrypt the storage drive itself, or apply policies to protect the storage boundary.

Encryption plays a major role in securing data at rest. For protecting data in motion, enterprises often encrypt sensitive data prior to transport, or use encrypted connections (HTTPS, SSL/TLS, FTPS, etc.), or both.

Encrypting data at rest and securing channels for data in motion are important first steps for security, but this does not guarantee that sensitive data is protected. If PII data is shared with a SaaS partner or external service provider and a breach occurs, both the originating and receiving companies may be liable under GDPR. Thus, it is critical to secure every layer of the infrastructure that interacts with sensitive information.

Anatomy of Data

To determine and enact appropriate security measures that comply with GDPR, we must understand the anatomy of a data — its creation, transformation and flow across its lifecycle:

  • Where did the data originate?
  • Where is the data used? (identify all places the data is shared)
  • How is the data protected at each stage?

Armed with this information, organizations can identify data security violations and vulnerabilities and come under compliance.

Measuring compliance or lack thereof does not move at the velocity of CI/CD. With every build of an application, data elements are added, revised, removed, and new communication channels are enabled within and across the boundaries of the application’s services. Any of these changes can drastically affect the risk profile of an application from a security standpoint.

Priorities for Complying with GDPR

Organizations must prioritize five specific actions to prepare for the impending requirements under GDPR:

  1. Data discovery and classification (sensitive user-defined or business domain-specific).
  2. Data flow analysis (across microservices, business partners and service providers).
  3. Authentication and authorization controls.
  4. Codifying policies to track data flow across service and between business partners and services.
  5. Continuous measurement of compliance and violations.

Every successful business is based on the premise of collection and exchange of data. Putting into place the right strategies and systems can keep your business secure for years to come.

Stay Tuned

This blog is the first a series of posts on GDPR. In my next blog I will discuss data classification and discovery in context of GDPR. In the mean time, feel free to reach out to me directly or post your comments here.


What GDPR Means for Application Teams was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.



*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Chetan Conikee. Read the original post at: https://blog.shiftleft.io/what-gdpr-means-for-application-teams-125277be0589?source=rss----86a4f941c7da---4