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 organisation, 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 recognise 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.
Your policy should also address such issues as:
- 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...
For more, click here...
