The first step has been taken. One year after the General Data Protection Regulation (GDPR) came into force, data breaches and compliance are on the radar of most of the private and public sector. Regarding awareness, the regulation can therefore be called a blessing. However, we cannot just sit back and relax. A fact that our incident response department is very much aware of.
This department functions as a kind of digital fire department. We deal with hacks, see state actors (governments that hack) pass by and do other big things, whereby hackers have invaded a corporate network. If we assume that every hack is basically a data breach, then GDPR often applies. The striking thing is that in 50 percent of the cases a data breach is noticed by people outside the organization. More worrying is the fact that this happens on average one hundred days after the leak has occurred.
This shows that compliance and security are not the same. In our daily work, we see that many organizations have their GDPR paperwork in order. The procedures are written out and the boxes are ticked. However, for converting this to the prevention and handling of security incidents, more is needed and many organizations recognize that. But …. where to start?
Ideally, you ensure that all sensitive information is “secured by design”. In practice this proves to be very difficult, because a complete IT architecture has already been set up and the budget often does not allow a rip and replace to completely integrate information security with IT.
The first step to better protect your sensitive information is to find out where the crown jewels are. What sensitive information is present within the organization and where is it stored? Questions that an organization must ask itself are: “If a major security incident happens, what do we do?” And “How do we find out sooner?”
The answer to those questions must be recorded in an incident response plan. In addition, an incident team must be put together to ensure that the steps in the plan are followed. Before and while making the plan, you must at least take the following into account:
- If sensitive data is stored at a third party, then we see in 60 percent of the cases that there are no clear agreements in the SLA about who responds when in the event of a data breach. As a customer, you do not want to hear that you will be the first on Monday, while you have been hacked on Friday evening. So, it is certainly worth to look at this carefully.
- Organize the logging of your systems and test this. To investigate the cause and impact of an incident, you must have insight into which log information is required to investigate the various scenarios. Without this data, you can often not exclude anything: which data has been leaked and which have not, which systems have been hacked and which have not been hacked. This is very important for reporting to the Dutch Data Protection Authority (AP) and to those ultimately involved. Keeping in mind that exclusion is almost never possible; without evidence, you must assume that all information has been leaked.
- Ensure that your backup systems are tested so that you can roll back to the situation before the incident and that the operational consequences of a data breach can be kept to a minimum.
- Educate people on cyber security awareness: is your IT staff trained to recognize a data breach? Can they secure evidence? Can they make decisions in the incident response process?
- Determine who will handle the incident response. Do you have your own team of in-house experts or do you rely on an external party (Fox-IT)? Hiring an independent party could have benefits in reporting to the AP. Also evaluate each incident afterwards and record the lessons learned so that you can improve the process.
- Consider investing in measures to detect incidents faster, for example by using an intrusion detection system (IDS) or a security information and event management platform (SIEM). Also determine whether you want to do this yourself or outsource. If you do it yourself, in addition to an IDS or SIEM, you also need the right people to operate them and properly interpret the output.
Finally, I would like to argue in favor of being as transparent as possible about data breaches. This concerns what we call “responsible disclosure”; determine for each situation what the risks are of disclosing information. The fear of reporting data breaches due to possible sanctions or image damage is understandable, but not entirely justified. After all, there is more than just your organisation. By sharing information about the leak and the way you have addressed the solution, you maintain customer confidence. In addition, it offers the possibility of structurally improving the security of confidential data.