How Does GDPR Impact Open Source Security Expectations?
Your inbox is probably jammed full of emails talking about GDPR, the European Union’s comprehensive data privacy regulation regime that is set to come into effect on May 25.
The driving force behind GDPR is to formalize data protections across the European Union, giving citizens better control over how their data is handled, guarding them from abuse. A large component of this is to set expectations for companies regarding how they handle user data, whether they fall into the categories of data processor or controller.
This is hardly the first time that the EU has issued regulations on data and privacy, but it is causing such waves of stress globally because it forces all organizations that have EU citizens’ data to be compliant, regardless of where in the world they are located.
The past decade has seen an explosion in the amount of data that organizations are collecting on users. Beyond simplistic details like names and emails, many companies hold personally identifiable information (PII) like our addresses, social security/national identification numbers, and other bits that can be used to commit wide scale fraud. This is not to mention financial information like credit card numbers that are commonly stolen from poorly protected databases, sold on the dark web and other corners of the internet.
Amidst the scramble to make sure that your organization is compliant, cleaning out excess data and notifying your loyal customers, you might be missing out on one of the most important aspects of the regulation — namely keeping your applications secure.
Breaking Down the Role of Open Source in Application Security
Applications are the interfaces that allow us to access data, making them a prime target for attackers. Research by the Global Risk Management Survey in 2016 found that 84% of cyber attacks target the application layer, using it to make their way into an organization and steal their valuable data.
These applications are vulnerable to design flaws that can be exploited by hackers to breach without the need for an action like an employee clicking on a phishing email. GDPR lays out in Article 25 that data should be protected by design and default, pointing to the need to build applications that do not contain any known vulnerabilities that could be later exploited by hackers.
The issue of known vulnerabilities is most prominent in open source components, often referred to as the building blocks of software as they comprise between 60-80% of the code base in applications. The challenge is that when a new vulnerability is discovered, it is generally reported to one of the security databases or advisories so that developers can patch their system and avoid using the risky components.
Hackers are also watching these updates, receiving free intelligence on which components are vulnerable and how to carry out the exploits, saving them months of work sifting through the code themselves.
Last year’s hack of Equifax, wherein hackers exploited a known vulnerability in the Apache Struts 2 open source framework in the company’s web application to steal the PII belonging to over 145.9 million people, highlights the necessity of keeping on top of open source security.
Unfortunately for security teams, these postings are distributed, and difficult to track on one’s own manually.
Adopting the Right Tools for Stronger open source Security
In order to keep their data — through building better applications — secure, organizations need to ensure that they are not incorporating open source components with known vulnerabilities into their products.
The only way to ensure this is to know which components you have in your environment is to use an automated Software Composition Analysis (SCA) tool that runs continuously, detecting open source components and matching them with a wide ranging database of known vulnerabilities to alert developers if they are using a risky piece of code. By warning them before they add a bit of risky code, SCA can help developers shift left their security, catching problems before they turn into tragedies.
Article 32 also has implications for GDPR’s impact on open source security as it requires “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.”
Since SCA tools continue to monitor products throughout the SDLC, including post deployment, they can help security teams to shift right security, receiving similar alerts when a new vulnerability is discovered in an open source component that they are using in one of their products.
Application security testing tools that are aimed at proprietary code, like SAST or DAST, are unable to identify vulnerabilities in open source components. Unfortunately, far too many organizations believe that they are protected with their AST solutions, and have not implemented SCA tools, and like Equifax, are missing out on vulnerabilities that could be putting their users’ data at risk.
Acting in Good Faith
Regulators understand that implementing all of the necessary measures to reach compliance with GDPR is no mean feat, and will take time. Based on insights from experts familiar with the rollout of the regulations, it appears that the enforcement will likely target those who are the worst offenders, exhibiting gross negligence or disregard for the spirit of the rules.
However, where we are likely to see regulators taking a harsher stance is in cases where a breach occurs and the victimized organization was found to have not taken basic measures to protect their data, such as utilizing SCA tools to secure their open source use.
Headlines of mishandling of information by data-driven companies like Facebook and the misuse that can occur when in the hands of outfits like Cambridge Analytica, not to mention Equifax, have raised the public consciousness surrounding the issue of data protection. This raises the stakes for companies to show that they are taking steps to be responsible actors.
Penalties are high for offending companies, as fines can reach up to 20 million euros or 4% of the total worldwide annual turnover of the preceding financial year, whichever is higher according to the statute.
The slog towards compliance is tough enough without the need for hysterics over the upcoming due date. Adopting the right tools can help make getting on the right side of regulation easier, helping your team return their focus to the business of building great software and serving customers.
