Who is performing computer incident coordination? Ask someone from the computer security world and the answer will probably be CERT/CC. If you are not from North America but instead from the Asia Pacific region, then you might hear JPCERT/CC or AusCERT, while Europeans may add CERT-FI or CPNI. All of these teams, together with your respective national CERT, are the “usual suspects” when computer incident coordination is concerned because they have done such tasks in the past and are still doing them today. Each of these teams has handled the coordination of large incidents where multiple sites were involved. If your site is involved in a large-scale incident, and if your policies allow it, you may consider asking some of these organizations to help you handle the incident.
But each of these teams is also finite in size and their main mandate is not to investigate and coordinate each and every computer incident that is reported to them. These teams will look into all reports sent to them, but they won’t necessarily get directly involved in every incident because they simply cannot scale to coordinate each and every one.
The number of computer incidents handled by the various CERTs and related communities is staggering. And in all of them we find at least two parties involved: a victim being attacked and a source from where the attack is coming. The location from where an attack originates is not necessarily the same location where the attacker resides, because in practically all cases the attacker is using a compromised host. So this means that in most all computer incidents the two parties involved are actually a victim and a victim. This chain of victims can be several layers deep.
Another possibility is that an attacker is using your host to attack several other sites. In a case like this, a CERT would notify owners of the compromised sites and, in some cases, help them handle the compromises in their systems.
Whenever a CERT — any CERT — begins communicating with multiple other sites involved in the same incident, even if there are only three or four teams involved, we’re talking about incident coordination. We do not have to involve 30 teams across four continents to call ourselves a coordinator. The number and distribution of involved teams is not relevant. It’s the functions that the coordinator provides that counts. Incident coordination, in other words, is a function of any CERT.
But incident coordination is not an easy task, as you must keep track of many details and at the same time keep control over who has access to what information. Two tools that exist that are designed to help teams with incident coordination are AbuseHelper and Palantir.
According to its description, AbuseHelper can be used to retrieve Internet abuse handling information (through near real-time sources such as IRC, periodic sources like e-mail, and request/response such as HTTP), aggregate the information based on keys such as AS numbers and country codes, and then send reports in various formats via different transports and timing.
Palantir does not seems to be freely available, but according to a paper, it is described as “… a framework for supporting multi-site collaborative digital investigation and incident response. [Integrating] the two areas of prior work, namely, digital investigation and incident response, by developing models for Roles and Responsibilities as well as Processes that identify their interaction.”
Every CERT must start seeing itself as an incident coordinator and actively nurture required skills to perform incident coordination. Unless there is a contractual or legal obligation to report incidents to a central entity, the majority of incidents can be handled effectively without involving such an entity. The idea that incidents can only be effectively coordinated on a national, regional, or global level is a misconception. In many cases, involving non-affected parties will only slow the process and bring only dubious benefits, if any.
The two previously mentioned frameworks could be seen as starting points from which teams can build their competency. Each team should consider what functions are appropriate for it and then determine how existing frameworks can fulfill its needs. Both frameworks seems open and flexible enough so that you can pick and choose only the elements that you need.
And the next time someone asks who is performing incident coordination, tell them you are.