Responding to Incidents | MCSE: Windows(r) Server 2003 Network Security Design Study Guide (70-298)

< Day Day Up >

To prevent mistakes from happening when responding to security incidents, you should have a well-designed procedure for responding to incidents. Having a procedure in place allows the security response team in your organization to react appropriately when a situation arises. Failure to respond appropriately can cause the incident to worsen. There is the potential to damage or taint the evidence that could lead to the capture and prosecution of the attacker. In the section that follows, you will learn how to design an incident response procedure that will provide your response team with the appropriate steps in the event of a security breach.

Designing an Incident Response Procedure

A recurring concept in information systems management is to have well-designed processes. This is true in all facets of business: the better defined the process, the less ambiguity in the minds of the facilitators.

A plan must be in place that provides you with the information you’ll need at the moment that the attack is discovered or suspected. It should contain a list of the names and numbers of those to be notified, especially in an enterprise environment; all site administrators must be aware of the incident so that they can plug or patch the vulnerability that they are probably susceptible to as well.

There are typically two techniques when responding to an attack. One is to shut down or disconnect the system(s) that have been compromised (not the router that they came in through, unless it has been compromised). Shutting down or disconnecting the system(s) allows you to preserve the evidence before the attacker has the opportunity to hide their tracks. The other option is to isolate the system(s) so that you can monitor the activity of the attacker to gather more evidence and at the same time prevent other systems from being attacked. The benefit to this method is that you can monitor the activity of the attacker and can gather even more evidence. This option does, however, come with significant risk. The attacker may notice the changes, eliminate the evidence, and stop the attack. Allowing the attacker to continue, even in an isolated environment, should be an option only for a highly skilled security expert.

There are several situations where the importance of procedures is demonstrated, specifically how not having a procedure can lead to damage in a number of different scenarios. In your procedure you should create a determinate chain of notification, where the information can flow to everyone who may be affected by the incident. One of the best ways to avoid mistakes when reacting to an incident is to have a procedure that spells out how the information should be disseminated to the various members of the team as well as notifying those individuals in need-to-know roles. The Communication procedure is key to the success of your security response team in properly defending and reacting effectively. For example, in a scenario in which you suspect an employee is selling information to competitors typically spurs an internal investigation by the security team to audit the critical resources that are being leaked. Without a procedure specifying whom to notify, the workstation of the employee could be re-imaged by a desktop administrator, which would obviously erase most of the evidence on the machine. Many companies use an imaging solution, such as Symantec’s

Real World Scenario: A Incident Response Procedure Will Prevent Mistakes

The first time that I fell victim to an external attack, I panicked and immediately shut down the router that the attacker entered through—I literally unplugged it. That was my knee-jerk reaction under the stress that obviously comes with being attacked. Turning off the router not only disconnected the attacker, it also stopped Internet e-mail from entering our organization and prevented us from sending external e-mail and accessing the Internet entirely. Fortunately, the attackers (I found out later that it was significantly more than one) were only able to gain access to our public FTP servers and simply used them to store and share files across the Internet.

Had there been a well documented procedure dictating my response, I wouldn’t have made such monumental mistakes. You will want to make sure that you have a procedure in place to prevent your response staff from making those mistakes.

Ghost, for the hard drives of the workstations in the enterprise, so without proper communication, the workstation of the employee could be re-imaged by a desktop administrator, which would overwrite most of the evidence on the machine. The desktop administrator should be made aware of the breach in security and trained well enough to know that re-imaging the workstation hard drive is not the appropriate response in this situation.

The first step in putting together a Computer Security Incident Response Procedure (CSIRP) is to build a team referred to as a computer security incident response team (CSIRT). It is extremely important that each member of the team be given a finite scope of responsibility. It is always a good idea to include a broad range of skills in the team. A good team would include a network administrator who knows the topology of the network, a server administrator who knows the configuration of the servers, a desktop administrator who knows the configuration of the desktop workstations in the organization, an application specialist who is familiar with the application set that is running on the workstations and the servers, a security specialist whose main focus is on securing the organization, a team leader to facilitate the chain of communication, and a manager who has the authority to make a clutch decision.

Once the entire team has been formed, the next step is to determine the severity level you’ll assign to certain types of incidents. As you may imagine, some security incidents may not require the entire team being brought in. For example, an incident such as a small virus infecting a single computer would certainly not warrant the whole CSIRT to resolve the problem. There must be clear definitions of what severity an incident is and therefore who needs to work to resolve the issue. Table 2.3 shows an example of severity classification for ABC Corporation with some examples.

Table 2.3: Severity Classification Example
Severity	Example(s)
1	Small number of users receive an e-mail with a virus attachment, which is caught by antivirus software on the computer.
2	Small number of scans detected on perimeter systems along with information concerning which computers will be targeted.
3	Large number of scans detected on perimeter systems; zero affect on production systems. Large number of computers infected with a known computer virus that is handled by antivirus software. Small number of isolated computers infected with unknown computer virus.
4	Breach of perimeter systems or successful denial of service attack with minimal impact on production.
5	Breach of perimeter systems or successful denial of service attack with major impact on production systems; poses a significant chance of financial or public relations damage.

Based on Table 2.3, incidents with a severity of 3 or greater would result in the activation of the CSIRT, while incidents with lower severity levels would be handled without the intervention of the incident response team.

The incident response procedure should include details for the following steps, with as much specific information as possible:

Declare the incident The response procedure should include the conditions that must be met for an incident to be declared as well as who is responsible for making the declaration. When an incident occurs that requires the team to respond, it should be declared. Typically, the team manager would be the individual making the declaration and would notify upper management that a security incident has occurred. The team manager would also be the person responsible for communicating the incident to the rest of the team.

Analyze the incident The incident will need to be analyzed to determine the scope of the breach. It is at this stage that the details of the incident will be recorded.

Contain or resolve the incident Depending on the type of incident that occurs, you may need to quarantine the systems that have been compromised. Should a solution exist that can be applied and alleviate the situation, it should be carried out. Fixing the problem is better than containing it.

Resolve the problem If the previous step led only to containment, the next step is to resolve the problem. This may begin with cleaning a system and then applying a patch or a service pack.

Prevent reoccurrence of problem Take the appropriate steps to prevent the system(s) from being compromised again.

Document events Log all of the events that have taken place, from the discovery of the breach to resolution. This documentation will be used in the post-incident evaluation.

Preserve evidence Be sure to retain as much evidence as possible. As previously stated, this data can be used by the authorities to capture the attacker. The evidence can also be used to prevent future attacks that exploit similar vulnerabilities.

Conduct a post-incident evaluation Gather the team after the incident has been resolved to review all of the information that was collected. Identify areas in which the team could improve its response and paths of communication.

Design Scenario: Designing a Response to an Incident

A virus that propagates from the Internet penetrates the internal LAN of your network. The virus is not immediately identified by all of the administrators. Some of the administrators recognize the virus and manually remove it from the servers that they are responsible for. After the administrators remove the virus, they notice that the servers are immediately infected again.

Question: What actions should be included in your response procedure for this type of incident? Answer: The administrators who recognize the virus should notify the team leader, and the rest of the team, regarding the fix for the virus. The team leader would be responsible for communicating the solution to the rest of the team and to the other departments who need to be aware of the situation. In order to prevent the reoccur rence of the virus, the administrators should take steps to prevent the reinfection of the servers; the steps may include isolation from the LAN, WAN, or Internet.

< Day Day Up >