I was invited to give a presentation on legal and ethical issues around information sharing at TERENA’s recent security services workshop. The talk highlighted the paradox that sharing information is essential to protect the privacy of our users when their accounts or computers have been compromised, but that sharing can also harm privacy if it’s not done correctly. Since there’s increasing interest in automated information sharing, we need to work out rules that we should encode into those systems to ensure that their actions on our behalf do have the effect of improving privacy rather than harming it.
A set of principles seems a good place to start, but the principles written into privacy laws generally assume that individuals can be told in advance what will be done with their information. That may not be possible in network incident response, where an incident response team will often discover indications of problems in a different organisation, network or continent. When you detect an attack, scan or spam coming in to your network, that’s usually a sign that the attacking computer has itself been compromised and that its users have a serious privacy problem. Surveys still suggest that many incidents are first spotted by teams outside the affected organisation. To let incident response teams try to help those external users, my suggested principles are a shorter list, designed to protect privacy even when a team has no way to identify or directly contact the individual victim:
- Necessity: only share information when doing so is likely to help
- Minimisation: only share the information that is needed to provide help
- Accuracy: explain clearly how reliable you believe the information to be
- Security: keep all information appropriately secure, both in storage and in transmission
The first two principles will be easier to satisfy if, when working to protect privacy, we concentrate on sharing information back towards its source where the privacy problem exists. If the source is within our own constituency, we should fix the problem ourselves rather than sharing it! That’s the opposite direction of information flow from the police/court process, where the focus is on finding out who a remote source is and holding them account. Interestingly, “upstream” sharing has significantly more support in data protection law: if you consider an IP address to be personal data and you receive it without prior contact with the owner then the Data Protection Directive requires you to notify them of any further processing. If the source is outside the EEA, the UK Information Commissioner’s observation that processing should address the privacy expectations of those countries, rather than Europe’s, suggests it should at least be no harder to share information back to a non-European source than a European one.
Both the e-Privacy Directive and the draft Data Protection Regulation (Recital 39) recognise preventing and responding to security incidents as legitimate interests: processing that is necessary for these purposes is allowed provided it is not overridden by the fundamental rights of the individual. The Article 29 Working Party has recently documented the balancing process that’s required when using the legitimate interests justification: my paper for TF-CSIRT suggests how to apply that process to the specific situation of sharing information about incidents. Upstream sharing should normally benefit, rather than harm, the individual’s fundamental right to privacy so it should be possible to design sharing processes that satisfy the balancing test. For sharing in other directions the balance may be less clear and sharing may only be appropriate where there is a serious and widespread threat to the security and privacy of others.
The law in this area isn’t as clear as it might be, but using that as a reason not to gather and share incident-related information is no solution. The law is clear that we must to take appropriate measures to protect the security of personal information; the international standard on information security (ISO27002) identifies incident response as one of the key controls needed to do that. Done correctly, incident response shouldn’t be seen as a threat to privacy but a vital tool in protecting it.
