Conducting Security Investigations

Conducting Security Investigations

Another challenging aspect of incident response is conducting the investigation itself. Although other stages of incident response have their own issues, the process used in the investigation can expand or inhibit the capability of the response team. Unskilled investigators will often damage critical evidence that could lead to discovery of the attacker, or they will otherwise hinder the team. Similarly, approaches that could yield additional information might be overlooked. For these reasons, the team should practice their response techniques before they are needed so that these techniques are already fine-tuned when an actual incident occurs.

Involving Law Enforcement

Many times, incident response involves making the least bad choice rather than making optimal choices. At no point is this more true than when you must decide whether to involve law enforcement authorities. Your organization should decide whether to involve law enforcement officials before a security incident occurs to ensure that the proper evidence collection techniques are used.

One consideration about involving law enforcement is that it will likely slow the restoration of network services. Also, if your organization does chose to work with law enforcement officials, there is a strong chance that the security incident will become public record and damage the reputation of your organization. If your organization does decide that it might want to prosecute attackers if an incident occurs, you should work with local or regional law enforcement agencies in advance to determine how to engage law enforcement and receive training in forensic investigation methods.

Conducting the Investigation

In cases where an incident response might ultimately include taking the attacker to court, it is imperative that you perform all your operations with the knowledge that they will contribute positively or negatively to the proceedings. The rule of thumb is to always follow the principle of best evidence while conducting the investigation. Criminal investigations involve something known as chain of custody, where specific processes for collecting evidence are required. Such processes vary by jurisdiction. If these processes are not followed, the chain is considered broken and the evidence might not be admitted into court or could be picked apart by opposing counsel. (We will discuss chain of custody and collecting evidence in more detail momentarily.)

Although your legal counsel can provide more details on the topic of evidence handling, some general principles exist. First, ensure that your handling and collection of information is beyond reproach and will stand up to the closest scrutiny. If you collect such incontrovertible evidence to prove, beyond the shadow of a doubt, a particular detail, be assured that the opposing counsel will not try to refute the evidence. Instead, the opposing counsel will attempt to undermine the credibility of the collectors and your incident response process to inject doubt into the proceedings.

With this in mind, ensuring precision in your investigative work is key, as is validating sources and details. Ensure that no possible questions can be raised about each of the investigative activities your team performs. Document in as much detail as possible all the actions of every member of the investigative team throughout the course of the investigation. If not documented, even the seemingly mundane details, such as a time difference between the computer BIOS and the OS, can cause a great deal of heartache in court. Your documentation should include the time and date on the system including the time zone, the name of the person conducting the action, details of the steps taken and their results, the timestamp following the steps taken, the signature of the investigator, and a signature of a skilled witness.

In addition to helping prove the quality of evidence in your own legal jurisdiction, if you find yourself working with law enforcement authorities in another region or country, such documentation can clarify the steps taken to protect evidence from tampering and damage should that jurisdiction s rules of evidence differ from those of your own jurisdiction.

Limiting Investigative Work to Backup Media

Because the act of inspecting files on a live system can modify last modified times and access times of individual files, thus eliminating potential evidence, you should conduct investigative work only on copies of the original media. These must be byte-level copies because slack space the space between files on drives can contain significant quantities of evidence that should be retained.

A number of tools can be used to make a forensic image of the drive, including SafeBack from NTI (http://www.forensics-intl.com/safeback.html). Ensure that the receiving media has not been previously used because previous data on the target drive can lead to incorrect assumptions during the investigation. Furthermore, the target media must have the same or similar hardware geometry. If a receiving drive has a dramatically different number of cylinders or sectors, evidence can be lost during the transfer. If time permits, you might want to make additional, second-generation copies from the first set of copies. This guarantees that you have an unmodified first-generation copy at all times should one be needed for additional avenues of investigation. An illustration of this method is in Figure 27-1.

figure 27-1 preserving evidence by making forensically-sound backups of the original media and working copies from the first-generation backup

Figure 27-1. Preserving evidence by making forensically-sound backups of the original media and working copies from the first-generation backup

Treatment of the original media, which is now your evidence copy, must also be handled properly throughout the investigation. You must be able to account for the original media s whereabouts at all times, identify who has access to it at any given point, and pinpoint when possession of the evidence changed along with the reason for any change. This is the chain of custody process we referred to earlier. To protect the chain of custody, place the media in a secure location that a minimum number of people have access to and require that all access be logged. Store the logs in such a way that no question about whether they have been altered can arise. These logs should contain the time, date, and circumstance under which the evidence changes hands, and they should document each person who takes possession of this evidence.

Collecting Evidence

If you decide to pursue a law enforcement solution, the agency you work with will have additional recommendations about the steps to take to preserve evidence and conduct the investigation. This is because the methods you use to collect one type of evidence can obscure or destroy the collection of another type. You should not begin collecting information about an attack until you have a good understanding of the type of attack that is occurring without this understanding, you risk tipping off an intruder or destroying evidence

When you begin collecting information about an attack, you might not know exactly what you are looking for. Even if you think you know, you might be wrong: as mentioned earlier, the attack might have occurred on more levels than you are aware of. With this in mind, a keen-eyed investigator with journal in hand will look at every potential clue to determine what occurred and the extent of any damages.

Two primary types of data exist on a computer system: volatile data and nonvolatile data. Simply put, volatile data is data that will disappear if the system loses power, and nonvolatile data is the data that persists after power is restored. Because many attacks leave only remnants in the form of volatile data, it is essential that you collect as much of this data as possible (without causing additional damage) before shutting down the system.

Volatile Data

Volatile data includes information about the following:

  • The processes that are running, suspended, or disabled

  • The network connections that are open

  • All recently executed programs

  • The dynamic contents within the registry

  • The contents of the Address Resolution Protocol (ARP) cache and of the rest of memory

  • The pagefile (if it has been set to wipe itself clean upon shutdown)

  • Any backup media inserted into the local system (because running processes might cause a backup to initiate and overwrite the contents of the media)

  • The accounts that have sessions logged on (either locally or remotely)

  • How long the system has been running since the last reboot

  • The ports that are open and the applications listening on those open ports

When capturing this information, keep in mind that it might not be possible to trust the executables on the machine you are cataloging because an attacker might have modified them with one or more Trojan horses. Because it is easy to overwrite or otherwise destroy forensic information, you should conduct this type of investigation only if you have received training or are working with more experienced administrators. To properly evaluate the forensic evidence, you must know what the state of the computer would be under normal conditions. For example, it is very difficult to look at a list of processes running on a computer and determine which normally execute on the computer and which are malicious. As mentioned previously, understanding the baseline operation of the computers on your network is essential during an investigation.

As you collect information, you also must ensure that you are capturing the time at which the collection occurs. Looking at your watch and noting it in your journal does not suffice because the system time might differ. A good rule of thumb is to note both the clock time and the system time in your journal before and after each command.

Nonvolatile Data

Nonvolatile data is also important to the investigation. The primary difference between volatile and nonvolatile data is when and how they can be collected. As mentioned, nonvolatile information persists after a system shutdown. Therefore, assuming no processes are running that will eliminate the evidence when the system is stopped, you can collect this information after the system is taken offline ideally from a forensically sound backup of the media (described in the previous section).

Nonvolatile information includes the following:

  • The contents of the registry

  • Event logs and other log files

  • Service startup configurations

  • The access and modification times of files

  • Recently deleted files

  • The slack space between the end of a file and the end of the cluster

    Because normal activity that occurs when starting up a system can change the access and modification times of a large number of files as well as causing processes set to run at startup to overwrite slack space or change other elements of the OS configuration we suggest you conduct analysis of these aspects offline.

Data Collection Tools

Incident response teams should be familiar with the wide variety of tools that are available for collecting data, along with their capabilities, strengths, and weaknesses. Practicing working with these tools before they are needed in an incident response will help investigators hone their skills. This can help reduce the number of steps required to collect the necessary information and prevent other evidence from being destroyed in the process which, as we mentioned, is a large factor in determining the success of the investigation. Table 27-2 shows some of the tools available for gathering data in an incident investigation and where you obtain them.

Table 27-2. Tools for Gathering Information

Data Type

Command or Tool

Processes running

Task Manager or the command-line tools TList (Windows 2000) and Tasklist (Windows XP), which are both available in default installations of Windows 2000 and Windows XP

PsTools from Sysinternals at http://www.systeminternals.com

Fport from Foundstone at http://www.foundstone.com

Current system activity

Filemon and Regmon from Sysinternals at http://www.systeminternals.com

Services and drivers

SC.exe, Sclist.exe, and Drivers.exe, found in the Tools folder on the CD included with this book

Net Start and Reg.exe, which are both available in default installations of Windows 2000 and Windows XP

New files

Dir /q /-c /o:d /t:a /s > filename.txt, which is available in default installations of Windows 2000 and Windows XP

Forensic Toolkit from Foundstone at http://www.foundstone.com

Memory contents

CheckSym.exe, found in the Tools\CheckSym folder on the CD included with this book

Registry

Reg.exe, which is available in default installations of Windows 2000 and Windows XP

Regdmp.exe, found in theTools folder on the CD included with this book

Permissions

Xcacls.exe, Xcacls.vbs, and Subinacl.exe, which are found on the CD included with this book. (Xcacls.exe and Subinacls.exe are in the Tools folder; Xcacls.vbs is in the Tools\Scripts\XCACLS VBS folder.)

Current network connections

Netstat.exe -ano and Nbtstat.exe, which are available in default installations of Windows 2000 and Windows XP (the -o switch for Netstat.exe works in Windows XP only)

Fport from Foundstone at http://www.foundstone.com

Network IP routes

Netstat.exe -r and Route Print, which are available in default installations of Windows 2000 and Windows XP

Shares information

Net Share, which is available in default installations of Windows 2000 and Windows XP

Srvcheck.exe, found in the Tools folder on the CD included with this book

DumpSec from SomarSoft at http://www.somarsoft.com

Vadump.exe, found in the Tools folder on the CD included with this book

Scheduled tasks

At and Run registry keys, which are available in default installations of Windows 2000 and Windows XP

Slack space

Tools such as EnCase (http://www.guidancesoftware.com/), NTI (http://www.forensics-intl.com/tools.html), WinHex (http://www.sf-soft.de), Norton Utilites Disk Editor (http://www.sf-soft.de)

The capabilities of tools listed in Table 27-2 vary widely. Not every tool will be valuable in every instance. In some cases, combining the output of multiple tools will be necessary to gain information that is useful to the investigation for example, when collecting information on running processes. Although it is useful to collect a list of the processes running, it is even more useful to combine that information with information on open network sessions. This combination can help you, as the investigator, ferret out abnormal system behavior.

You can extend the usefulness of this combination of data when comparing the results with a known good baseline. For example, if you are concerned about changes to the files that are listed in your services list, you can use a tool such as Tripwire (http://www.tripwire.com) to compare hashes of all system files to see whether any have changed. Alternately, you can use a command such as

dir /q /-c /o:d /t:a /s > filename.txt

to output a complete, recursive file listing of all files on the system sorted in date order to the Filename.txt file. To perform the same type of activity with the registry, you can leverage the Reg.exe tool and its /query and /compare switches. To review permissions, you can utilize Xcacls.exe, Xcacls.vbs, or Subinacl.exe.

As many of the examples discussed in this section illustrate, if you want to be effective, you must collect a fair amount of data long before an incident occurs. In cases where you have not performed this preparatory activity, you might be able to obtain enough information from similarly configured systems for comparison. Keep in mind that if those other systems have also been compromised, the information you collect might be useless at best, or it might lead you to believe that no compromise has occurred.

Once volatile data has been collected, you must preserve the state of the original media either for evidence or for additional investigation by making one or more backup copies, as mentioned earlier. When making copies of the drives, it is not enough to simply copy files. Additional evidence can be found in the space between files the slack space in the form of previously deleted (but not yet overwritten) files. Additional evidence can also be found in the space between the end of a file and the end of the sector where the tail end of that file resides. Because of this, the backup needs to be a byte-level backup of the entire drive. Best results will be obtained by matching the original drive as closely as possible in terms of its geometry. The drive must not have been previously used because remnants of that earlier use could contaminate evidence and impede the investigation. A number of tools exist for performing a sector-by-sector copy of a hard drive, including SafeBack from NTI (http://www.forensics-intl.com/safeback.html), Norton Ghost from Symantec (only when using the -IR switch, and found at http://www.symantec.com/sabu/ghost/ghost_personal/), EnCase (http://www.guidancesoftware.com/), and dd, a tool for forensically-sound backups.

RAID arrays pose a challenge to the forensic recovery process because data often spans multiple drives and slack space is quickly overwritten by other data as the RAID array is optimized. It can be difficult, if not impossible, to extract data from the slack space on a RAID volume.

Performing Network Monitoring

If the information described throughout this section does not provide you with sufficient guidance, you might want to perform full network monitoring and inspect traffic on the network. By analyzing which systems are talking to each other as well as the contents of those communications, you can gain a great deal of information about an attack in progress. However, the analysis of masses of raw data can be very time-consuming.

Besides taking into account the tedium of network monitoring, you must consider the issue of privacy. If an investigator reads all data passing on the wire, she likely will review user data and thereby violate the privacy of those users. This is a larger issue for some law enforcement personnel who might be legally barred from this type of monitoring to prevent the possibility of inadvertent privacy violation.

Because privacy violation is a complex legal issue that varies among jurisdictions, we recommend you discuss this topic with your organization s legal counsel. Even in cases where full packet details cannot be reviewed because of privacy concerns, it is possible to gain useful information by analyzing transactional data contained in packet headers. Knowing which systems are talking to each other, which protocols are being used, whether the traffic is encrypted, and the volume of the traffic flow can allow an investigator to make inferences that can help with future investigative tasks.

See Part VII of this book, Applying Key Principles of Privacy, for more information about privacy issues.



Microsoft Windows Security Resource Kit
Microsoft Windows Security Resource Kit
ISBN: 0735621748
EAN: 2147483647
Year: 2003
Pages: 189

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net