5 The Security Incident Response Team Template

Top - Help

Copyright(c), 1996 - Management Analytics and Others - All Rights Reserved


This material which follows is addressed to those responsible for Security Incident Response Teams.

5.1 Template Updates

Details of an IRT change with time, so the template must indicate when it was last changed, who will be informed of future changes, and (by implication) who will not. Without this, it is inevitable that misunderstandings and misconceptions will arise over time.

5.1.1 Date of last update

This should be sufficient to allow anyone interested to evaluate the currency of the template.

5.1.2 Distribution of Template Updates

Persons on this list are notified automatically whenever the template is changed. The list might normally cover the constituency and immediate Partner IRTs. Readers not on the list can then recognise that they should check the central repository (above) for possible updates.

Digital signatures should be used for update messages sent by an IRT to those on its distribution list.

5.2 Charter

Every IRT must have a charter which specifying what it is to do, and the authority under which it will do it. The charter should include at least the following:

5.2.1 Mission Statement

The mission statement should focus on the team's core activities, already stated in the definition of an IRT. In order to be considered a Security Incident Response Team, the team MUST provide incident response, by definition.

The goals and purposes of a team are especially important, and require clear, succinct definition.

5.2.2 Constituency

An IRT's constituency (as defined above) can be determined in many ways. For example it could be a company's employees or its paid subscribers, or it could be defined in terms of a technological focus, such as the users of a particular operating system.

The definition of constituency should create a perimeter around the group to whom the team will provide service. The policy section (below) should explain how requests from outside the perimeter will be handled.

Constituencies might overlap, as when an ISP supports an IRT, but delivers services to customer sites which also have IRTs. The Authority section (below) should make such relationships clear.

People within the constituency have to learn that there is an IRT for their purposes; the building of a trusted relationship with the constituency is an on-going process which never ends.

5.2.3 Sponsoring organization / affiliation

The sponsoring organization, which authorises the actions of the IRT, should be given next. Defining the affiliation amounts to stating: "Who is your God?".

5.2.4 Authority

IRTs may not have authority to intervene in the operation of all the systems within their perimeter. They should identify the scope of their control as distinct from the perimeter of their constituency; if other IRTs operate hierachically within their perimeter, these should be identified.

--- (Responsibility should be covered here) ---

5.3 Policies

5.3.1 Types of incidents and level of support

The types of incident which the team is authorised to address and the level of support the team will contribute in assisting with each type of incident should be summarized here in list form. The Services section (later) provides opportunity for more detailed definition.

The team should state whether it will act on information it receives about vulnerabilities which create opportunities for future incidents. A commitment to act on such information on behalf of its constituency is regarded as an optional pro-active service policy rather than a core service requirement for an IRT.

5.3.2 Co-operation and interaction with other organizations

This section should make explicit the related groups with which the IRT interacts:

5.3.3 Reporting and Disclosure

The default status of any and all security-related information which a team receives can only be 'confidential,' but rigid adherence to this makes the team a 'black hole.' Its template should define what information it will report or disclose, to whom, and when.

Different teams are likely to be subject to different legal restraints requiring or limiting disclosure, especially if they work in different jurisdictions. Each team's template should specify any such restraints, both to clarify users' expectations and to inform other teams.

Conflicts of interest, particularly in commercial matters, may also restrain disclosure by a team; the present Draft does not recommend on how such conflicts should be addressed.

An explicit policy concerning disclosure to the Press can be helpful, particularly in clarifying the expectations of an IRT's constituency.

'Disclosure' includes:

The reporting and disclosure policy should make clear who will be the recipients of an IRT's reports in each circumstance. It should also note whether the team will expect to deal through another IRT or directly with a member of another constituency over matters directly involving that member.

A team will normally collect statistics. If they are distributed, the template's reporting and disclosure policy should say so, and should list the recipients.

5.3.4 Communication and authentication

Methods of secure and verifiable communication should be established. This is necessary for communication between IRTs and between an IRT and its constituents. The template should include public keys or pointers to them, including key fingerprints, together with guidelines on how to use this information to check authenticity.

At the moment it is recommended that every IRT have, as a minimum, a PGP key available, since PGP is available world-wide. Teams may also make other mechanisms available, for example PEM.

For comunication via telephone or facsimile an IRT may keep secret authentication data for parties with whom they may deal, such as an agreed password or phrase.

5.4 Services

Services should be defined in two sections, as listed below.

5.5 Incident reporting Forms

Samples of reporting forms used by the IRT (or pointers to them) should be included at this point in a template.

5.6 Disclaimers

Although the template does not constitute a contract, liability might conceivably result from its descriptions of services and purposes. The inclusion of a disclaimer at the end of the template is recommended.

It should be noted that some forms of reporting or disclosure relating to specific incidents or vulnerabilities can imply liability, and IRTs should consider the inclusion of disclaimers in such material.

In situations where the original version of a template must be translated into another language, the translation should carry a disclaimer and a pointer to the original. For example:

Although we tried to carefully translate our German template into English, we can not be certain that both documents express the same thoughts in the same level of detail and correctness. In all cases, where there is a difference between both versions, the German version is the binding version for our operation.