We get lots of people asking us what it is they need to have tested as a requirement for GDPR Compliance, so I’ve put this together to provide some clarity.
This post is NOT a definitive guide to the General Data Protection Regulations. It is, however, helpful, real-world advice about what you should be considering in your testing requirements for the GDPR.
What the Information Commissioners Office has said about Penetration Testing and GDPR
Article 32 of GDPR is the section that covers security testing and it simply says this:
“a process for regularly testing, assessing and evaluating the effectiveness of technical and organizational measures for ensuring the security of the processing”
Well that’s as clear as mud then isn’t it! But don’t worry there is some further guidance:
Nigel Holden, head of technology policy at the Information Commissioners Office (ICO), said: “There may be some circumstances where organizations could be held liable for a breach of security that relates to measures, such as patches, that should have been taken previously.”
He added: “We therefore strongly recommend that organizations determine which of their systems are vulnerable, and test and apply the patches as a matter of urgency. Failure to patch known vulnerabilities is a factor that the ICO takes into account when determining whether a breach of the seventh principle of the Data Protection Act (DPA) is serious enough to warrant a civil monetary penalty.”
Current guidance from the ICO on their website for the Data Protection Act says:
‘Run regular vulnerability scans and penetration tests to scan your systems for known vulnerabilities – make sure you address any vulnerabilities identified.’
A key part of the GDPR is securing personal data, or more explicitly PII (Personally Identifiable Information). Article 5(1)(f) from the ICO guide covers it:
“The GDPR requires personal data to be processed in a manner that ensures its security. This includes protection against unauthorised or unlawful processing and against accidental loss, destruction or damage. It requires that appropriate technical or organisational measures are used.”
NB: Personal data relates to your employees, your prospects, contractors, customer and contacts etc
So what exactly is covered by GDPR compliance that might need Penetration Testing?
Typically, most organisations large and small keep PII in various applications and business systems which might be on an internal server or hosted ‘in the cloud’. Then there are all those word documents and excel spreadsheets that our employees create and store locally, plus all your emails of course.
And don’t forget the data you give to a 3rd party – payroll for example – you are responsible for that too.
Penetration Testing Requirements for GDPR
The ICO says that “the GDPR specifically requires you to have a process for regularly testing, assessing and evaluating the effectiveness of any measures you put in place”. In practice this will mean undertaking vulnerability scanning AND penetration testing – at least once a year, probably once a quarter and depending on your ‘risk appetite’ weekly or even daily.
Vulnerability scanning is automated and essentially looks at every system that is visible on the public internet and checks that operating systems are up-to-date, that software is up-to-date, patches/security up-dates have been installed, and that the system cannot therefore be exploited with these methods. Testing should also be done to ensure known or default user names and passwords are not in use.
It’s surprising how often we find internet enabled IP telephone systems where the installation engineer has either added or forgotten to remove some default user credentials and we (or anyone else who knows them) can simply log in and interrogate the directory as well as listening to the voicemail messages.
We also frequently find that IT and system service providers are not always meeting their contractual requirements (SLA’s) for keeping the systems up to date and correctly patched.
In short you should really test the external infrastructure at least once a year as a minimum.
Web applications and email
External applications come in three general forms and if they contain PII then you have a GDPR responsibility and they also require what Mr Houlden at the ICO called vulnerability assessments and penetration testing, although not necessarily by you.
Let me pick three possible examples:
Say your company uses an externally hosted CRM like Salesforce or Workbooks which would contain your prospects and customer data. Firstly, under GDPR you should ask the CRM company if they are compliant and satisfy yourself that they are taking adequate steps to protect the PII that they hold. Now I chose Salesforce and Workbooks for good reason.
Firstly they both take security seriously and will be able to provide details for their security processes during both development and upgrading of their respective applications as well as having them regularly penetration tested to a sufficient level that you can be reasonably satisfied that not only are they designed to be resilient to external attackers, but also that they have been tested from a trusted user perspective so you can also be reassured that another company is not going to see you clients data or you theirs within the CRM.
The other reason for choosing these two examples is because Salesforce is based in the US and demonstrates the point that (a) you can have your PII outside of the UK or Europe if you want but (b) wherever it is, you are still responsible for the data and it still falls under GDPR.
Testing of any externally facing applications is equally applicable for those that are owned, managed and/or hosted by you too of course.
Let’s say you use an accountancy firm to run payroll and once a month they receive PII data relating to your staff. Now just like the previous example, you need to ask them what they are doing with your staff data and how they are ensuring they are compliant for the purposes of GDPR? Hopefully, they’ve also read this blog post and done what we suggested. But the key thing is that you / your business has to be satisfied with the response you receive… under GDPR “it wasn’t me” in no excuse if it’s your PII data that walks.
You should want to know they have had an external infrastructure penetration test as a minimum. If they receive the payroll details via a cloud-based application or their own web portal you would also want to know it has had a full web application penetration test annually and conducted by a CREST approved penetration testing company to be reasonably sure that no external attackers or any of their other clients could manipulate the application and access the data.
We tend to find that companies come in two flavors: they are either like Workbooks and they quickly answer the questions and provide evidential support or they flounder around, avoid the question, say they have a firewall or something equally daft … So if they give you a woolly answer then 99% of the time it will be because it’s never been tested.
TIP: If they cannot satisfy you that they have suitable controls in place then you only have four options: get them to have it tested, get it tested yourself, carry the risk and if they do happen to have a breach of your PII, it’s your company that carry’s the can, or go and find yourselves another supplier that takes the security of your data more seriously.
If you ever need to send PII via email (a) make sure it’s encrypted and in a password protected format as a minimum and (b) make sure they are using Two Factor Authentication (2FA) for external login to their email system. Phishing – when a user is tricked into giving away their username and password – is one of the most common reasons for a data breach.
There are two other areas you should consider as your minimum standard.
An internal vulnerability assessment looks at the internal servers, networking equipment and end user devices (laptops & desktops etc) and much like an external test, it seeks to confirm that the systems are up to date and correctly configured. We frequently find that this is an area that’s overlooked by IT teams and especially 3rd part providers who assume that a bad guy isn’t going to get in to start with… and it’s always dangerous to ‘ass-u-me’.
Through our penetration testing, we know that with enough time and effort there is always a way to get inside eventually and a poorly configured internal network can make data breaches all too easy and far more damaging as a result.
Malware and Virus Testing
Since the creation of cryptocurrencies malware and specifically ransomware has become the cybercrime of choice for organized gangs and petty criminals alike.
Malware can enter a business by email, browsing the internet, attachments and files on removable media such as USB sticks, or can even be placed on the network by a hacker that has gained access. If you are considering a penetration test, it’s well worth thinking about some testing with known virus signatures just to be sure your firewalls, web filtering, proxies, antivirus and endpoint software is working as expected. It normally only takes a few extra hours but could save you from a whole world of pain in the future.
This is my interpretation based on experience and best practice. Some organisations are doing far more than this minimum, others are doing little more than a very basic external review. Some are doing nothing at all. It’s all down to your organisation’s appetite and perception of the risk.
What we know of course is that once disclosure is mandated when GDPR comes into force at the end of May then we will all hear about very many more companies being affected by data loss than we do today.