Part I of a 2-part series to inform the AppSec community regarding the upcoming GDPR regulations.
For even more on GDPR be sure to watch the recording of our complimentary webinar:
THINK APPS - You may be thinking that GDPR is a compliance requirement that legal should worry about. You may think that application security has little to do with this new regulation. Think again! The truth is that applications (AKA software) run everything.
The data collected from the data subjects is done by software, the data is then analyzed by software and is presented to whomever needs to consume it by software. GDPR places strict requirements on the security of data processing, which is why GDPR compliance is also an application security problem.
1. Know Your Data
Because you can’t secure what you don’t know, it is essential that an enterprise understands what data it is processing. According to GDPR, data processing is really anything you do with data. Things like collection, modification, deletion and aggregation are all data processing. Even if you are collecting data for the purposes of determining if an individual’s data is subject to GDPR - say their country of residence - you are already processing GDPR data. Most organizations have multiple applications and multiple ways of collecting data. Having accurate inventories, including those Microsoft Access databases, is of critical importance.
Once you have identified what data you are collecting, you should go through a minimization exercise. GDPR mandates collecting only the necessary data that is relevant to the purpose of collection. It is easy to just collect data and figure out later if you need it. GDPR forces you to go through that determination up front. This mandate is actually a lot better than it seems on the surface. If you don’t need certain data points, don’t collect them - and then you won’t have to worry about securing them! Why carry that extra burden? Determine the data that is absolutely critical and justifiable to your business operation and collect only that data. Google, for example, currently collects your date of birth when you open a new account. If you read through their justification it is so they can determine if you are old enough to receive certain Google services. I ask – do they need my date of birth for this or just my age? It will be interesting how and if Google changes this practice with the onset of GDPR.
2. Implement a Risk-Based Approach
Having trimmed the data you are collecting, now it is time to classify or risk-rank the data. GDPR focuses on protecting the data subjects and a lot of it revolves around the “risk to the rights and freedoms of natural persons.” When classifying data, organizations need to understand how important the data is to the individual it belongs to. What bad things can happen to the individual if you lose that data? Will it be simply a nuisance or can it affect their livelihoods? This is where it is important to think like an attacker. Having an adequate threat model will greatly help. You may think the data is trivial, but if an attacker can find secondary uses for the data, such that it affects the freedoms of people, it may not be as trivial as once thought. Take thermostat data for example. It may really not be that important at first sight, but an attacker can use that data to determine when you are on vacation and the best time to rob your house or even steal your identity, since you are probably not as vigilant about checking that credit monitoring service while climbing Mt. Kilimanjaro.
Accurate data classification will ultimately determine your risk and how much security controls, if any, you should implement in protecting that data. Essentially, it will determine how much you should spend on security. GDPR mandates a risk-based security approach. However, GDPR by itself does not prescribe any controls and there is really no “compliance” stamp for any specific data set. GDPR provides the framework for courts and data protection agencies within each member state to determine if the level of security meets the risk of processing. It is quite possible that you may get away with having subpar data protection, however if there’s a complaint or a breach and it is determined that the level of controls are inadequate – you could be in hot water.
3. Design Security IN
Not that long ago, I would frequently find that application security was an afterthought. It would be something bolted on top to meet compliance requirements; address results of a pen test; vulnerability scan; or a 3d party audit. While the situation is improving, security still appears to be a non-functional burden to some - and it is easy to understand why. Security controls generally add very little to the initial value of the application. It is not a feature and, for the most part, does not generate additional revenue, therefore it is easily overlooked or sometimes, brushed under the rug.
GDPR changes this trend with a requirement to build “secure by design and default”. It mandates that data protection principles be implemented at the earliest stages in the process and that highest possible protection is the default norm.
So what does this really mean for your application development process? This really boils down to thinking about security at the start of the project and continuing the security mindset throughout the product life-cycle. Threat modeling your application, for example, will help you take the attacker perspective and understand why someone may want to attack your application and how they might go about doing so.
A good threat model will feed into your security requirements. These requirements become just as important as functional requirements for your application. They may include specific controls and countermeasures for identified threats; security expectations of business logic, such as access control or transaction integrity; and perhaps specific regulatory requirements, such as PCI. The critical part is to build these requirements early and keep refining and improving on them as you move through the development process.
Next week I’ll share Part II with the remaining top tips, but if you just can’t wait that long or are looking for even more insight into how application security fits into GDPR, please click to register for our complimentary webinar: GDPR: The AppSec Twist on March 21, 2018 at 12:00pm ET.
