Published on February 21st, 2023 📆 | 4047 Views ⚑
0GDPR 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.
Gloss