Incident Response and the Law
At the FIRST conference this week I've heard depressingly many incident responders saying "our lawyers won't let us...". Since incident response, done right, should actually support the law's objectives, it seems we need to be smarter, and maybe a bit more assertive, about explaining how incident response and law interact.
The laws most relevant to incident response activities are those regulating unauthorised access to computers, unauthorised access to communications, and privacy. However hacking, information "theft" and privacy breach are the most frequent incidents that we are called on to defend against. It seems that the same laws that say it's important to defend against incidents are also the ones that are alleged to be stopping us doing just that!
For longer-standing members of the incident response community, this may sound familiar. When computer misuse laws first appeared, many struggled with the fact that the same tools that system and network managers use to find vulnerabilities in their own systems were also used by "hackers" to break into them. Most laws did eventually get the hang of these dual-use tools and recognise that the same actions might be legitimate or unlawful, depending on how and why they were done. It seems we may need to help lawyers and legislators do the same for incident response activities.
The first step is to investigate the basic requirements of your own laws on privacy, computer access and interception. What do they require for an action to be lawful, rather than illegal? In many cases that will involve having a good reason for what you are doing, doing the minimum necessary to achieve that, and informing users of the system what may happen and why. Some laws also consider your motivation and what authorisation you have. Then design your security and incident handling processes to get as close to that as you can (you are probably already doing a lot of it, as good security practice, anyway), and write down how you address each of the law's requirements.
Next look at the threats that the law intends to protect individuals and computers from: for example unauthorised access to their data or communications, unauthorised modification of information, or invasion of their privacy. Work out how your security and incident response plan contributes to protecting against those threats. As was pointed out by Malcolm Harkins earlier in the week, security and privacy should reinforce each other, it's only when either is taken to extremes that they become mutually destructive.
Once you have documented how you are protecting your users from the threats the law is concerned with, and what measures you are taking to avoid becoming a threat yourself, then you’re ready to talk to your lawyers. But don’t say "can we..?": a much more productive approach is "this is what we need to do, this is why we think it’s lawful, can we do better?". If they point out areas where you might improve, then see if you can implement those. If you can't then compare the risks that your activities are creating for your users and your organisation with those they will be exposed to if you don't do security and incident response. A user whose malware-infected computer is being remotely controlled by an attacker who can see every file and keystroke, listen to the microphone and turn on the camera is in a pretty awful privacy situation. Privacy-respecting security and incident response that can reduce the risk of such breaches, and detect and respond to those that do occur, has to be a good thing.
In fact European law already recognises that organisations have legitimate interests that may justify the processing of individuals' personal data. The amended Telecommunications Privacy Directive recognises that those include "include preventing unauthorised access to electronic communications networks and malicious code distribution and stopping 'denial of service' attacks and damage to computer and electronic communication systems" (Recital 53). The Article 29 Working Party has recently published a guide to performing that balance of interests; some time ago I wrote a paper for TERENA suggesting how incident response teams could ensure their activities created more benefit than harm. In my discussions with Data Protection Regulators I've been pleasantly surprised how aware they were of the role of security monitoring and incident response in protecting the privacy of internet users. Make that case clearly and you may find there is less resistance than you expect.
