فا

‫ Computer Security Incident Handling in Six Phases- Eradication

IRCAR201105101
Date: 2011-05-31
 
The goal of the eradication phase is to eliminate or mitigate the factor(s) that resulted in a compromise of system security. Compromise of a system can be traumatic for a system owner. But if the incident handling team fails to adequately eradicate the problem, and if another compromise occurs, then management can legitimately question the competency of the incident handling team itself.
 
STEP 1: DETERMINE CAUSE AND SYMPTOMS OF THE INCIDENT
You cannot fix the security problem that led to a system compromise if you don't know what happened.
 
Action 1.1: Isolate the attack and determine how it was executed
Information collected during the survey phase may be sufficient to determine the root cause of the incident. In most incidents, there are multiple causes for a compromise. The absence of adequate technical controls, for example, may result from the failure to adequately select and train system administrators; from the lack of written security policies and procedures; from the absence of management emphasis; or all of these reasons. Team members must conduct a comprehensive review of the data gathered, and not assume that one factor alone contributed to the compromise.
If for whatever reason, there is insufficient evidence to arrive at an exact understanding of the attack and how the attacker exploited a weakness, then team members may list all realistic possibilities based upon available information. From what is possible, the team can collectively develop scenarios to explain what has occurred.
 
STEP 2: IMPROVE DEFENSES
Once a system has been compromised, its password file, IP address, and operating system may get advertised to the hacker community. As a result, for weeks following the incident, the system may get repeatedly probed or attacked. New attackers may have enough data to launch attacks. More importantly, the original attacker may be unaware that the system's owner has discovered the compromise. That attacker may continue to return to the compromised system to obtain additional information and to use the compromised system as a springboard for attacks on other systems.
 
Action 2.1: Implement appropriate protection techniques such as firewall and/or router filters, moving the system to a new name/IP address, or in extreme cases, porting the machine's function to a more secure operating system.
The incident handling team cannot permit a compromised host to reestablish network connections until the team fully understands the cause(s) of the incident, and can direct the system's owner to follow specific eradication procedures that will preclude a reoccurrence. The team must always verify the correct implementation of those procedures before reconnection.
Depending on the environmental and operational factors involved, many procedures may be outside the control of the system's owner. For example, typically in large enterprises, firewall and router configurations are the responsibility of another organizational entity. The team should serve as the liaison between the system's owner and these entities to ensure adequate protection. Similarly, the system's owner may lack the technical expertise to re-build a system after a compromise. The incident handling team may have to provide assistance, or again serve as a liaison. Finally, the team may decide that the cause of the compromise was an insecure operating system or network environment that cannot be addressed by simply re-building an existing system or network. The team may then recommend that management approve a redeployment on a safer operating system before reconnection.
 
STEP 3: PERFORM VULNERABILITY ANALYSIS
Though prudence dictates that all sites that care about security perform regular vulnerability analyses of their systems and networks, many do not. When they experience a security incident, however, they usually act quickly to look for additional vulnerability analyses. The use of automated vulnerability assessment tools can assist an incident handling team not only to validate the correctness of eradication procedures, but also to anticipate and correct factors that might facilitate an attack.
 
Action 3.1: Perform system vulnerability analysis
Use a system vulnerability tool to determine whether configuration and software versions at your site need to be updated. Either acquire a vulnerability analysis tool or hire a security consultant who brings one along.
Both host-based and network-based assessment tools can determine the robustness of system and network configurations. Host- based tools provide a higher degree of accuracy than do network-based tools. Increasingly host-based tools such as bastille, available at http://www.bastille-linux.org or the tools from the Center for Internet Security http://www.cisecurity.org/ have the capability to actually correct or to strengthen the security of a system. Network-based tools such as nmap, available at http://www.insecure.org/nmap or nessus, available at http://www.nessus.org can identify, and in some cases stress, common vulnerability exposures that may have resulted in a compromise. A combination of tools is beneficial because each tool may have unique capabilities.
 
Action 3.2: Search for related vulnerabilities
One critical step, often forgotten in the eradication phase, is to ensure other platforms within the organization are not vulnerable to the factor(s) that allowed the compromise. Incident handling team members can quickly use automated assessment tools to search for these factors. Team members must be aware, however, of two pieces of information that can facilitate the search. First, does the organization have an inventory of computing resources? If so, that inventory will expedite the search. Team members must recognize that, if they employ a network-based assessment tool, they may have no assurance that all potentially vulnerable systems are online at the time of search. Without a valid inventory of computing resources, any network search may be an exercise in hit-and-miss.
Second, does the organization have an effective configuration management program? If so, is the program centralized or decentralized? Inventories and centralized configuration capabilities will allow the team to focus its attention and resources productively when searching out and correcting related vulnerabilities.
 
STEP 4: REMOVE THE CAUSE OF THE INCIDENT
Deciding what to do to remove the cause is often a great challenge. The actions below provide high-level guidance. Additional guidance for each of the common types of attack is offered in a later section.
 
Action 4.1: For virus infestations
In the case of a virus, eradication simply requires removing the virus from all systems and media, usually with virus eradication software.
 
Action 4.2: For other malicious code infestations
Commercial software may exist to eradicate common or "in the wild" malicious code. Most commercial programs will identify computer viruses, well-known Trojan horses, and certain worms—all forms of malicious software for the Windows and Macintosh environments. For Unix environments there are few commercial programs available. However in most cases, dedicated professionals have released detection and removal tools into the public domain to address the influx of Trojan horses and worms that have appeared in UNIX systems within the last three years. The incident handling team must stockpile both commercial and free detection/ eradication software in anticipation of an infection.
The team must recognize the potential for reinfection, given that it may be difficult to disinfect all media—particularly backup media. If backups become infected, then the potential for reinfection increases.
Finally, the team must ensure that there is an effective procedure by which updates to commercial anti-viral programs are available.
 
Action 4.3: For network intrusion
In the case of a network intrusion, eradication is more difficult. Many attacks over a network are in two parts. First there is an initial phase, where a system vulnerability is exploited and the system is accessed. Once in, the intruder often installs a tool (back door) to provide continued access. The intruder may also set up shop on the compromised system to use it for intrusions into other computers. There are many examples in which intruders have launched exploit scripts against other computers from a single compromised system. Attackers also often install backdoor access programs and sniffers to collect additional passwords and user ID's. Your team's job—often its most difficult job—is to search for all such programs and remove them.
The team must determine whether the attacker has modified the compromised system in any way (i.e., alterations of system binaries and files, installation of attack programs, creation of "backdoors" into the compromised system). The only practical way to do this is to immediately disconnect the compromised system from the network until such time as team members have completed forensic analysis. This assumes that team members have information as to what was the baseline "norm" of the system before compromise; and that they have access to clean, uncompromised system binaries and application programs installed on the compromised system.
If there are business reasons that preclude disconnection, then the team can consider alternatives. For example, it may be possible to place a firewall directly in front of the compromised system and establish an Access Control List (ACL) to preclude an attacker's access. Another possibility may be to filter incoming and possibly outgoing connections to and from the compromised system at the organization's network perimeter.
Finally, if law enforcement considerations dictate that monitoring the attacker takes precedence over eradication, then the system may be left in place with appropriate sensors to capture the attacker's keystrokes. Only senior management, not the incident handling team, or the legal department, has the right to approve such a course of action.
 
Action 4.4: If the attacker discovers your efforts
Sometimes the attackers will detect your eradication efforts and attempt to maintain control of your system. This is a tough situation for which you may wish to request law enforcement support. Continue in your efforts to remove the attacker's code from your system. Do everything possible to get network/phone logs of the attack. If the source address of the network traffic is not spoofed and if your policy allows, contact that owner for the source network and try to get their logs as well.
In some cases, attackers have actually contacted organizational personnel with offers to help in the eradication.
Each organization must have written policies and procedures in place to address such situations. The policy must indicate at what point the organization will report to and seek assistance from law enforcement agencies. Most importantly, the policy must identify who within the organization will make the decision, and who will make the contact.
Team members should refrain from direct contact with an attacker in the absence of written policy. If such contact does occur, team members must maintain detailed audit records of all contact. Once law enforcement personnel have responded to an incident, they—not organizational personnel—will usually manage all contacts. For this reason organizations should make liaison with respective law enforcement agencies in advance of an actual intrusion.
 
STEP 5: LOCATE THE MOST RECENT CLEAN BACKUP
In the next phase you'll restore the system to operation. First, however, you must locate a backup that is not infected and that is current.
 
Action 5.1: Search for a current backup (i.e., pre-infestation or intrusion)
It can be hard to know just when the attack occurred, and this makes selecting your backup problematic. During the Code Red worm attack, the second version, "variant c" installed a back door onto the Windows NT or 2000 system running IIS. Most of the people affected by Code Red were unable to determine when their system was first compromised. Though there were tools to remove the infection, there was no way to know what had been done to the system while it was compromised. They had to choose between rebuilding the entire system from original media or restoring files from a backup created before the second version of Code Red was first detected in June 2001. In either case, high quality backups were critical.
 
·         In case of a root kit-style attack
A root kit attack embeds so much malicious code in so many hidden places in a computer system that cleaning the system is almost never a viable option. If there is evidence of a root kit style attack, it may be better to avoid the backups, nuke the disk, rebuild the operating system (without the vulnerability), configure the operating system safely, patch the operating system with the latest patches, and reload the data.
 
Related Links:
 
References:
Computer Security Incident Handling: An Action Plan for Dealing with Intrusions, Cyber-Theft, and Other Security-Related Events, Version 2.3.1, Stephen Northcutt, SANS Institute, 2003

نظرات

بدون نظر
شما برای نظر دادن باید وارد شوید

نوشته

 
تاریخ ایجاد: 18 مرداد 1393

دسته‌ها

امتیاز

امتیاز شما
تعداد امتیازها:0