GDPR Part 3: GDPR and the Information Security Program

In the first two parts of this series, we discussed the legal, IT and information security implications of the European Union (EU) General Data Protection Regulation (GDPR)—which goes into effect on May 25, 2018—as well as the six pillars for cyber security as they pertain to GDPR. In this third and final part of the series, we’ll spend some time bringing GDPR and its various requirements back into the information security program in an effort to identify areas where GDPR compliance may become a side-effect of a business-aligned, risk-based, data-centric and threat-aware information security program.

The last decade (or so) has taught us that chasing compliance regulations to “check a box” and not taking care of the fundamentals not only is counterproductive, it actually can hide the current level of risk in an organization by providing a false sense of security. Biggest healthcare breaches? Well after HIPAA/HITEC. Biggest retail breaches? Well after several iterations of the PCI DSS had been developed. Biggest government breaches? Well after FISMA was passed in 2002 and the commensurate NIST standards were developed and refined. With GDPR, we must use our past experience with the changing regulatory landscape and do what we can to pursue compliance without neglecting the other components of the information security program. We best achieve this by viewing GDPR as another risk we must prioritize and manage as we would other information security risks.

Information Risk Governance and Security Program Management

Optiv’s clients often say that information risk governance is an area of particular concern and an area of immaturity. Specifically, we hear they are challenged with communicating information risk to non-security stakeholders and business leaders in a way that enables the them to prioritize initiatives against other risks that are not related to information security or IT (such as market risk, credit risk, etc.). GDPR now throws privacy risk into the equation, and our requirements for effective information risk prioritization and good risk management become even more important.

Article 25 (Data Protection by Design and Default) and 32 (Security of Processing) of GDPR gives us incentive to view privacy in the context of overall risk management. The articles begin with this statement:

Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate...

Article 32 goes on to discuss pseudonymisation, encryption, confidentiality, integrity, availability, and the testing and assessment of such. We couldn’t possibly ask for a regulation to more clearly expect that we perform sound information risk governance in order to protect privacy.

Dissecting Articles 25 and 32 a bit further, we’re clearly expected to use what we know as professionals to ascertain the likelihood and severity that a breach will violate data subject rights. This is far from a “check-the-box” activity, but requires us to leverage the six pillars discussed in the prior post in this series to answer fundamental questions around where GDPR regulated data is in the environment, who has access to it, how it’s currently protected, and where there are gaps. The cost, complexity and benefit of closing such gaps is precisely an information risk governance issue. If ever there was a time for us as security professionals to focus a bit more on risk governance techniques, GDPR gives us such an opportunity. Such techniques can include, but aren’t limited to: standing up an information risk steering committee which includes stakeholders outside of IT and security; creating an information security risk register; ensuring information security risks are included in the corporate enterprise risk management (ERM) workflow (if there is one); and distilling information security risks into clear and succinct business language so boards and leadership can clearly understand the information security risks and put those risks in the proper context with other enterprise risks.

Third-Party Risk Management

Another common concern in our industry is the management of our third-party suppliers and partners. Chapter 4 of GDPR provides general obligations for controllers and processors. Article 25 goes on to require the controller to implement appropriate technical and organizational measures to ensure privacy by design. Nowhere is this requirement more acute (and perhaps carries more risk) than with our third-party relationships. As with information risk governance and security program management, if ever there was a time to get the third-party risk management program tuned up, it’s now.  

We should begin by asking some basic questions: 

• Who processes GDPR-regulated data on my behalf, and how well is it protected? 
• Am I assessing my third-party suppliers to ensure they’re doing the right things? 
• If not, should I be leveraging an outside partner to manage and track third-party risk?

We’re all too familiar with the danger third parties can represent from an information risk point of view, and GDPR leaves us little room to point the finger at a third party and say “they did it,” given the definitions and duties called out for controllers and processors.

Security Operations

Articles 25 and 32 spend a fair bit of their space in the regulation requiring technical and organizational measures to ensure the security of processing and the protection of data subject rights. For the information security professional, understanding what constitutes normal use of information assets and when a change in the environment occurs is critical. As we’ve seen in recent high-profile breaches, both the public and regulatory bodies have lost tolerance for haphazard security operations, especially in the areas of network security, endpoint security, vulnerability management and event management. Meeting Article 32 requirements for the security of processing necessitates that we take care of the fundamentals from a security operations perspective including having (and following) vulnerability and patch management policies, keeping endpoint and perimeter defenses up-to-date (IPS signatures, anti-virus definitions, firewall updates, etc.), and ensuring that we’re using our operational technology in accordance with our policies. None of us want to fend off a regulator asking questions about why we had years-old vulnerabilities or out-of-date IPS definitions.

The very last section of Article 35 in GDPR—Data Protection Impact Assessment—states, “Where necessary, the controller shall carry out a review to assess if processing is performed in accordance with the data protection impact assessment at least when there is a change of the risk represented by processing operations.” Effective security operations and good tools can help enable us as information security professionals to answer the question, “what changed?” Only through effective security operations (not just the tools, but the processes and policies) can we repeatedly and reliably answer these questions.

Technology has also come a long way in this regard which can enable our security operations to provide even more insight into the state of the environment. For instance, the latest evolutions in endpoint detection and response (EDR) technology can give us an operational edge if we have an incident, which brings us to another key element of the security program which becomes more important due to GDPR: incident management.

Incident Management

Determining whether an incident is or is not a breach just became an extremely high-stakes component of the information security program. Articles 33 and 34 of GDPR specify a 72-hour notification window after becoming aware of a breach, with any delay requiring a description as to the cause of the delay. These articles are specific as to the content of the notification and the responsibilities of the controller, and provide us little wiggle room for sweeping incidents under the rug, save for being able to prove that we had technology in place to render breached data “unintelligible to any person who is not authorized to access it.”

Being able to identify an incident, determine what has occurred, and answer the question, “Did data subject rights get violated here?” just became a multi-million-dollar (euro) question. The differences between an incident, a compromise and a breach cannot be understated. Just as with third-party risk, if ever there was a time to ensure an organization had either an internal incident response (IR) capability with qualified forensics professionals and some reverse-engineering capability (or a third-party IR retainer to accomplish the same), it’s now. Imagine a scenario where an incident is discovered, and through good forensics it was determined that the incident did not lead to a breach with violation of data subject rights. Scenarios such as these happen regularly (for instance, attackers looking for health records on a payment network). It’s incumbent upon us to be able to answer our stakeholders clearly, quickly and accurately when responding to an incident and quantifying its impact.

Compliance as a Side-Effect

GDPR is written a bit differently than many of the frameworks, laws and standards we have been used to seeing in our industry, perhaps as a by-product of years of negotiation between EU member states on the language. This stated, if GDPR could be distilled down into one sentence, it would be, “Don’t get breached.” Perhaps a corollary sentence would be, “If you do get breached, it’s going to cost a lot of money.”

It is for this reason we should consider GDPR as an opportunity to ensure the basics are taken care of in the security program. Sound governance, effective third-party risk management, reliable security operations and comprehensive incident response capability aren’t new to our industry. We’ve known for a long time that effective security programs which do these things well are less likely to experience breaches, and that’s precisely what GDPR is trying to accomplish.

Regulatory compliance is a side-effect of well-run security programs. Leveraging GDPR as another risk which warrants our attention (along with other risks) is a sound approach and ensures we don’t chase regulatory compliance at the expense of opening ourselves up to other risks.

In Summary

In this series, we’ve evaluated the IT, legal and information security implication of GDPR.  We’ve identified six-pillars of information security relevant to GDPR, and we’ve hopefully brought it all back together for you by putting GDPR in the context of the overall information security program. Great security programs exist in every industry and across every regulatory environment. We should give GDPR its due as a groundbreaking piece of privacy legislation and yet, simultaneously, keep it in context as we attempt to do the right things for our organizations by building and maintaining business-aligned, risk-based, data-centric and threat-aware information security.