Flylib.com

Books Software

 
 
 

13.6 Eradication


13.6 Eradication

Once the evidence has been secured, the process of eradication can begin. In some cases, where the entire affected system is being used as evidence, eradication can also mean replacement.

The most pressing issue concerning eradication is that a system that has been compromised in any manner can no longer be trusted. While the incident response team may be confident that it has found the cause of the incident, it is difficult to establish that nothing else has been modified. Thus, the most common method of eradication is either restoring the affected system from a known good backup, or restoring the system from the original media and restoring saved data from known, good backups .

Restoring a system can be time-consuming and troublesome in its own right. Once again, having an incident response plan in place prior to the incident can make this process much easier. During the prevention phase, a common step in prevention is to create a cryptographic hash of all files and executables on a given system. When done during the installation of a system, incident response teams can ascertain with some certainty what has been affected on a system. This is one of the rare exceptions to the "reinstall rule" and may greatly reduce any downtime.

Finally, the recovery phase can begin. This is the process of reintegrating the system into a production network. Ensure that the cause of the incident has been addressed before reintroducing the affected system. This means reviewing the security policy, adjusting any packet filtering rules, reviewing user permissions, and installing vendor patches to the affected systems as required.



13.7 Post-Mortem

Incident response planning is an iterative process. The final step in resolving any incident is the post-mortem analysis. Here, the incident response team must meet and review the cause of the incident, the resolution, and recommend any steps that must be taken to either improve response time in the future or prevent similar incidents from occurring again.

Some things to consider during the post-mortem phase are any additional requirements that the incident response staff may require, such as:

  • Additional training in response time

  • Additional training in troubleshooting or evidence collection techniques

  • Methods of improving team communications

  • Methods of providing additional resources to incident response team in a timely manner

  • Formally requesting changes to security policy as appropriate

The goal is not only to improve the response of the incident response team, but also to document the evidence as much as possible so that similar incidents can be more quickly resolved.

As a last step, the total monetary costs of the incident should be tallied. This includes any loss of data and the estimated value of that data, any hardware damage that may have occurred, and the total cost (in man-power hours) that response to the incident cost.

No matter how thorough your information security document may be, it is essential that proper attention be paid to the steps that will be taken when things go amiss — because they will. Incident response is typically written as a separate part of the overall information security policy because the process of incident response can change without altering the rest of the security policy. Due to its crucial role in the resolution of unforeseen circumstances, the incident response plan is just as important a step to overall information security as the security policy itself, an acceptable use policy, or a disaster recovery document.