In order to document and respond to network incidents you will need to thoroughly record the details of the problem. Documentation is necessary in order to present the activity to management, and, indeed, will be required should your enterprise decide to proceed legally against the parties responsible. Almost as bad as the incident having happened is the feeling that you have missed some crucial piece of evidence that could help track down and convict the culprit, or, worse, leave your systems open to another attack. The following is a list of essential information to be collected:
- Who completed the form and how he can be contacted.
- What is the incident being reported: equipment failure, software failure, or a security issue like intrusion, inside security breech, denial of service, virus, Trojan, worm, or something else.
- What data was compromised and when. Describe the level of access achieved in the incident.
- What equipment or software was compromised? What actions are necessary to remedy the situation.
- How was the incident first detected: software or audit logs, user query, external factor.
- What symptoms are noticed and how do they affect business operations and systems. Describe specific OS, hardware, applications, IP address, user and group, and other factors affected.
- Are the affected systems still online; are they backed up, and can they still be attacked.
- Is this incident actionable, and what is required to create the necessary documentation for forensics.
A checklist can be very useful, and when complete should be printed, signed and dated not only by the author but by an agreed upon chain of command.
Barrie Sosinsky is president of consulting company Sosinsky and Associates (Medfield MA). He has written extensively on a variety of computer topics. His company specializes in custom software (database and Web related), training and technical documentation.