Cleaning up after Botnets
One of the challenges in finding an appropriate legal framework for incident response is that for many types of incident you don’t know in advance what information you are likely to receive. Rogier Spoor of SURFnet discussed one of the most common situations – cleaning up after a botnet infection - at the TERENA Networking Conference last month. Although SURFnet’s approach is designed to comply with Dutch, rather than UK, law, it seems a reasonable fit for our legislation too.
Many of those unexpected and rather vague e-mails you receive inviting you to open an attachment or visit a website are trying to persuade you to install a small piece of malicious software, known as a (ro)bot, on your computer. If they succeed then your computer will join thousands of others waiting for instructions from the person who controls the botnet. Bots may be instructed to do many things, including sending spam and launching denial of service attacks; however they are also used to extract information from files, e-mails or user activity on the local machine and send it to some location where the botnet controller can collect it. Sometimes it’s possible for those collections of stolen information to be recovered by incident response teams, who would like to use it to let the owners of the information know what has been taken.
The problem for incident response teams is that they, unlike most botnet controllers, want to act within the law. Depending on where the bots were installed and what they were instructed to collect the information recovered could be anything that was on the infected machines: personal data, credit card numbers, or even medical data. Normally Data Protection law doesn’t allow that kind of information to be handled unless individuals have been informed first, but the incident response team doesn’t know whose information may involved until after it processes it. Fortunately the law does recognise circumstances that require processing before notification, and EU law explicitly says that incident response is one of those. However any handling of information must be for a clearly defined purpose, must be limited to what is necessary for that purpose, and must not involve disproportionate risks to individuals’ privacy.
SURFnet’s original approach was simply to inform their customers that a collection of botnet data had been found and where it could be obtained. However this meant that each interested customer had to download the whole collection (probably including personal data of others) without being able to assess whether their portion of the information was sufficiently important to justify either their own effort or the invasion of users’ privacy.
Following discussions with customers and legal experts, SURFnet concluded that they could perform a useful (and lawful) service by obtaining the collections of botnet information themselves, separating out the information associated with each customer’s IP address range, and then informing each customer which of their IP addresses has had information taken and when. Each customer can then decide, based on their own information about the sensitivity of the information likely to have been present on those machines at that time, whether to ask SURFnet to provide the full data for any or all of their IP addresses. Any information that is not requested before a designated deadline is deleted by the team, though of course it may remain available to the botnet controller. This two-stage approach reduces the amount of processing needed to let individuals learn of data losses, while ensuring that such processing as does take place has a clear and limited purpose. It also fits rather neatly with the fair processing requirement in UK law that anyone who obtains personal data other than directly from the individual must try to inform them as soon as possible.
[UPDATE] Janet CSIRT have published a companion piece on their approach to dealing with botnet data, including some of the technical challenges
