Updated Dec 1. 2020
More than 2 years after the GDPR came into force (May 25, 2018), sanctions have been pronounced by several data protection authorities. These sanctions have important consequences, economic but above all for the reputation of the companies concerned, as they are publicly communicated.
While the essential principles of the GDPR (General Data Protection Regulation) are generally known, the main technical measures to put in place to secure a website or an information system are sometimes still not so clear. To remedy this, we detail in this article the technical security aspects of the GDPR.
What does GDPR Require in terms of Security?
GDPR (General Data Protection Regulation) clearly sets personal data security as one of its main principles. Privacy by design and by default impose that personal data must be protected from the design stage, and in the default settings of a product or service. This Privacy by design and default applies to data exchange between a company and its clients as well as its suppliers. Data must be protected from misuse (human or software error) as from hacking (Art. 5 ; Art. 25).
Article 32 of GDPR “Security of processing” outlines the main security requirements:
- “to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;”
- “to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;”
- [having] “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.”
The Key Principles of Personal Data Protection of the GDPR
Minimising the Collected Data to Reduce Risks
Data protection is facilitated if the area to be protected is reduced. The minimisation of collected data as required by the GDPR helps to protect data by limiting the number of data, their storage and the persons having access to them to what is strictly necessary.
From a technical point of view, this includes reducing the amount of technical information freely available on the Internet: in the source code, versions of the third-party components used, error messages, etc. Attackers use this information to prepare their attacks and make them more relevant (and therefore more dangerous).
Know your Attack Surface and Reduce it
A company’s digital footprint is often made up of several elements: website, domains and sub-domains, test versions, servers, cloud services, etc. Carrying out a complete and up-to-date cartography is essential to know and reduce its attack surface, and therefore protect the company and the data it has at its disposal.
Do you know where and how the pre-production versions of your website, web application or API are stored? Are they linked to your elements deployed in production? How are they protected? Are there other potentially vulnerable elements on the same server? If one of them is compromised, can the attacker spread to the others? If credentials are stolen, can they be used on other applications or servers?
Be Careful with Third-party Components
At all levels, companies use third-party components: operating system, frameworks, CMS, libraries for building a website, etc. It is not because those components are developed by other companies or individuals that you should not pay attention to their safety. Likewise, it is not because a solution is popular that it is more secure. On the contrary, it is probably more targeted.
Some components have known vulnerabilities, with even online shared exploitation possibilities. Attackers are only too happy to have effortlessly available attack scenarios. They will try to exploit them before looking for vulnerabilities specific to your platform. Vulnerable components are indeed n°9 in the OWASP Top 10, because they are widespread, generally exploitable without too many technical difficulties and cause damage that can be significant, such as denial of service, data theft or even server compromise.
However, the use of third-party components must not be stopped. Their vulnerabilities can be corrected by ensuring a complete and precise monitoring: cataloguing the elements used, knowing their functions, keeping them up to date and/or patching any flaws discovered. Planning a regular update is essential. It is also recommended to follow the news in order to be alerted quickly if a component used has a newly published vulnerability (0day).
GDPR Specific Points of Attention
Access Control
Article 25 states that “[…] by default personal data are not made accessible without the individual’s intervention to an indefinite number of natural persons.” to an indeterminate number of natural persons without the intervention of the natural person concerned. »
Two vulnerabilities are meant by this statement:
- Lack of access controls on other users’ data: a user X can access information or files related to the account of a user Y,
- Privilege elevation, lack of access control over “functions”: a user can perform actions normally reserved to administrators (create, modify or delete registered elements, etc).
These vulnerabilities are common, they are also n°5 in the OWASP-Top 10. Attackers appreciate these flaws as they allow them to collect data (to sell them on the black market or to use them for future attacks), or alter them in order to make the platform unusable. The potential consequences are therefore quite high.
Data Encryption
GDPR emphasizes the encryption of personal data both in use and in storage. In the event of theft or data loss, the data will be unusable, as it cannot be read without the decryption key. The potential impact of the attack is therefore far reduced.
Nevertheless, data encryption does not solve the initial problem: an attacker had access to data. If there is access to personal data, the attacker may also have obtained information about the encryption, even if it was stored in a different location. It is also quite conceivable that the attacker may be able to find a decryption key. The important thing is therefore to protect the entire system.
Logging and Monitoring
Lastly, GDPR requires to notify a personal data breach to the supervisory authority (Art. 33), as well as the data subject (Art. 34). However, how can this obligation be met if it is not known that a breach has occurred?
Special attention must therefore be paid to monitor logging. Well-established logs provide information on the attempts and angles of attack, and therefore on the most vulnerable parts of the systems: by what means did the attackers try to enter? Where did they enter? What elements did they have access to? … Monitoring logs is therefore very important to strengthen security. It is thus important to put in place good practices to facilitate implementation and increase the efficiency of good logging and monitoring. Attackers rely on the lack of control and the detection time to hide their presence and achieve their goal. Insufficient logging and monitoring is thus ranked n° 10 in the OWASP Top 10.
To make up this vulnerability, it requires to detect and register unsuccessful access attempts, suspicious activities, attack attempts and to automate alerts for unusual actions. Let’s not forget that attackers generally choose to carry out attacks when surveillance is less intense (at night, on weekends, during holidays).
In conclusion, not all the technical measures to secure information systems are mentioned here. To go further, you can read the article of the ICO “Information security.” Each company must reflect on its personal situation with its processing and security issues in order to adapt the technical measures to be implemented.
A manual penetration test (pentest) – as we offer – can then be carried out to check the strength of the information system.