21.3 Incident Response Framework

To build an initial incident response framework, we can use the SANS Institute's six-step incident response methodology. The methodology includes the following steps for dealing with an incident:

1. Preparation

2. Identification

3. Containment

4. Eradication

5. Recovery

6. Follow-up

The actions defined by the plan begin before an incident transpires ( extensive preparation steps) and extend beyond the end of the immediate mitigation activities (follow-up).

21.3.1 Preparation

The preparation stage covers everything that needs to be done before an incident ever takes place. It involves technology issues (such as preparing response and forensics tools), learning the environment, configuring systems for optimal response and monitoring, and business issues such as assigning responsibility, forming a team, and establishing escalation procedures. Additionally, this stage includes steps to increase security and to thus decrease the likelihood of and damage from any possible incidents. Security audits , patch management, employee security awareness programs, and other security tasks all serve to prepare the organization for the incident.

Building a culture of security and a secure computing environment is also incident preparation. For example, establishing real-time system and network security monitoring programs provides early warning about hostile activities and helps in collecting evidence after the incident.

A company-wide security policy is crucial for preparing for incidents. This policy defines the protection of company resources against various risks, including internal abuse and lawsuits. Often the policy must satisfy the "due diligence" requirements imposed by legislation onto specific industries (such as HIPAA for healthcare and GLBA for the finance industry). A separate incident response policy, one that defines all the details of the response process policy and assigns the incident " owners ," might be needed to further specify the actions that have to be taken after a security incident. Such a policy contains guidelines that will help the incident response process to flow in an organized manner. The policy minimizes panic and other unproductive consequences of poor preparation.

21.3.2 Identification

Identification is the first step after an incident is detected , reported by third parties, or even suspected. Determining whether the observed event does in fact constitute an incident is crucial. Careful record keeping is very important, since such documentation will be heavily used at later stages of the response process. You should record everything observed in relation to the incident, whether online or in the physical environment. In fact, several incident response guides mandate pictures of the compromised systems and the environment in which they are used. Increased security event monitoring is likely to help at this stage by providing information about the chain of events. During this stage, it is important that the people responsible for handling the incident maintain the proper chain of custody. Contrary to popular belief, this is important even when the case is never destined to end up in court . Following established and approved procedures also facilitates internal investigations.

Various security technologies play a role in incident identification. For example, firewall, IDS, host, and application logs reveal evidence of potentially hostile activities coming from outside and inside the protected perimeter. Also, logs are often paramount in finding the party responsible for the activities. Security event correlation is essential for high-quality incident identification, due to its ability to uncover patterns in the incoming security event flow. Collecting various audit logs and correlating them in near real time goes a long way toward making the identification step of the response process less painful.

21.3.3 Containment

Containment is what keeps the incident from spreading and incurring higher financial or other loss. During this stage, the incident responders intervene and attempt to limit the damage by tightening network or host access controls, changing system passwords, disabling accounts, etc. During the containment stage, make every effort to keep potential evidence intact, balancing the needs of system owners and incident investigators . A backup of the affected systems is also essential. A backup preserves the system for further investigation. The important decision on whether to continue operating the affected assets should be made by the appropriate authorities during this stage.

Limited, automated containment measures may be deployed in the case of some security incidents, especially those on the perimeter of the organization. This is possible if security event correlation is used in the incident identification process for reliable threat identification. Correlation makes incident identification much more accurate, enabling automated containment measures such as firewall blocking, system reconfiguration, or forced file-integrity checks.

21.3.4 Eradication

Eradication is the stage in which the factors leading to the incident are eliminated or mitigated. Such factors often include system vulnerabilities, unsafe system configurations, out-of-date protection software, or even imperfect physical access control. Also, nontechnology controls such as building access policies or keycard privileges might be adjusted at this stage. In a hacker- related incident, the affected systems are likely to be restored from the last clean backup or rebuilt from the operating system vendor media with all applications reinstalled. In rare cases, the organization might decide that mitigating the flaws is impossible given the current environment, and will make the decision to migrate the affected system to a new platform

Time is critical during the eradication stage. The first response should satisfy several often conflicting criteria, such as accommodating the system owner's requests , preserving evidence, and stopping the spread of damage, while simultaneously complying with all of the appropriate organization's policies.

21.3.5 Recovery

During recovery , the organization's operations return to normal. Systems are restored, configured to prevent recurrence , and returned to regular use. To ensure that the newly established controls are working, the organization might want to increase monitoring of the affected assets for some period of time. Increased monitoring implemented at the recovery stage not only leads to more effective protection of the affected assets, but also might be adopted as a new baseline for the whole organization, especially if such monitoring uncovers new threats.

21.3.6 Follow-Up

Follow-up is an extremely important stage of the incident response process. Just as in the preparation stage, proper incident follow-up helps to ensure that lessons are learned from the incident and that the overall security posture improves as a result. Additionally, follow-up is important in order to prevent the recurrence of similar incidents. A report on the incident is often submitted to senior management. This report covers actions taken, summarizes lessons learned, and serves as a knowledge repository, in case of similar incidents in the future. It might also summarize the intruder's actions and tools and give details of the vulnerabilities exploited, and it may contain other information on the perpetrator.

Follow-up steps often need to be distributed to a wider audience than the rest of the investigation process. This ensures the IT resource owners are more prepared to combat future threats. To optimize the distribution of incident information, you can use various forms and templates, prepared in advanced for different types of incidents. A summary of suggested actions might also be sent to senior management. The more in-depth changes to the organization's handling of security are performed at this step.

21.3.6.1 Benefits of the SANS framwork

Overall, the SANS process allows you to give structure to the somewhat chaotic incident response process. It outlines the steps each organization must define. Such steps need to be easy to follow, since they have to work in a high-stress post-incident environment.

In fact, many of the above steps may be built from predefined procedures. Following the steps will then be as easy as selecting and sometimes customizing the procedures for each case at hand. Incident handling workflow thus becomes relatively painless and crucial steps are not missed. Using predefined procedures also trains incident response staff on proper actions for each process step. An automated system can be built to keep track of the response workflow, suggest proper procedures for various steps, and securely handle incident evidence. Additionally, such a system facilitates collaboration between various response team members , who can then share the workload for increased efficiency.

Now that we have built the response framework, let's review the goals of an incident response program for various environments.