GDPR deadline: Does “appropriate security” include open source risk?

Organizations that handle European citizens’ data must adhere to “Appropriate Security” in the EU GDPR. It’s time to address appropriate security at your organization.

It’s May 25th, 2017, and the GDPR deadline is bearing down on us like an express train. Personal data privacy is the impetus behind the EU General Data Protection Regulation (GDPR), which goes into effect in exactly one year — on May 25th, 2018.

Will your business be impacted by the GDPR?

Any organization based in the EU or that processes, holds, or owns the personal data of European citizens needs to adhere to the GDPR — or face heavy penalties.

Created by the European Parliament, the General Data Protection Regulation mandates that all companies processing and holding the personal data of European citizens must protect that information — regardless of where it is sent, processed or stored — and proof of protection must be verified. “Personal data” can be anything from a name, a photo, an email address, to bank details, posts on social networking websites, medical information, even a computer IP address.

The new regulation applies to any organization that holds or processes the personal information of any European citizen, regardless of where the organization itself is based, or where the data processing takes place. All companies that process, hold, or own European data must comply with the law’s provisions, and that includes U.S. and U.K. (Brexit notwithstanding) businesses.

Once this regulation goes into effect, the penalties for non-compliance can be severe. Organizations can be fined up to 4% of annual global revenue or up to €20 million (approximately 22.3 million USD ) for breaching GDPR, whichever figure is higher.

Open source security and the GDPR

Complying with the GDPR will require a proactive effort by organizations that control or process personal data.

General requirements of the General Data Protection Regulation revolve around the concepts of preventing, assessing, and monitoring, including a gap analysis examining current security processes to determine what may need to change to meet the new requirements. Of note is the regulation’s Article 32: organizations will be required to “ensure a level of security appropriate to the risk,” including establishing processes for regularly assessing and testing security practices.

“Security appropriate to the risk” is a key phrase. Many organizations don’t pay sufficient attention to the additional security exposures created by vulnerable open source components, and may not even be aware these exposures exist. Yet today’s software is built on a core of open source, and open source use is pervasive across every industry vertical. 96% of the 1,000+ applications scanned in Synopsys’ latest Open Source Security and Risk Analysis (OSSRA) were found to have open source in their code, with nearly 70% of those applications having vulnerabilities in the open source components used.

OpenSSL, Heartbleed, and the GDPR

OpenSSL was among the most common high-risk components found by the Synopsys analysis. OpenSSL, an open source project contained in hundreds of thousands of applications that need to secure communications over computer networks, is widely used by multiple industry verticals. More than 66% of websites use OpenSSL, as well as a multitude of business email servers (SMTP, POP and IMAP protocols), chat servers (XMPP protocol), virtual private networks (SSL VPNs), network appliances and a wide variety of client-side software.

In early 2017, more than 200,000 websites were still vulnerable to Heartbleed, a critical security flaw of OpenSSL that can expose supposedly secure communications. Even today, many companies still incorporate a version of OpenSSL containing the critical Heartbleed vulnerability years after the security issue was made known and long after versions of OpenSSL fixing the vulnerability became available.

Would a failure to secure against a widely-publicized vulnerability disclosed years before become a violation of the requirement for appropriate security if a hack exploiting that vulnerability was used to steal personal data? Very possibly. I for one, would not want to be a C-level executive confronting that question.

Would ignorance about the vulnerable open source component be a defense? In the case of a well-known vulnerability like Heartbleed, almost certainly not. And again, who would want to take the risk to find out?

GDPR compliance will be both a challenge and opportunity for your business

Many enterprises will require their vendors to be fully compliant with the GDPR as a condition to doing business with them.

With the right approach and early planning, organizations can turn the necessity of complying with the General Data Protection Regulation into an opportunity now to differentiate and open new business opportunities for their firms. In addition, many enterprises will require their vendors to be fully compliant with the GDPR as a condition to doing business with them. These requirements will typically be part of the RFP process and / or privacy and security audits. Non-compliance could lead to significant loss of business to competitors who are able to demonstrate their GDPR compliance.

If your organization needs to comply with the General Data Protection Regulation, you’ll need to examine the software eco-system you’re using and include open source identification and management in your GDPR security program. As well as examining custom source code for vulnerabilities, ensure that the open source you or your vendor companies use is not introducing hidden security vulnerabilities.