Internet and/or Technology Incident Response Sample Policies & Procedures

In an incident response plan, you want to cover the following topics, at a minimum:

Identify possible "incidents" before you do anything else. This can be done in a brainstorming session, and you can get additional ideas from the Net.

1. Figure out how you can spot critical incidents. Who will be monitoring what?
2. Determine who should get notice of various types of incidents. For example, if your Web site goes down, who should be notified and how. If there is an unfriendly employee termination, who needs to know about it If a laptop is stolen, or a password is compromised, who do you tell.
3. Decide if you can streamline some types of reports by developing report forms and/or checklists.
4. Mitigate damage. Act immediately to control the possible negative consequences of the incident. For example, if a disgruntled employee has just been fired, remove their permissions from the network and any special software they can access. If you use secure modems, remove their IP address and user name/password from the set of permissible accessors. Do not allow them to access their computer or any others within the organization. Try to determine whether it's possible they had access to anyone else's passwords or access rights. If so, force a chance of those passwords. If your network has been infected with a Worm that propagates via email, take your email server down until the worm has been cleaned off your system in order to avoid further spreading it.
5. Bring in outside experts, if necessary, to troubleshoot and contain the problem. You may need computer forensics experts, for example, or you may wish to notify the FBI. If someone has hacked into your customer files, you need to marshal your PR resources.
6. If it fits the definition of "computer intrusion", file a SAR. Identify the systems that have been compromised.
7. Protect the evidence. The Secret Service Web site has excellent guidance on preserving electronic evidence.
8. Restore data from backups, if necessary.
9. Schedule a post-mortem review. Determine what you need to do differently and what you learned from the experience. Make whatever changes need to be made as a result.

First published on BankersOnline.com 10/01/06