GDPR is the buzzword of the moment. There are many articles explaining-detailing-advising the new legal obligations. We noticed, however, that most articles remain broad on the new security requirements. Here is also an article dedicated to the security aspects of the GDPR.
What does GDPR Require for 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 are protected from the conception, and in the default setting, of a product, a service. This Privacy by design and default applies to data exchange between a company and its clients as well as its suppliers. Data have to be protected from a bad utilisation (human or software error) as from a 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.”
All protection is made easier if the area to protect is small. The minimisation of collected data as wanted by the GDPR helps to protect data as their number, their storage and the person accessing them are limited to what is strictly necessary.
From a more technical point of view, minimising risks means to reduce technical indications visible on the internet (in the page code source, versions of the third-party components used, error messages …)
Attackers use information found to refine their attack and make them more pertinent (and thus more dangerous).
An online presence of a company has often many channels: official website, sub-domains, test versions, servers, cloud services…
A precise and up-to-date cartography is indispensable to protect the company correctly and the data it has.
Do you know where and how are kept the pre-production versions of your website or API? Are they related/connected to your actual website? How are they protected? Are there other websites potentially vulnerable on the same server? If one of them is damaged, can the attacker reach the other websites? If identifiers are stolen, are they working for other applications or servers?
Be Careful with Third-party Components
At all levels, companies use third-party components: operating system, frameworks, CMS, libraries for the construction of a website…
It is not because those components are developed by other societies 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. This solution is, however, probably more targeted.
Some components have known vulnerabilities, with even online explanations how to exploit the flaw. Attackers are only too happy to have without effort attack scenarios. They will try to exploit them first, before searching for vulnerability specific to your platform.
Vulnerable components are indeed n°9 in the OWASP-Top 10, as they are widespread, usually not too difficult technically to exploit and cause damage possibly important, like denial of service, data theft, or even server compromise.
It is yet no reason to stop using third-party components. Vulnerabilities of third-party components are avoided with a precise monitoring: cataloguing the used components, knowing their functions, keeping them up-to-date and/or patching known flaws.
Planning regular update is indispensable. It is also recommended to follow the news to be alerted quickly if a used component has a new vulnerability published (0day).
GDPR Specific Points of Attention
Article 25 specifies that “[…] by default personal data are not made accessible without the individual’s intervention to an indefinite number of natural persons.”
Two vulnerabilities are meant by this mention:
- Lack of access and control of data users: a user X can access information or files related to the account of user Y,
- Privilege elevation, lack of control of the “functions”: a user can do specific actions normally reserved to admins (create, modify or delete registered elements, etc).
Those vulnerabilities are regularly encountered, they are 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 the data in order to make the platform unusable. Potential consequences are thus quite high.
GDPR emphasizes personal data encryption when they are used as stored. In case of loss or theft, data will be unusable, as not readable without the encryption key. Potential impact of the attack is also 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 has possibly also reached information on the encryption, even if it was stored in a different place.
It is as well as completely probable that the attacker manages to get a decryption key. The important is thus to protect the system globally.
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). And yet, how to fulfil this obligation if one does not know that a breach happened?
A careful consideration should be given to monitor logging. Good settled logs inform on the attempts and angle of attacks, and therefore on the most vulnerable places of the system: which means did attackers use to try to enter? from where did they enter? which elements could they reach? … Monitoring logs is thus very important to strengthen security.
Attackers rely on the lack of control and the detection time to hide their presence and to reach their goal. Insufficient logging and monitoring is n° 10 in the OWASP-Top 10.
To make up this vulnerability, it needs to detect and register unsuccessful access attempts, suspicious activities, attack attempts and to automate alerts for unusual actions. Let us not forget that attackers choose generally to carry out attacks during less accurate supervision (nights, weekends, holidays).
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 has to think of its specific personal situation with its processing and its security stake to adapt the technical measures to set up.
A manual security audit –as those that we offer- can then be run to verify the strength of the information system.
NB : For a more general article on the GDPR, you can read or read again our article “365 days before GDPR: What, why and how to get ready?”