The hype behind GDPR fines is about to start…
The recent announcement from the ICO regarding its intention to the fine BA for a data breach under the applied GDPR will certainly make headlines and result in a raft of new marketing pushing GDPR solutions.
Before we all rush around declaring the dawning of the apocalypse, I’d like to take a step back and remember what this data breach was.
…but the reality is much more interesting
The article by wired.com presents a very detailed account of the items that occurred to result in the breach of personal data, and in short this was a flaw in the websites called cross-site scripting (XSS) that is often reported in the findings of penetration tests but deemed to be low level and of less concern than other issues.
In short, this was not a breach of the data held within the servers of BA itself but allowed the BA website to direct traffic to malicious servers that BA customers thought were real.
Indeed, the occurrence of a breach isn’t something that will necessarily lead to a fine, as long as the governance of the security of processing (which is much more than cyber BTW) has been assessed and improvements planned.
The big fines occur for those who didn’t do everything they should’ve done, and the language from the ICO statement makes it clear that they feel that there was “a variety of information was compromised by poor security arrangements at the company, including log in, payment card, and travel booking details as well name and address information”. I await the final documentation from the ICO with interest to see what was deemed to have happened to result in the decision of the ICO in this matter.
Why is this important?
So this now looks like this is an issue that is purely a cyber one, but the reality is:
a) security of processing within the applied GDPR is not just about cyber but the complete governance of personal data to ensure it is processed in a manner that is understood, safe and appropriate to respect the privacy of those whose data is being processed in accordance with how the data was acquired
b) that XSS is not new and we need to understand why we don’t fix cyber issues. The GDPR security outcomes from the NCSC define the minimum steps to be undertaken under Article 32 of the applied GDPR.
Whether you’re a controller or a processor, you also have specific security obligations under Article 32, ‘Security of processing’. These require you to put in place appropriate technical and organisational measures to ensure a level of security of both the processing and your processing environment
These provisions turn what is considered good security practice into a legal minimum.
I wonder how many people are even aware of these outcomes, given they were published a week prior to the enforcement of the applied GDPR and the Data Protection Act 2018?
Given that the following is a legal minimum for appropriate security within the applied GDPR as stated above:
B.4 Ensuring that web services are protected from common security vulnerabilities such as SQL injection and others described in widely-used publications such as the OWASP Top 10
This would’ve shown clearly that XSS is still something to be addressed within websites, but it still isn’t in my experience. The main reason, I would suggest, is that at present there is so much to handle yet so little resource or focus so the more severe items get addressed. XSS is still something found in too many pen tests, and indicative of lack of basic standards within the build process.
Less than 5% of organisations in the recent DCMS cyber breaches surveybenchmark themselves against the NCSC minimum cyber standards, and only 31% have a cyber risk assessment in the past year. Are we concentrating our efforts on the “advanced” cyber standards believing that they will address the baseline cyber standards?
The gap between cyber compliance and corporate governance
The reality of life is that despite 78% of respondents to the DCMS saying that cyber security is a priority, only 13% are aligning their cyber security activities to legal obligations.
With only 33% of respondents to the DCMS survey having policies to address cyber security risks, this shows that controls are not being implemented according to risk assessments and are likely to be reactive at best. This is reinforced by the statistics on implementation of the GDPR within the DCMS survey show that 30% of organisations made changes due to the new legislation but 60% of this was new policies.
With a recent Ponemon report saying that 56% of organisations bought cyber controls after a breach occurs, this all combines to show that there is a disconnect between the board and how cyber risk is handled proactively.
The lack of understanding the legal context and the focus on generating of new policies to comply with the requirements of the applied GDPR and Data Protection Act is simply symptomatic of the belief that technology can solve all issues, rather than taking a structured approach to address the disconnect between the board and compliance functions.
How to address the gap
If you start to look at assets as belonging to the organisation (and ownership of assets is by officers as per the definition from the Companies Act) you then start to see the need to consistently assess the impact arising from a threat exploiting a vulnerability. Assessing threats at an organisational level, using the language used by the board, then helps with prioritisation on addressing identified risks.
Current UK legislation, when taken together under the equity of law, requires that UK-based organisations understand:
- the location of the data (how do you know where it is being stored, or if it has been deleted?)
- the format of the information (what is the asset?)
- the disclosure requirements (can you share it, and what are the requirements?)
- the retrieval requirements (the retention period and can you access the information throughout that period?)
- the handling requirements (does it need encryption, where can it be accessed from, what right of audit is there?)
- the usage requirements (what purposes was the information acquired for, how do you provide evidence that you meet those requirements?)
So understanding assessing the legal, regulatory and contractual obligations helps with defining an impact for the assets, but also helps with understanding how information should be managed. Note that we are talking about information, not data. The obligations do not care about the technology, they care about what is being managed.
Making sense of what you have
Once you have a consistent understanding of the information and associated impacts, you can then allow the people, process, site and technical assets recorded in various organisational structures to be defined consistently and their risks assessed accordingly.
Rather than managing different technical systems with varying levels of knowledge about assets being incompatible with each other, you can align the assets to a single view of the truth.
A consistent view of the impacts and likelihood does allow you to align with the language used by corporate governance, but also allows you to set the translation between the amount of levels used by the board (be it three, four or five) and the security impact levels used by security standards such as CVSS.
The ultimate positive outcome of taking the steps to understand impact and align it with other systems is that you start to make sense of all the security issues found by your testing activities and patches being notified, which allows you to objectively focus efforts on what matters.