Design Thinking & GDPR

Design Thinking & GDPR

The General Data Protection Regulation (GDPR) makes the law (at least, in relation to EU personal data) what privacy professionals have been saying for years—think about privacy concerns (like collecting as little personal data as necessary and safely getting rid of personal data when it is no longer needed) when designing products and services that involve the handling of personal data. GDPR calls this “Data Protection Privacy By Design and Default.” 

So, what do I, as a security professional have to say about this? Well, I say, “This sounds familiar.” And it should. It’s just the security development lifecycle (SDL)—“Secure By Design, By Default and In Deploy” —with a privacy spin. The commonality is how “design” is given primacy in both approaches.  

Are both design practices—privacy AND security by design—required? On principle, we (and any other security-minded product company) would say “absolutely!”   

But, while GDPR explicitly requires “privacy by design”, if you are looking to GDPR for the words “secure by design,” you won’t find them. Instead, when it comes to security requirements, you will find repeated references to the “state-of-the-art.” That said, can you legitimately call your product security practices “state-of-the-art” while passing on secure design? Likely not. We would not leave this up to chance in an audit—do both “secure by design” and “privacy by design.”  

Assuming you agree in principle, you might still groan that this is now double the work. We don’t think so. These things can be done together. So, the next question is “how to?”. From a privacy perspective, GDPR is pretty specific: start with a privacy impact assessment (PIA). What about from the security perspective? We think you must start with threat modeling. This means, if you have done neither, then start here.

Threat Modeling

Arguably the most important aspect of the SDL is “threat modeling.” It’s the primary tool in “Secure by Design.” We use threat modeling to identify exposures that may be susceptible to various forms of “threat activity.” We make the distinction “threat activity” versus just saying “threat” on purpose. We usually think of a threat as the one who is threatening someone or something. But in this case, we are simply looking to identify all the places in a system that is susceptible to the things various threats (threat actors) might do. By taking this route we avoid the rabbit hole of identifying various intangible actors (nation-states, organized crime, script kiddies etc) and focus on the weaknesses in your systems they may abuse.  

While there are various schools of thoughts on identifying “threat activity”, probably the most canonical is called STRIDE. It stands for: Spoofing, Tampering, Non-Repudiation, Information Disclosure, Denial of Service and Elevation of Privileges. A thorough threat model looks at a product’s architecture, particularly its data flow, to identify all the places the system may be susceptible to threat activity. Where unmitigated exposure exists they are documented, prioritized and mitigated.

One thing to note about threat modeling in relation to GDPR: virtually all of the threat activities, perhaps save denial of service, tie directly into privacy.   

Privacy Impact Assessment (PIA)

PIAs in GDPR parlance is enshrined in Article 35 “Data Protection Impact Assessment.” They are called DPIAs but are really just PIAs by another name. PIAs look to understand how and why data is being used and then recommends mitigations to risk that might impact the rights and freedoms of “natural persons.” (A natural person is just a fancy term for individuals covered by GDPR, i.e. EU folk.) So, PIAs identify privacy threats to individuals where threat models identity technology threats to a  system.  So, it makes sense to do these together – there’s bound to be overlap.

There are plenty of examples of PIAs out there so we won’t recreate the wheel here. The principal elements are:

• What type of personal information is being collected and how sensitive is it, not just to the business, but also to the person to whom it belongs (something you probably already did as part of your threat modeling)?
• How is it gathered, used, stored, moved and why (also something you probably already did at least some of as part of your threat modeling)?
• Is it necessary and proportional to the purpose for which it is being processed?
• In what contexts can it be shared and why (something you likely sussed out in your threat modeling)?
• How is it protected each step of the way (see threat modeling—what did I tell you!)?

An additional question is when should PIAs be done?  In short, at the start of a product’s design, when existing data may be used/shared for a new purpose, and at any time when new systems or data are being considered that could have an impact on the rights and freedoms of an individual.  In short, when any change could expose individuals (data?) it’s time to consider updating the PIA.  

Design Holistically—Better Safe Than Sorry

In summary, if you plan on doing business globally then both security and privacy by design is not an option. You will need to demonstrate that you considered how bad guys and your own systems might impact the rights and freedoms of individuals. Our answer is to integrate threat models and privacy impact assessments holistically. We believe this will go a long way toward solving for both concerns and better anticipate the next “GDPR” and or “threat actor.”  Lastly, while there is no such thing as perfect security and privacy we do believe luck favors the prepared!

How to Get Started

New to GDPR? Don’t worry, we’ve got you covered. Here are some resources to get you started:

• Getting to know the 4 magic letters of compliance: GDPR
• What are data subjects, data controllers, and data processors?
• What Twilio is doing to protect your data

If you’re already on top of your GDPR game, you probably know that you need to have appropriate data protection terms in your contracts with service providers that process EU personal data on your behalf. To that end, Twilio has updated its data processing addendum. Fill in the data processing addendum request form to receive the addendum.

The countdown has begun – so let’s get it done! Onward!