Two common concerns in incident response are (a) not having the data needed to investigate an incident and (b) not being able to find signs of incidents in a mass of other data. My Networkshop talk (see “Making IT Safer… Safely”) looked at how the GDPR principles might help us to get it, like Goldilocks’ porridge, “just right”.
- First, write your incident response (IR) process(es). How am I going to detect a (possible) incident? What will I do when that happens? This helps towards the GDPR principle that processing should be Lawful and Fair: and also means that your documented IR process will be quick;
- Then think what data and sources those processes will need, make sure you know where those are and that you can access them quickly when needed. For the GDPR Data Minimisation principle that tells you which data and sources you don’t need: on the IR side it means the ones you do need should be ready to hand;
- Then think how long after an incident it is realistically possible and worthwhile to conduct an investigation, rather than simply wiping the affected machine and restoring it to a more secure state. You’ll often need external information to interpret your logfiles: what was the network and system configuration? What vulnerabilities existed and were being exploited? Once those data no longer exist an investigation is likely to be hard work. Also, once an intruder has had access to a system for months, they’ve had ample time to do damage and conceal their traces. How much of the logs can be trusted? Getting rid of logfiles that are too old to be worth investigating addresses the Storage Limitation principle: it should also reduce the size of the Incident Detection haystack;
- Keeping logs secure should be obvious, but the same needs to apply to the tools used to access them. Both are a goldmine for any intruder. Security is both a GDPR principle and an IR obligation;
- Automating at least the early stages of incident detection is another win-win. Data Protection law has long recognised that having a computer, rather than a human, look at personal data can contribute to Process Minimisation and reduce intrusiveness: from the IR side, having a machine group logfile “events” into security “alerts” reduces tedium and lets humans get on with what they are best at. Incidentally, I’ve also been finding some guidance on automation in draft AI laws.
- One of the legal advantages of incident response is that most of the identifiers we deal with (IP and MAC addresses in particular) are what GDPR refers to as pseudonyms: they don’t directly identify an individual but require an additional step (such as looking at DHCP and authentication logs) to do so. Postponing that lookup process until we are pretty sure that an incident has happened and that there are victims in need of help, contributes to GDPR Purpose Limitation and delivers the benefits of IR to those who need it most.
Once you’ve developed your process, it may be worth checking it by conducting a more or less formal Data Protection Impact Assessment. We are doing these regularly for the Janet Security Operations Centre, who are finding them a really useful way to think about their work (so much so that they asked to do them more often!). We also publish the results, which we hope will reassure users of the network that, yes, we do process a lot of personal data, but that’s necessary to protect you and we work hard to ensure we do it as safely as we can.
