The European Union’s General Data Protection Regulation (GDPR) takes effect May 25 and the penalties are stiff for failing to comply. Many are still unsure whether their companies are safely out of harm’s way. The regulation is long and full of terrors, to be sure. However, resistance is futile.
“Many organizations are saying that they will simply refuse traffic from EU countries, and think that will dispense with the need to comply with GDPR,” said Anne P. Mitchell, attorney, GDPR compliance consultant, and author of Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law). She’s also legislative consultant and CEO/president of the Institute for Social Internet Public Policy (ISIPP), formerly known as The Institute for Spam and Internet Public Policy, among many other positions and achievements in internet law and policy issues, from both the legal and the technical sides.
“However, beyond the fact that there is simply no real way to know—because of VPNs, tethering and so forth—it is a violation of GDPR to do any sort of automated profiling of data, including to determine location,” she added. “So, the very act of detecting and geolocating an incoming IP address—unless done manually for every single IP address— is itself a violation of GDPR.”
Since there is no escape from GDPR, here are six of the trickiest obstacles security teams will have to overcome:
‘Identifying Data’ Doesn’t Mean What You Think it Means
Cookies, IP addresses and other data points that enable someone to deduce a person’s identity are now considered personal identifying data, too. This is problematic on several fronts, since a lot of these types of data are routinely and automatically collected and because companies typically are not aware of what data they are collecting and storing. Therefore, most companies are unable to identify every instance.
“For the most part, companies already treat the standard bits of personally identifying data, such as date of birth, SSN, etc., securely, and even if it is not up to snuff for GDPR, it’s not always that difficult to get there,” said Mitchell.
“But IP addresses, for example, are a whole other ballgame because network systems take note of incoming IP addresses in a host of different ways—some of which the IT and security teams may not even think about. For example, when a sending mail server connects to your receiving mail server, your server makes note of the sending IP address. If it is storing that IP address —which, of course, it is in mail logs—that data is subject to GDPR. Likewise, the recording and storage of IP address in the email headers in received email, which are in the mail clients of the employees, etc., at the organization. And of course, the email addresses as well.”
A privacy audit and risk assessment are in your future, if you haven’t done it already. Several experts are recommending the use of OCTAVE Allegro methodology for that.
“Unlike some risk assessment methodologies that deal with the security of a particular system, OCTAVE deals with data assets, what they are, who has access, where they are stored, and what threats they are exposed to,” said Tom DeSot, EVP and CIO of Digital Defense.
“As an example, when looking at GDRP and personal information, you would want to look at the common components of the data, say ID number, and then look to see how the ID number is being collected and stored, who inside and outside the company has access to the captured information, and what threats such as a hacking breach or insider action may place the data at risk,” DeSot added. “Once you’ve done this you can begin putting mitigating controls in place.”
No, You Really Don’t Know Where Your Data is or How Much is Subject to GDPR
“The first thing that companies need to understand is, “Where is ALL of our data that pertains to EU citizens? Where does it reside (what specific databases) and where is it in transit?” explained Greg Reber, CEO at AsTech, a San Francisco-based security consulting company. “This is more than simply a data-mapping effort, as many companies have grown organically and most likely there is not a single data architecture documentation that is all-encompassing.”
And Reber is right: Knowing where your data is can be a complicated exercise.
Dallas N. Bishoff, director of security services at PCM, an IT products retailer, gave the following examples in a scenario involving a U.S. citizen who lives in the EU as a resident and works for a U.S. company subsidiary in Europe—keeping in mind that EU residency creates the basis for GDPR protected data:
- The employee experiences a healthcare event while in the United States. The family is aware of the individual’s medical history. The employee has been treated in the EU. The doctors at the U.S. healthcare organization arrange to have his medical records transferred to the United States for review by the attending physician. This transaction is subject to GDPR.
- The U.S. citizen is conducting regular HR transactions with the parent company in the United States. In fact, he is in the HR offices located in California. These transactions are subject to GDPR.
- The U.S. citizen, while residing in Europe, maintains communications with his old U.S. friends through social media. The social media transactions are subject to GDPR.
- The U.S. citizen, while residing in Europe, purchases products online. In the process the employee establishes an online profile with any number of e-commerce sites. All transaction with privacy data, and the purchasing habits of the individual are subject to GDPR.
- The U.S. citizen, residing in Europe, is assigned a dedicated IP address to conduct business with the U.S. corporate network. The dedicated IP address is used to verify the connection and is associated with the individual’s identity. The association of the IP address to the U.S. employee constitutes a GDPR protected record.
- The company maintains the employee’s identity in the corporate LDAP directory as part of the enterprise Microsoft Active Directory. The LDAP record for the individual contains privacy elements. Replication of the directory, to include EU resident records, across transnational boundaries constitutes a GDPR protected transaction, and the replication into the Unitd States without appropriate controls or consent will most certainly violate GDPR.\
Outsourcing Doesn’t Let You Off the Hook; It is a Hook
“Organizations that outsource anything related to their data in which they are providing/sharing that data to the outsourced entity can be on the hook for liability if the organization to whom they outsourced it—for example, a ‘data processor’—has a breach and especially if that data processor is not GDPR-compliant,” Mitchell warned.
Mitchell gave as an example scenario: Acme Widgets uses Great Email Newsletters to send email newsletter to Acme’s customers. To do so, it upload the list of its customers’ email addresses to GEN. GEN has a data breach. Acme can be equally on the hook for liability.
“This is why we urge our clients to add an indemnification clause in their third-party data processing contracts,” she said.
Delete on Demand, Copy on Command at Any Customer’s Whim
You know that part in GDPR that refers to “the right to be forgotten?” That means you’ll need to be able to delete all data about any customer or user who demands to be forgotten. But, you’ll also have to be able to provide a copy of that data if a user wishes to review what you have prior to telling you to delete it, or simply wants to see what information you have. Be sure you can find, copy and deliver or delete such information on short notice.
Real-Time Breach Reporting is Really Real-Time
This regulation makes no delays or exceptions in reporting a breach. You must find it fast and report the breach immediately or your company will be hit with potentially catastrophic fines and penalties.
You Have to Prove “By Design and By Default” in App Development
“One particular aspect of GDPR that requires greater consideration is the role of application development in the requirement to implement ‘data protection by design and by default,’” said Paul Farrington, solutions architect at CA Veracode. To comply with this clause, he said, you must be able to demonstrate that your application development processes are secure “by design and by default.
“This requires a shift-left of security throughout the software life cycle: from secure design and threat modelling to educating developers on secure coding practices,” Farrington explained. “Developers really need to be empowered to identify and remediate any security defects in their code—preferably, as they write it. Organizations should invest in automated and human code review, before it’s released, to ensure appropriate ‘pseudonymization’ and encryption of data.”
One more word of warning. Before you finish mastering all those hurdles in GDPR, another big challenge is headed your way. It’s called the Network Information Systems Directive (NISD); it pertains to network and systems security and it also comes to bear in May. At least there may be some good news in becoming compliant with NISD.
“While the GDPR and NISD have different criteria, their intent—to minimize risk—is mostly the same,” said Alexey Sapozhnikov, co-founder and CTO of prooV, an all-in-one proof-of-concept software provider. “NISD compliance is relevant for digital service providers, such as online marketplaces, online search engines and cloud service providers, and organizations should take the necessary security network and information systems measures to make sure that they are compliant.”
Good luck and may the odds be ever in your favor!