Creating an Incident Response Checklist
Let’s face it; a computer security incident can occur at any time.
Whether it’s the result of a networkwide malware infection, the work of a malicious hacker or a trusted employee with an ax to grind, the first response — as in any critical situation — is an assessment of the incident. Only after you know the specifics can your company’s response team put a stop to the crisis, contain the situation and mitigate further damage to your systems.
A computer security incident response checklist is an overall guide that lets your team efficiently recover from security incidents. The checklist helps organizations bring together a staff (each employee with their own specialties) to respond effectively during a security crisis. The checklist lays out the steps, policies and procedures for handling a security incident while maintaining critical computing services — at least to the extent possible — as well as protecting data (critical or otherwise) from further tampering and/or theft.
Other departments within the company, law enforcement and information security organizations should all be notified of the extent of the security incident’s damage. Notification will let those organizations use information from your incident to adjust procedures and response recommendations. The incident response checklist will also aid your organization’s legal action if you choose to pursue one.
The Written Policy
To be effective and ensure that personnel fully understand your company’s contingency planning parameters, a clearly defined written policy must be made available to them. The policy needs to define the company’s incident response objectives as well as establish the framework for incident response planning. To succeed, support for contingency planning must come from all areas of management right up to the CIO. The reason is simple: Personnel need management approval to drop whatever they’re doing so they can respond immediately to an incident.
First Things First
Although adequately staunching an incident is laudable, it’s best to anticipate crises before they occur. An incident response checklist presumes that an incident will take place — one for which your organization will be prepared. The plan should cover each stage of the response process, including getting the infrastructure ready from the outset, as well as incorporating into your checklist any new knowledge gleaned from the experience of a previous incident. Let’s face it, nearly all organizations today rely on the smooth operation of their information technology assets and any event, whether planned or unplanned, can bring operations to a halt.
Ensure Contact Info Is Current
When creating your checklist, the initial goal is to identify all incident response team members. Make sure that your contact information such as phone number, cell, pager, e-mail, etc. is up-to-date. Ensure that any external IT monitoring services have your current contact information. Your next step is to provide all employees with written incident response procedures. You’ll want to create backup tapes and, if convenient, have them stored off-site for added protection. Next item is to test battery backup and emergency generators for proper operation. You’ll want to do this periodically since you will have little time for it once an actual incident occurs.
Incident Response Procedure
Once a suspected security event is detected, the response plan is immediately set in motion. IT and all other units must be alerted at once. The first priority is figuring out if any company resources (or even external resources) are in jeopardy as a result of the system compromise. Subsequently, your team must determine if malicious processes that threaten data on the system have been set in motion and are still running.
If it’s determined that a tainted system could possibly threaten external systems or other important business purposes or utilities, then they must be immediately removed from the network. Sometimes all it takes is simply unplugging an Ethernet cable to physically isolate a system. Routers and firewalls can also isolate the system. If a substantial loss of data appears imminent because of a malicious attack, the team should be prepared to completely disconnect the system from its power source.
The next step is to follow company emergency response procedures and conduct a preliminary damage assessment. If the impact is severe enough, your team will set in motion the recovery portion of the response procedure. Your objectives should include a list of recovery strategies and an action plan. Items on this list would include the notification of incident response team members and, if necessary, the notification of any third-party business continuity and disaster-recovery service providers, if you are a subscriber.
To be effective, the incident response plan must be maintained and kept in a constant state of readiness. Periodic assessment of your IT inventory, system requirements, policies and procedures is necessary as systems undergo frequent change to support shifting business needs. Be sure that new IT assets are documented and contingency measures revised if required. Certain items, such as contact lists, will likely require more frequent reviews.
List Your Recovery Strategy
The last item on the list should include your recovery strategy. Recovery strategies provide your organization with the means for restoring IT operations quickly and effectively following a disruption. Strategies should address disruption impacts and allowable outage times. Several alternatives should be considered when developing this strategy such as cost, outage time and security issues.
Many organizations do not prepare sufficiently to deal with computer or network intrusions and often address incident response only after they’ve experienced a breach. The sad fact is, even with sophisticated security and prevention measures in place, incidents still take place. The best defense is a good offense, so having an incident response checklist available and in place will help you get your ducks in a row when the time comes.
Detailed reports of the actions your team has taken in response to incidents will not only benefit your organization, but federal regulations require that those responses (in an audit format) be reported. Answering the following questions will help make compliance easier.
- How were security measures circumvented? Which specific vulnerabilities were targeted? How did your organization learn that an incident had occurred?
- When did the security incident occur? Compare this time with the time when the incident was detected.
- What tools did the intruder use to gain access? What kind of data was exposed to the hacker (classified, unclassified), and what did the intruder do with it (steal, delete, modify)? What is the result to the organization (and perhaps its clients)? What programs have been installed on the system by the hacker (keystroke loggers, sniffers, other data collection programs)? To what level of access did the intruder gain admission? And, what measures have been adopted to thwart future incidents?
- Who set the incident in motion? Determine the identity of the party through examination of the Internet Protocol address and/or host name. Compare the identity information against the Energy Department’s Sensitive Countries list (http://www.ch.doe.gov/
offices/OCI/ SensitiveCountries/index.htm) to see if a user from a listed country may be involved and, if so, make the necessary notifications.