State of the Practice of Computer Security Incident Response Teams ...

• Rule #1: Don’t Panic!
• Rule #2: Document! [Garfinkel 91]
There are myriad reasons to track and record information:
• maintaining an archive of the types of incidents a CSIRT handles over the course of a
year
• identifying and compiling trends and statistics
• keeping detailed information that will be admissible in a court of law (should criminal
investigation of an incident be pursued)
• managing incident workload across staff
• providing reports on the status of an incident or incident report
• identifying work tasks that must be completed for an incident
• handing over an incident to another staff member for completion
• identifying large-scale incidents that might not be apparent when reviewing individual
incident reports
• correlating incident activity across the enterprise
Depending on the mission and goals of a team, these reasons will vary; however, there are
some common bits of data that will be useful to collect no matter what the end goal.
Each CSIRT needs to decide what data should be recorded and tracked. This will help to ensure
that the team is providing effective response services, is meeting any management and
funding requirements, and may also help to determine needed staffing levels.
Many teams recommend starting a log immediately to begin capturing critical information
about a reported activity. Keeping accurate information about the date and time, what has
occurred, who has been contacted, and what actions have been taken or need to be taken all
need to be included in such a chronological log [Mandia 01, p. 31]. This is most important
during times when incident activity is increasing and team members are handling multiple
events or incidents. In the early 1990s, for example, it was not uncommon for the CERT/CC
incident handling staff to be managing anywhere from 20-25 “active” open incidents concurrently.
This collection of assigned incidents could include activity such as
• newly received reports
• on-going interactions with previously reported incidents
• contacting/interacting with other identified sites related to previously reported incidents
• closed incidents that had been reopened because additional activity reports were received
• other types of requests for information
90 CMU/SEI-2003-TR-001