A formal process to manage computer incident response

Motivation

From time to time computers served by VT's network are 0wn3d or have copyrighted content. These computer incidences need response by a combination of the IT security office and IT network operations. This process has evolved over many years during the development of global networking. Often times the response takes on a character of the wild west lawman who shoots from the hip.

Unfortunately this process of response has several shortcomings.

A New Response Process

An improved process seems to be indicated. Some qualities of the process are:

Details

Each incident should have the following steps or data collection processes:

  1. Complainants: The complainants and their complaints should be registered. The complainants may also offer logs and other information as evidence. This evidence should be filed separately in the evidence section. Each complainant should be marked with their preference for receiving updates about the response, also some information about the incident may be sensitive and it may not be appropriate to share with all complainants.
  2. Subject System Operator(s): The administrator or party responsible for the subject system must be identified. In some cases, multiple administrators or parties may be identified. For RESNET, exact information about the operator may not be known (i.e. all roommates in a particular residence hall room.) For non-resnet cases, the initial point of contact is the network liaisons.
  3. Identity: The identity of the subject system should be verified. Often the complainant will only identify a subject system by IP address or domain name. We need to verify that this address isn't being spoofed (i.e. ARP mapping shouldn't be flapping over recent history.) We cannot have perfect knowledge here.
  4. Evidence: Evidence may be offered by the complainant as logs. Evidence should also be collected independently by VT IT staff. Evidence should be independently verified. Evidence may take any form including the following:
  5. Threat checklist: A determination of the type of threat should be made by VT IT staff. The type of threat AND the type of system (university owned vs. privately owned) will determine the mitigation process and timeline to be followed. NOTE: any mitigation timeline starts from when we are notified of a problem, not from when the determination of type of threat is made.
  6. Response Status: This includes all the mitigation actions that have been performed and that are currently active. The response to an incident ends when the machine in cleaned up (verification by the subject system operator with perhaps independent verification) and all mitigation actions have been un-applied.

Mitigation

Various actions that can be performed in response to an incident

The timeline for mitigation response and the mitigation actions to perform need to be defined for each threat type.

Threats

Leftovers

Some stuff that needs to be moved to other sections.



From Marcus J. Ranum: Marketing.