‫ Computer Security Incident Handling in Six Phases- Containment

The goal of the containment phase is to limit the scope and magnitude of an incident—to keep the incident from getting worse.
If data is not gathered quickly and accurately, it may never be gathered.
Action 1.1: Deploy a small team
Four or five people are the limit for an On site Team at one location. The risk of loss of coordination leading to errors and the overhead of incident communication goes up with a larger team. Also, if this incident should ever go to court, everyone who stays in the area is a potential witness.
Action 1.2: Secure the area using physical security personnel if possible.
Action 1.3: Use the survey forms provided at the end of this article
The fields in the survey forms will help ensure that all needed information is recorded.
Action 1.4: Review the information that was provided to you from the identification phase
Be very careful to check any conclusions others have reached.
Action 1.5: Keep the system(s) pristine
Do not allow the system to be altered in any way until the backup has been completed.
If a network-based intrusion is determined, be careful not to give away what you know.
Action 2.1: Avoid using obvious methods to look for the intruder
A classic rookie error is to ping, nslookup, finger, telnet to, or in some other way make contact with the suspected source of the attack (hours later). If your adversaries detect you trying to locate them, they may delete your file systems and break off the connection (for a while anyway) in an effort to cover their tracks.
Action 2.2: Maintain standard procedures
If your site is protected by an active intrusion detection system that drops connections or blocks attacking IP addresses, do not disable the IDS to try to gather more data. This would create a change in your profile that might warn the attacker
Intruders may install Trojan horses and similar malicious code in system binaries.
Action 3.1: Be wary of compromised system binaries
It is not advisable to log in to a system suspected of being compromised, as "root" or "administrator," and then start typing commands such as ftp to download tools from another site. If possible, record the cryptographic fingerprint of critical binary files for the organization's core operating systems. Some experienced incident handlers recommend building disks with core binaries. In any case, the only binary you want to be particularly concerned about at this moment in an incident is the system's backup program.
Perpetrators of computer crime are becoming increasingly proficient in destroying evidence of illegal activity to avoid detection or prosecution. Therefore, it is extremely important to obtain a full backup, preferably using disk imaging of the system with known good binaries in which suspicious events have been observed.
Action 4.1: Backup to new (unused) media
Do your backup as soon as there are indications that a security-related incident has occurred. Use new media because juries may be convinced that the "evidence is faulty" if it is written over old information. Making a full backup immediately captures evidence that otherwise may be destroyed before you and others have a chance to look at it. If possible, make two backups, one to keep sealed as evidence, and one to use as a source of additional backups. The backup will also provide a basis for comparison later in case you need to determine if any additional unauthorized activity has occurred. Disk-to-disk backup is often the fastest method. Though there are tools for some Unix systems that do destructive formats, in general if you have to reuse media you should not count on format to erase all of the previous data.
There are tools that clear disk by overwrite to U.S. Government standards such as BC Wipe. Finally, you could always try using dd, e.g. dd if=/dev/zero of=/dev/hdb.
Action 4.2: Safely store any backup tapes so that they will not be lost and/or stolen
Tape protection is an important part of the chain of custody of critical information. If tapes are unprotected, the entire case could be damaged.
One of the most difficult decisions, and one subject to extreme pressure by end-users and senior management, is what to do about the compromised system. Here you will decide whether a system should be shut down entirely, disconnected from the network, or be allowed to continue to run in its normal operational status so that any activity on the system can be monitored.
Action 5.1: Acquire logs and other sources of information
Many log files turn over fairly quickly, so it is important to acquire network and computer logs immediately.
Action 5.2: Review logs from neighboring systems
Review logs and cryptographic file signature databases from other systems on the same subnet and from systems that regularly connect to the affected system(s), especially if there is a trust relationship.
Action 5.3: Make a recommendation
The On Site Team provides a recommendation to the Command Post Team, who will make the decision on what to do.
System owners' stress levels can be very high because their business may stop during the review process, and very large amounts of money may be lost.
Action 6.1: Keep system owners and administrators briefed on progress
The users of the affected system almost invariably really need the system, usually for an important project due that day. There is also a tendency for the system administrator or manager responsible for the system to internalize the incident. They might become defensive because they sometimes feel that since they operate the affected computer, the situation is their fault. Keeping them informed and aware of progress can help lower the stress level.
Action 6.2: Never allow fault to be an issue during incident handling
As you work to contain an incident, try to take time to give your co-workers a smile, a pat on the back, and mention the things that are being done right as much as possible.
A common target of intruders is root or administrator account names and passwords.
Action 7.1: Change the password on the affected systems
In the case of system compromise, passwords should be changed on the compromised system and all systems it regularly interacts with.
Action 7.2: If a sniffer is detected or suspected, expand the password change order
If you have reason to believe your systems have been subjected to a sniffer attack, passwords may have been compromised on all systems on the affected LAN or subnet. If a large system such as a POP mail server is compromised, and the organization wants to keep rumors and questions to a minimum, it may be advisable to explain the password change as part of a system upgrade or as the routine recommendation of an external security auditor. Emphasize how important it is for users to change to a unique password that is not being used on any other computer system.
Related Links:
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