Regulatory Developments

As well as looking at some of the legal issues around sharing information among incident response teams, earlier this month I was invited by the Janet’s Portugese equivalent, FCCN, to talk on the practical issues at their national CERTs conference in Lisbon. I was one of three speakers on the topic: since the others work with banks and telecommunications companies I had expected there to be quite a bit of difference. However our conclusions, without any prior discussion, were astonishingly similar. I just hope our hosts felt that was reinforcement of the message, rather than unnecessary repetition!

The invitation prompted me to look at the many information sharing activities I’ve seen in nearly 13 years’ working in and with the CERT community, and to try to identify the common features that the successful ones shared and that were missing from the unsuccessful ones. My impression is that nearly all the successful ones started out with the aim of creating a community and then developed information sharing activities within that community, whereas the others had the objective of “sharing information” and generally failed to achieve it. It seems that information sharing – whether the information is about tools, approaches, intelligence or incidents – develops naturally among people with common interests after they have established a mutually trusting community.

So if you want to promote information sharing, establish a trusting community. But that needs more than just getting people into a room. In discussion I heard an excellent summary: “trust is formed between individuals, based on agreements”. So as well as a group of people you need some sort of agreement  on  how anything they say will be handled. One common choice among CERTs is the traffic light protocol – red means that information is only for those in the room, amber allows it to be shared on a need-to-know basis with other members of their teams and constituencies, green allows it to be shared outside the team but not published and white is unrestricted. Frequent reminders of the protocol (for example at the start of each meeting, or on messages exchanged) are a good idea both to reduce the risk of mistakes and to build confidence that the rules of the group are being respected. Mention of confidence points out the second success factor: that the individuals within the group need to feel that it’s a safe place. That’s a human thing and, unfortunately for those who expect instant results, it takes time to develop. And it’s likely to be hindered if the membership of the group changes frequently – so try to make sure the same people attend a series of meetings – or if there are individuals in the group who don’t seem to be contributing.

Once the community has established itself, information sharing is likely to start spontaneously, often by someone asking if anyone else has had the same problem as them or by mentioning an area they’d like to work on. Each question answered or idea developed should increase the group’s instinctive feeling that sharing brings benefits and is not harmful, which should allow them to move to discussing larger or more sensitive issues. Group members don’t need to all contribute the same thing – if I have an idea and you can communicate it to people I can’t influence then we both benefit – but everyone does need to contribute something, otherwise members are likely to become suspicious of the silent participants and trust will be eroded. Groups (or subgroups working on particular topics) shouldn’t be bigger than they need to be – the idea that every organisation must be represented on every group should be resisted.

Finally, there are a few examples of successful information sharing groups that did form specifically to address a single issue. Mostly these were established around problems that were so clearly urgent that the need to collaborate overrode the risks. Two good examples are the Conficker Working Group and the group formed around the DNS Sequence Number vulnerability in 2008. It’s interesting that in both cases, once the urgent problem had been contained both groups seem to have worried about how long they would be able to continue without that incentive. The lessons learned paper published by the Conficker Group provides an excellent guide for anyone setting up an information-sharing community.

I had an interesting discussion last week with Thorsten Kraft of the German ISP association, eco, on how German network providers cooperate to help reduce the number of their users’ PCs that are infected with malware. The UK Government has recently added this as an aim in our national Cyber Security Strategy so the German example may be particularly relevant.

Users who are likely to have a problem can often be identified just by looking at logfiles of attacks against the ISP’s own systems. For example most PCs only make e-mail connections to the authentication host (smtp auth) of the mail sending infrastructure of their ISP and maybe one or two other organisations (such as universities) where users may have mailboxes. A PC that also makes e-mail connections to the ISP’s mail receiving servers (mx) is very likely to be part of a botnet sending junk messages under the control of a spammer.

A commercial ISP that detects such a pattern in its logs faces a number of problems. If they notify the affected customer to warn them that the contents of their hard disk and anything they type is also likely to be accessible to whoever controls the malware then they are likely to end up with a series of expensive helpdesk calls: a strong incentive not to report the problem when one call can cost more than the ISP’s annual profit from that customer. German ISPs have also found that unsolicited contacts mentioning security problems are often mis-interpreted as attempts to sell anti-virus or premium service packages and ignored!

To address these problems, and help ISPs to help their customers, eco have established a central website that takes customers through the three steps of Informing them about botnets, Cleaning any current infection using a choice of free downloadable scanners, and Preventing future problems through a combination of technical settings and tools and user awareness. Customers who are informed of problems by their ISP can also call a central telephone hotline if they need help resolving them. As the number of infected customers decrease, ISPs benefit in terms of reputation and also financially from the reduction in traffic on their networks.

Results are impressive – the site has had seven hundred thousand visitors, about half of whom had been notified by their ISPs. The scanners seem to have dealt with the vast majority of the problems: there have been nearly a million downloads, with less than 1% of visitors calling the hotline for an average of 11 minutes each. The German government provided initial funding with the objective of getting Germany out of the top ten most infected countries on the Internet (according to internetworldstats.com Germany is the sixth largest country in terms of Internet users). While the service has been in operation Germany has in fact dropped from second to eighth in terms of infection, so is now better than average for percentage of infected users.

There seems to be a shift in how Governments and rightsholders are looking to use Internet intermediaries, such as ISPs, to enforce Intellectual Property Rights (IPR) on line. For some time the focus has been on looking at the content of network traffic in order to detect infringing copies – in Belgium a court went as far as ordering an ISP to install content inspection appliances, while in other countries including France, the UK and Ireland the Government has either imposed or encouraged schemes where ISPs are required to respond to information obtained by rightsholders through their own monitoring of content flowing on networks.

Although the content inspection approach hasn’t gone away (though both the Belgian and Irish examples have recently been challenged), most of the activity by both Governments and rightsholders now seems to relate to using intermediaries to prevent access to particular locations where infringing content is published. Thus in the UK the Copyright, Designs and Patents Act 1988 has been used to obtain a court order requiring BT to add the URLs of the Newzbin website, in Ireland the absence of such a power has been identified and challenged and in Spain new blocking legislation has been proposed. Various legislative proposals in the USA also seek to interfere with users’ ability to access sites identified as infringing IPR.

I wonder whether the reason for this change may be similar to the European Court of Justice’s (ECJ) analysis of the Belgian order on content inspection, which concluded that state action to inforce IPR must consider three possible side-effects: the cost to intermediaries of implementing the state’s requirements, whether those requirements would also hinder lawful communications by Internet users, and whether those requirements would represent an interference with those users’ right to privacy. The Court didn’t prohibit such side-effects, but did require that they be proportionate in view of the likely benefit to Intellectual Property Rights. When a requirement to implement content inspection was considered against these tests, the side-effects on other communications, on users’ privacy and, in particular, on the cost to the ISP, were considered too high. Interestingly, even though the ECJ judgment had not been published at the time, the judge considering whether to require BT to block URLs looked at the same three issues, found that all three side-effects were much less and therefore that this order was, indeed, proportionate.

The common theme here seems to be a recognition that cost, over-blocking and privacy invasion are all undesirable side-effects that need to be taken into account, and that blocking particular locations may raise fewer concerns than content inspection. It will be interesting to see whether the same analysis is applied to other technical approaches to blocking (for example by manipulating routing or DNS resolution, both of which have a higher risk of over-blocking than URL blocking).

Incidentally the ECJ ruling only applies to IPR enforcement systems imposed by the state: it doesn’t prohibit a network operator from installing a content inspection system – whether for IPR enforcement or other traffic management reasons – on its own initiative. However since the privacy and over-blocking concerns were explicitly derived from the European Convention on Human Rights it’s probably still a good idea to ensure that such systems are designed and operated in a way that reduces interference with those rights as far as possible.

Over the past few months I’ve been working with UCISA’s Networking Group to develop a set of standard templates that Janet customer organisations can use, if they wish, to respond to copyright infringement reports. This supplements Janet’s existing guidance on how to handle copyright complaints in accordance with the Janet AUP. We hope that this will save organisations some effort in writing their own replies; it should also give rightsholders clarity that their reports have been dealt with or, if the report was insufficient to allow action to be taken, explain what they need to do to make future reports effective. There are three templates, reflecting the three most likely outcomes of a report:

• The responsible user has been identified and dealt with in accordance with the Janet AUP;
• The information provided was insufficient to reliably identify the responsible user;
• The information provided does not match our records (e.g. of authentications or traffic flows).

Although the templates were written for use in e-mail messages, we hope they are also short enough to be pasted into the web forms that some reporting agencies use for responses.

Responding to copyright infringement reports is, of course, covered by the Digital Economy Act 2010. However we don’t expect Janet or its customer organisations to fall within the class of Qualifying ISPs who are required to follow the Act’s processes. Nonetheless, in the interests of clarity for rightsholders, our template notices do follow the spirit of the draft implementation Code that was published for consultation in May 2010. When the final version of the Code is published, we’ll review the templates to see if any changes are required.