Is your incident response plan scalable?

by Deb Shinder | Oct 24, 2005 7:00:00 AM

Tags: SECURITY, NETWORKING, HereÂ, Deb Shinder, incident response plan, network, attack, incident response policy, SMB Strategies Newsletter

Takeaway: You may not have ever considered scalability in regard to your incident response plan, but it's important to have IR policies and an IR team that can adapt to organizational growth and to the severity and scope of each incident.

Most enterprise-level businesses and many medium-sized ones have taken a proactive approach to computer and network security and created incident response teams to streamline the handling of an intrusion or attack. You may not think about scalability in regard to incident response, but a good incident response strategy needs to be scalable in several different ways:

• The incident response plan needs to be effective and efficient whether the incident is relatively minor, such as the defacement of a single Web site, a large scale attack that threatens to bring down the entire multi-site network, or something in between.
• The incident response plan must take into account future growth of your organization, and you must be able to adapt the plan as the number of users, network bandwidth, and number of physical locations changes.
• The incident response plan should contain contingencies for changes in the network infrastructure, hardware and software, and services (such as Internet service provider) that may cause new vulnerabilities and affect the mode of response.

There are two important elements that make up your incident response strategy: the policy and the team that carries it out.

Creating and developing the incident response policy

If you're creating an incident response policy from scratch, you can ensure that scalability is built in by thinking outside the current box and anticipating the state of your network -- and new technologies and vulnerabilities that may not even exist yet -- a year, five years, even ten years from now. Even when you’re considering current response, think big.

Here’s what we mean: instead of writing into the policy document that the response team will consist of five members, identify the number of different roles that you need members to play. In the future, a role that can be handled by one person now may require several people to carry out its tasks if your network grows large and spreads to multiple sites, or if an incident affects hundreds of your computers instead of only a few.

Your incident response policy should contain broad procedural guidelines that are applicable to all (or at least the great majority of) security incidents and cover the following steps:

• Incident recognition: the first step in responding is to recognize that a security breach has occurred or is in the process of occurring.
• Containment: The next step is to stop the attack or reduce the attack surface (for instance, by isolating the server or network segment on which the attack is occurring or taking it offline completely).
• Identification: At this point, you can begin to investigate and identify the exact nature of the problem, something that may be impossible while you’re in the process of containing the damage.
• Eradication: Next you need to patch the vulnerability or otherwise prevent the problem from occurring again.
• Recovery: This step involves getting affected systems back up and running, reinstalling software, restoring lost data, or whatever needs to be done to recover from the incident.

• Whether, when, and how to call in law enforcement
• Preservation of evidence and maintaining a chain of custody
• Information flow before, during, and after an incident
• Post-incident assessment/evaluation of the response

The policy should also define the scope of the response team's services. Obviously, the team will respond to security incidents, but some teams are also responsible for risk analysis and management before the fact, and security audit and follow-up after the fact. In some organizations, the team’s responsibilities even extend to development of security tools and training other members of the organization in security awareness.

Creating and developing the incident response team

A computer incident response team is, in many ways, patterned after other emergency response teams. Each member of the team should have a specified role and there should be a division of responsibility that’s clear to all members, but it’s also helpful if each is cross-trained in the tasks normally performed by others.

The team members should train together and practice their response to realistic scenarios until everyone is able to work together smoothly and quickly, without stepping on one another’s toes.

Despite the "team aspect," there should be a designated line of authority, and everyone should follow that chain of command in making important decisions (such as shutting down a vital server in the middle of a busy workday). The team manager or leader should the authority to take actions that may impact the budget or disrupt the flow of business.

Team members should be selected based on their areas of expertise and interest. For example, a medium sized team might have one member who is a subject matter expert in each of the following areas:

• Firewall/perimeter security
• Operating system security
• Application security
• Computer forensics
• Legal
• Reporting/record keeping
• Recovery

Growing the team

In a small organization, your incident response team might initially consist of one person. The function may not even be part of a title or job description; he or she has just evolved into the one everyone calls if there’s a security incident. As the organization and the number of security incidents grows, the team can become a more formal entity, with members selected according to set criteria.

Team members are obviously selected for their technical expertise, but also for characteristics that may be less obvious, such as physical location in the organization (giving them the ability to respond quickly) and availability/willingness to respond after hours (which is when most incidents occur).

Outsourcing the service

An alternative to creating your own in-house incident response team is to subscribe to a commercial incident response service. For a small organization, there’s an obvious advantage to this approach if you have no one on staff who has the level of expertise required. Even in a large company with a big IT staff, your team’s incident response experience can’t be nearly as comprehensive as that of specialized personnel who do nothing else and who respond to incidents in many different environments.

Commercial services may be especially effective in conducting forensics examinations and handling evidence so as to build a criminal or civil case in court. Hiring an incident response service may also be more cost effective than maintaining full time security experts on staff.

Finally, you may find that a service can provide more flexibility and better scalability, since the service can deploy its personnel based on the severity and scope of a particular incident.