Information Sharing Communities

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.