Assignment

Chapter33IRandForensicsIM.pptx

Home >Computer Science homework help >Assignment

Chapter 33

Incident Response and Forensic Analysis

Introduction

Interruptions to the normal operation of computer and network systems can and will occur. The causes of service interruptions are numerous, and they can include such events as bad production changes, hardware and software failures, and security breaches. For the purposes of this chapter, an incident will be defined as any disruption of the normal operation of a computer system. Organizations need to have systems and processes to detect such disruptions, and they need plans and procedures to respond and recover accordingly. Once a problem is identified, organizations should use their incident response plans to coordinate their response and recovery.

In certain situations, you will need to reconstruct system activity and extract information from affected computer systems. Forensic analysis is the process of identifying, extracting, preserving, and reporting on data obtained from a computer system. Forensics can be used to recover important data from a failed system, to document unauthorized employee activity, or to obtain evidence for the eventual prosecution of a criminal act.

Incident Response

The ultimate goal of any incident response (IR) plan is to contain, recover, and resume normal operations as quickly and smoothly as possible. Thinking about and developing plans to respond to various types of problems, regardless of the time they occur, can prevent panic and costly mistakes. In addition, creating, reviewing, and testing response procedures will identify weaknesses and failures in the organization’s ability to detect, respond, and recover. A good IR plan enables organizations to recover from many types of incidents.

The initial response requires personnel with the expertise to diagnose and chart a course of action, and someone who has the authority to implement identified solutions. The initial responders may also discover that the scope of the incident is larger than originally thought or that it affects additional systems, and they will need additional people or teams. Well-defined escalation lists can assist responders in identifying and contacting such resources. Beyond simply notifying technical personnel, it may be necessary to contact other departments, such as public relations, legal, or human resources to handle the nontechnical aspects of the incident.

IR Plan

The IR plan should also take into account that the person who discovers a problem is most likely not capable of fixing it and that he will, therefore, need to report the problem. Specifying how and where incidents should be reported is a good starting place for many IR plans.

A good IR plan comprises a number of distinct phases, each of which is discussed in the following sections:

Incident detection

Response and containment

Recovery and resumption

Review and improvement

The details of the IR plan consist mainly of how personnel are notified, what the escalation procedures are, and who has decision-making authority for a given incident. For example, the failure of a critical transaction-processing system most likely requires different people to be involved than would a suspected security breach or a power outage.

Incident Detection

Incident detection comes in many forms. It may come from an intrusion detection system (IDS) or Security Information and Event Management (SIEM) system, from a user phone call, or from a dedicated system that sounds an alarm. A notification or warning may also come from a public service, however. The first obstacle to effective incident response is detecting an actual incident such as a process failure or a security breach. Systems based on the Simple Network Management Protocol (SNMP) are typically a popular choice for monitoring.

SNMP management systems can be used to routinely monitor system response times and check the availability of processes from a centralized console. Such systems have the ability to notify configured personnel by paging or e-mailing them when an alarm is triggered. In addition, the monitored systems themselves can use SNMP to send emergency messages called traps to a console, should a major fault occur that requires attention.

Beyond SNMP monitoring, organizations require mechanisms to detect security-related events and to inform the appropriate people. IDSs have been specifically developed for the purposes of detecting malicious activity and SIEM systems work with IDSs to correlate, summarize, report, and alert on problems at a higher level, so the people monitoring those systems don’t have to wade through huge amounts of logs.

Response and Containment

When a potential incident is detected, the organization’s response plan should be initiated. An organization needs to get the right people working on the problem as rapidly as possible. A clear and simple mechanism should be available for notifying and apprising appropriate staff members of the developing situation. Having up-to-date contact information in the IR plan is crucial. Larger organizations may maintain a ticketing system with various queues that automatically contact configured staff when a ticket is assigned to that queue.

Whatever mechanism is implemented, it should be a reliable and efficient method for contacting whomever the organization wants working on the problem. Remember that a quick and organized response may mean the difference between a minor incident and a major catastrophe.

Identifying an Incident

Once the proper people have been notified, their primary goal is to perform a quick assessment of the situation, identifying any immediate actions required to contain and prevent further damage to systems. These are the immediate questions they need to answer:

Is this a security incident?

If it is a security incident, has the attacker successfully penetrated the organization’s systems, and is the attack still actively in progress?

If it is not a security incident, what is causing the alert?

If the incident appears to be a security breach, it is important to determine whether the attack is active or not and whether it is obviously successful. If it is not active or not successful, more time will be available for planning the response. If the attack appears successful or is still ongoing, decisive actions should be taken quickly to contain the breach.

Actions

The actual actions taken are influenced by the ultimate goals of the organization. Should an organization wish to prosecute an intruder, response plans should be careful to preserve and collect evidence. A number of legal requirements must be satisfied to have system evidence that is admissible in court. If an organization is not interested in prosecution, only in recovery, immediately shutting down affected systems and cutting off the attacker’s network path may be the most appropriate response.

While assessing the extent of the security breach, you may need to interact with the affected systems. The most important thing to realize when working with a potentially compromised system is that you should not trust it. Do not rely on system commands to report accurate information, and remember that logs may have been altered to hide the attacker’s activity.

Communication

Appropriate communication among response personnel, decision-makers, system owners, and affected parties is crucial when responding to an incident to prevent duplication of effort and people working at cross purposes. For example, the response team may decide to disconnect the affected systems temporarily from the network, but without proper communication, an application owner may think the system has a problem and take unnecessary steps to fix it. In addition, contacting vendors and ISPs may provide additional information about events going on outside of your particular network. The ISP can also provide information from its logs, which may shed light on the events. In certain situations, the ISP may also be able to implement upstream filters quickly to protect your network from the suspected attacker.

For system failures, IR plans should contain appropriate documentation for obtaining preapproved emergency authorization to make changes outside of normal change windows. If the root cause is not initially obvious, contacting the system vendor to report the problem and to gain access to the vendor’s support personnel may be necessary—IR plans should contain vendor contact information as well as the necessary information to gain access to support.

Recovery and Resumption

Once the incident has been contained, the organization can move into recovery and resumption mode to return the organization to normal operations. For system failures, this mode includes applying patches, making configuration changes, or replacing failed hardware. For security breaches, it focuses on locking down systems, identifying and patching security holes, removing intruder access, and returning systems to a trusted state.

Intruders can and will install programs and back doors (commonly using rootkits) to maintain and hide their access. Therefore, simply patching the security hole that enabled their access may not be sufficient to remove the back door into your system. The attackers may have replaced system components and software with a Trojan that allows remote connections or control. In addition, they may have replaced logging and auditing components so their presence on the system is not reported.

Rebuilding

The best avenue for recovery after an intrusion is to rebuild affected systems from scratch. Rebuilding is the only way to ensure that the system is free from Trojans and tampering. Once the system is rebuilt, restore critical data from a trusted backup tape (one created before the intrusion occurred, not necessarily the backup from the previous night). If critical data has been deleted that cannot be restored from a backup, however, forensics may be required to recover the data. In this situation, preserving the disk media to increase chances of data recovery is important.

Once the system is recovered to its previous operating state, be sure to remove the security vulnerability that allowed the intrusion in the first place. This may entail applying a patch, reconfiguring the vulnerable service, or protecting it via a more restrictive firewall rule set.

Review and Improvement

The final step in the process should consist of review. Performing an overall assessment of the incident allows the organization to identify response deficiencies and make improvements.

The review process should include the following elements:

Perform a damage assessment. How long were systems unavailable? Could systems have been recovered quicker if better backups or spare hardware were available? Did monitoring systems fail? Was any evidence of the impending failure not reviewed in timely manner?

For security breaches, was critical data accessed, such as trade secrets or credit card data? If so, does the organization have a legal responsibility to notify the stakeholders? If the attack was not successful, significant work may not be required. Even if the attack was unsuccessful, however, the organization may wish to increase its monitoring, especially if the intruder was aggressive and persistent.

Identify how the intrusion occurred and why it was not detected more quickly, ideally before it was successful. If needed, go back through firewall and IDS logs to find evidence of initial probing by the intruder.

Actions

Ensure that appropriate steps are taken to close the security hole on the affected machine, as well as to identify and similarly protect any other servers in which the hole might exist.

Review procedures to identify how the security hole may have come into existence. The origins of a security hole are numerous and can include such things as a failure to identify and apply a critical patch, a service misconfiguration, or poor password controls.

Beyond a simple review of the technical aspects of the attack, the organization should review its performance to identify areas of improvement. For example, how long did it take critical personnel to begin working on the problem? Were they reachable in a timely and simple fashion? Did they encounter any roadblocks while responding?

Should legal proceedings be under consideration, ensure that all evidence has been adequately collected, labeled, and stored, as described in the next section.

Forensics

The field of computer forensics is dedicated to the identification, extraction, preservation, and reporting on data obtained from a computer system.

Forensic analysis has a wide array of uses, including reconstructing or documenting user activity on a given system and extracting evidence related to a computer break-in.

Additionally, forensics can be used to recover a copy of data from a failed system or data that had been accidentally or maliciously deleted.

NIST SP 800-86

The National Institute of Standards and Technology defines a process for performing “digital forensics” in Special Publication SP800-86 as follows:

Collection: Identifying, labeling, recording, and acquiring data from sources while following procedures to preserve the integrity of the data.

Examination: Forensically processing collected data and assessing and extracting data of interest, while preserving the integrity of the data. This usually means working from a copy, rather than the original.

Analysis: Analyzing the results of the examination, using legally approved methods and techniques, to derive information that addresses the questions that inspired the collection and examination.

Reporting: Reporting the results of the analysis, which may include describing the actions used, explaining how tools and procedures were selected, determining what other actions need to be performed, and recommending improvement to aspects of the forensic process.

Legal Requirements

Forensic evidence that will be used in criminal proceedings must satisfy a number of legal standards to be admissible. Understanding those requirements before diving into the nuts and bolts of computer forensics is important. It would be very disappointing to have spent many tedious hours scouring a computer system collecting evidence only to have it thrown out in court due to improper procedure.

In a nutshell, forensic evidence is held to the same standards of evidence collection as any other evidence. These standards require that evidence is acquired intact without being altered or damaged. It also requires that the evidence presented be extracted from the crime scene.

Finally, the analysis must be performed without modifying the data. When the ultimate use of the evidence is unknown, or even if there is an extremely remote chance that the case will ever go to court, an examiner should remain diligent in his or her procedures and documentation. Improper evidence-handling procedures cannot be rectified later, should proceedings, in fact, end up in court.

Evidence Handling

The evidence must be presented without alteration. This requirement applies to the entire evidence lifecycle, from collection, to examination, to storage, and to its eventual presentation in a court of law. Once evidence has been taken into custody, you must be able to account for its whereabouts and ownership at all times. The documentation of the possession of evidence is known as the chain of custody. You must be able to provide a documented, uninterrupted chain of custody when testifying to evidence integrity. To protect the integrity of evidence when it is not being analyzed, it should be physically secured in a safe or an evidence locker. Additionally, a detailed log should be maintained of each person who accesses the evidence, the reason for the access, and the date and time it was removed and returned to storage.

Unrelated to the physical scene, but important nonetheless, is the identification of relevant management policies and procedures. Should a corporation wish to terminate or prosecute an employee for improper use of systems, they will need documented policies that establish what types of activities are prohibited. Policies should also establish that employees have no expectation of privacy and consent to monitoring when using corporate systems. Written policies that aren’t disseminated and acknowledged by employees, however, do little good. It is good practice to have employees acknowledge that they have read and understood such policies on an annual basis.

Evidence Acquisition

The process of acquiring evidence is perhaps the most sensitive and crucial step in the entire process. If done improperly, potential evidence may be lost, missed, or deemed inadmissible by the courts.

Computer forensic data can be classified as either network-based or host-based.

Network-based data comes from communications captured from a network-based system, such as a firewall or IDS. Some IDS products have a built-in ability to record network traffic for playback at a later date. This feature can be useful in reconstructing events surrounding a computer break-in. Logs of network firewalls can also provide insight into network activity and evidence.

Host-based data is the evidence found on a given system, and it can encompass a variety of different things, depending on what is being investigated. If the investigation is related to a break-in, a forensic examination may wish to detect the presence of foreign files and programs, document access to critical files, and any alteration to such files. When investigating unauthorized employee activity, the examiner may be attempting to reconstruct the employee’s Internet usage, recover e-mails, or identify documents that the employee should not have possessed.

Before touching the computer, an examiner must gain control of the immediate vicinity of the computers to be examined and document the surroundings. Note the location of important items, such as portable storage devices, power adapters, and assorted wiring (so you can disassemble and move it to another location without any difficulty, if necessary), and if it is still operating, note the contents of the display.

Photographs

A simple and effective way to document the scene indisputably is to take pictures.

The more thorough the documentation, the harder it will be to dispute the authenticity and accuracy of the evidence.

When collecting evidence from a crime scene, err on the side of over-collection: grab anything and everything that may contain evidence, such as laptops, PDAs (and their chargers), storage devices, CDs, and DVDs.

Label and seal each item that is collected from the scene, being sure to include the date and time and the specific location the item was recovered from with specific information such as “top-right drawer of desk.” An examiner rarely gets a second chance to return to the scene to pick up a forgotten item.

Tip:

While at the scene, check under keyboards and inside drawers to see if you can find a note with a password or two. These passwords may be used to log in to the system and gain access to accounts or encrypted files.

Computers

If the computer has not already been powered off, the examiner must make a critical judgment call: let it continue running or pull the plug. If the machine is already turned off, make sure it remains off until the appropriate images are made. Evidence must be presented without alteration, and the boot process of an operating system causes numerous changes to the drive media, such as updates to file access times and changes to swap space and temporary files.

Both approaches have their merits, and the individual situation dictates the best approach. Pulling the plug and freezing the system is usually considered safest and should never be construed as a wrong decision. By powering the machine off, the examiner cannot be accused of contaminating the system contents. In addition, once the system is frozen, the examiner has more time to formulate a plan without being concerned that more damage to systems could occur. In some cases, however, the only evidence available may be in memory, or management may have refused to allow the machine to be taken offline. The server may perform functions too integral to the business for it to be down for even a short time. Allowing the machine to continue to function may enable the examiner to monitor the intruder and obtain additional evidence. An examiner should be flexible and be prepared for either scenario.

Creating a Forensic Backup

When the machine can be taken offline, the examiner should make a forensic backup of the local hard drives. The goal of a forensic backup is different from that of a regular system recovery backup. A regular backup targets intact files and is designed to recover the system to a functioning state as quickly as possible.

A forensic backup, usually called a system image or bit-stream backup, is an exact duplicate of contents of the entire drive—including the free or “unused” space. The bit-stream method captures any and all partitions that have been created, whether used or not, and even unallocated space (drive space that has not yet been partitioned).

Thus, any data that may exist in file slack or in the file system, and anything written to disk not in the file system, will be captured. This way, when examining the forensic image (the original is rarely examined directly), you can recover deleted files and fragments of data that may have found their way onto one of these locations.

Hard Drive Partitions

Hard drives comprise many nested data structures. The largest structure on the drive is a partition. A hard drive can contain one or more partitions, each of which can be referenced separately by the OS. Partitions are often used to separate multiple operating systems on the same drive or to enable more efficient use of one very large drive. Information about the available partitions is kept in a special area of the disk called the partition table. Once the partition is created, a file system can be installed on it.

The file system is used by the operating system to store and access files in a simple and logical fashion. To function, the file system must be subdivided into evenly sized units. On a Unix system, these units are referred to as blocks, whereas on a Windows system they are known as clusters. These units are the smallest chunks that a file or piece of data can be stored in, and depending on the size of the file system, these units can be as small as 4 bytes but also can be upward of several hundred bytes. If a file does not fill the entire cluster, the remaining space is left unused and is referred to as slack. Thus, storing a 64-byte file in a 128-byte cluster actually leaves 64 bytes of file slack.

File slack is interesting to a forensic investigator because of what it may contain. If a smaller file overwrites a larger file, there may be remnants of the larger file in the file slack. Additionally, a sophisticated user may intentionally hide data in file slack to avoid detection. File slack is not transferred with a file when the file is copied to another drive or backed up in a non-forensic manner.

Backups

Bit-stream backups can be created in several different ways.

Dedicated hardware built for the purpose of disk duplication can be used to copy one drive to another.

If dedicated hardware is not available, you have to boot the system to an alternative operating system and mount the disk as read only.

Although many different software programs exist to make a viable forensic image of a system, you may have to prove to the courts that the backup is truly identical and the software used is reliable.

When using software to make an image, be sure to capture the entire drive, not just the file system in the main partition.

Hashing

As further support of an examiner’s claim that the image is an identical copy of the original drive, it is good practice to compute a hash value of the untouched original media. A hash value is produced by applying a cryptographic algorithm to the contents of the drive. Hashes are one-way, meaning that a set of data will produce a hash value, but the algorithm cannot be used to derive the original data from the hash. For the hash algorithm to be reliable, no two sets of data should produce the same hash value and any change to the data set will produce a different hash value. Currently, MD5 and SHA1 are the hash algorithms of choice. It is good practice to create hashes using two different algorithms, so if a flaw or attack is discovered in one hash, rendering it unreliable, the other hash can still be used to validate evidence.

In addition to hashing the original media, compute a hash value for the newly created image to ensure that the hash values match. If they don’t match, the image is not an identical image of the original and another image should be created.

Working with a Copy

Examiners commonly do not work directly with the original backup, but instead use an image of the image. This way, the original image can be safely locked up, and if a mistake is made or the evidence becomes corrupted, a fresh and intact copy still exists.

Working with a Live System

Should the decision be made to work on a live system, proceed with extreme caution! An attacker may be waiting for an authorized administrator to log in to complete an attack. The goal of working with a live system is to capture items that won’t survive the power-off process. These can include such items as the contents of physical memory and swap files, running processes, and active connections. Additionally, the trick is to capture these items as intact as possible. For example, asking a system to list running processes starts a new process, and this new process will require and use system memory. The output of any commands executed also needs to be captured.

Writing files to the local file system can potentially destroy evidence, as well. Be prepared to write output to remote systems via a network, or attach a local storage device that is capable of recording the output.

Capturing System Contents

The contents of computer memory and parts of the computer hard drive are highly volatile. When working with a live system, your initial steps are to capture information from the most to the least volatile. These are the major items to be captured:

CPU activity and system memory: CPU activity is one of the most volatile and, therefore, hardest things to capture accurately. Fortunately CPU activity is of little use to the forensic examiner and is not really worth the effort. The contents of system memory can be captured on a Unix system by dumping the contents of the /dev/mem and /dev/kmem files to a remote system.

Running processes: Documenting the active system processes can help the examiner understand what was occurring on the system at the time. Processes can be captured via the Unix command ps and via the Windows Task Manager.

Network connections: Documenting network connections serves two purposes: understanding what systems are currently connected and determining if any unknown processes are currently listening for incoming connections. The presence of such listeners is a telltale sign of an intrusion. On both Unix and Windows, use the netstat command to capture network connection information. In addition to netstat, capture the contents of the system’s Address Resolution Protocol (ARP) table by using the arp command, and capture the system routing table by using netstat with the -r switch.

Open files: You can caption open files on a Unix system with the lsof command (list of open files). For Windows, use the Handle utility from www.sysinternals.com.

Rootkits

If your investigation is occurring because of a security breach on the system, the examiner cannot initially determine the extent of compromise and, therefore, should not consider the victimized system to be trustworthy. The intruder may have taken steps to hide his or her presence on the system, such as replacing system commands to not report their presence on the system or doctoring logs to remove evidence of the break-in. Unfortunately, this is not as complicated as it sounds, and it has been largely automated through the proliferation of rootkits.

The Danger of Rootkits

Rootkits are automated packages that create back doors, remove incriminating log entries, and alter system binaries to hide the intruder’s presence. An intruder may well have installed a rootkit on a compromised system. On a Unix system, the ps command is used to list the running processes; a common rootkit function is to replace the system’s version of ps with a modified one that does not report any processes related to the intruder. Doing this means an unsuspecting administrator is left blind to intruder’s presence. When examining a compromised system, an examiner should maintain a set of trusted binaries on a CD or a set of floppies and run those in lieu of the binaries that are installed on the system.

Although this may be sufficient, a growing rootkit trend is to modify the actual OS itself. The ps command obtains its output by asking the OS to report what processes are currently active, and a newer type of rootkit, commonly called loadable kernel modules (LKMs), work by intercepting the actual request to the OS and removing the intruder’s processes from the output. The end result is that even if a trusted version of ps is run, the output will not list the intruder processes.

Detecting the presence of an LKM is more complicated and requires searching through the system memory contents. In a Linux environment, use the kstat command to search memory contents.

Evidence Analysis

Once a set of evidence has been obtained, you can begin analysis. Evidence analysis consists of a number of phases, and evidence may exist in a number of places. The most obvious place evidence may exist is in a file contained somewhere on the file system. But if the examiner is documenting unauthorized use of computer systems, evidence may need to be pieced together from temporary and swap files, identifying recently used files and relevant e-mails, reconstructing Internet browser caches and cookies, and recovering deleted files and pieces of data from local and possibly from remote file systems.

Forensic examiners need to be flexible. They encounter a myriad of systems and situations that test their skills and knowledge. The following sections provide an introduction to the various methods for extracting evidence from systems.

Examining the File System

When examining a file system for potential evidence, a forensic examination scours the entire disk in search of evidence. A growing challenge facing forensic experts today is the ever-increasing storage capacities of today’s disks. And computers may be connected to an external storage device or even a storage area network (SAN) with terabytes of storage. Unfortunately, files on the file system will be the most significant source of evidence, and you may find it necessary to inspect each and every file manually, searching through every byte for potential evidence or tampering. Such an endeavor on a large disk could keep an examiner busy for months.

Examining the File System with Software

In reality, the majority of files on a system are harmless and can be quickly discarded. However, how can the examiner be sure that a Windows device driver doesn’t contain hidden data, or that it really is a Windows device driver?

General forensic software, as well as specialized software, can be used to verify that common files have not been tampered with or are really what the filenames say they are. These programs work by using the same trusted MD5 and SHA1 hash algorithms used to authenticate drive images. An examiner can build a system with the same operating system, patch level, and installed programs as the suspect machine and then use one of these packages to obtain a cryptographic hash for each file on the trusted system. Once a trusted database has been created, its hash values can be compared to the cryptographic hashes of files on the target system. Files that have hashes that match those of the trusted system have not been tampered with and can be discarded, and those that don’t match need to be investigated further. A well-constructed database may eliminate the need to examine upward of 50 or 60 percent of the files on the system.

Examining Files

Once you reduced the population of files, you need examine the remaining files. When attempting to reconstruct and document the activity of the system owner, the most recently accessed files will probably be of significant interest. Each file on the operating system has a timestamp indicating the last time it was accessed.

The number of files on the system could still be significant, and going through them one by one can be time consuming. Several utilities are available to simplify the process of examining files and directory contents in bulk. Another time saver is to employ a utility that understands and can open many different file formats. This can be a significant time saver.

Another source of information that is of interest to an examiner is a user’s Internet usage history. An examiner will want to examine the browser cache, bookmarks or favorites, and cookie files to see what web sites the user visited recently.

Hidden Data

Unfortunately, not all evidence is sitting out in the open. Users may take the time to conceal the presence of incriminating data. A rudimentary way to hide evidence in a Windows environment is to change the file extension and place the file in a nondescript directory. For example, changing a file extension from .doc (a Word document) to .dll (a Windows system driver) and moving it from the My Documents directory to the Windows System32 directory (c:\winnt\system32) may hide it from a cursory search of file extensions and popular file-storage directories.

A more interesting search is to identify all files that have extensions that do not match the true type of file. Forensic programs can be used to seek out and identify such files. Another good practice is not to rely on a program, such as Windows Explorer, that is dependent on file extensions.

Unix environments do not rely on file extensions to determine file types, so such attempts at concealment do not apply. A popular Unix trick, however, is to precede the filename with a period (giving it a name such as “.hiddenfile”) or even making a file look like a directory by naming it with a period followed by a space (. ). A filename consisting of simply a period is the current directory in a Unix listing, so a period followed by a space would look the same.

Hidden files also exist in a Windows environment, so be sure to set Windows Explorer to show any and all hidden files.

Alternative Data Streams

The NTFS file system enables a single file to have an alternative data stream (ADS). The ADS can be used to store data or other files, and its presence is almost completely hidden behind the primary data stream. ADS functionality was originally developed to provide compatibility for Macintosh users storing files on NT-based systems.

Windows Explorer does not indicate the presence of the alternative data stream, and most antivirus programs overlook its existence as well.

Using the command line, you can place one file into another’s ADS.

This image shows an empty file created on an NTFS drive in Windows. Once the file exists, you can hide text in the file’s ADS, but the file is still reported as being 0 bytes long.

An ADS can be created without an actual file!

For particularly sneaky users, data can be directly hidden in an ADS without a filename. The next example image takes a file called evidence.doc, hides it in an ADS without a filename, and then deletes the original file. To prove its presence, you can do a type on the ADS to show that it’s there.

An ADS can be created without an actual file!

Deleted Data

The act of telling an operating system to delete a file doesn’t actually cause the data to be removed from the disk. In the interest of saving valuable CPU cycles and disk operations, the space used by the file is simply marked as available for the operating system. Should a need for the disk space arise at a later time, the data will be overwritten, but until then the actual data is left intact on the disk. Several third-party programs are specifically designed to retrieve deleted files from Windows systems. Before searching the drive, however, be sure to check the Recycle Bin contents for anything useful.

Even if the section of disk gets reused, you may find parts of the original file in the slack space. Advanced tools and techniques also let you determine what was on the disk before the data was erased or overwritten. Much like a blackboard that has not been thoroughly cleaned, a faint image of the original file is left behind on a disk. To delete data securely from a disk, you have to overwrite the section of disk on which the file resided with a file-wiping program. The wiping program overwrites the section of disk many times with binary ones and zeros to destroy all trace elements thoroughly from the drive.

Note:

Guidelines published by the National Security Agency indicate that it is possible to recover meaningful data from a disk that has been overwritten more than 20 times.

Encrypted and Compressed Data

Encryption is a technique a person can use to hide data on a system.

Compression is commonly used to bundle multiple objects into a single smaller object to conserve resources. Compression can be viewed as a weak form of encryption. The difficultly posed by compression is that any data contained in a compressed file will be missed by a keyword search on the hard drive. Although decompressing the file is likely a trivial process, the examiners can’t decompress and search such files if they’re unaware of their existence.

Encryption poses similar problems, but decrypting files is most likely not a trivial exercise. Beyond detecting the presence of the encrypted data, you have to decrypt and inspect the contents of those files. If the suspect is unavailable or uncooperative and will not provide access to the files, you may have to find alternative means to decrypt the data.

In addition to encryption, a forensic examiner may encounter files protected by a password or may need to decrypt the OS login passwords. Unfortunately for security professionals, but fortunately for forensic examiners, people don’t normally use strong passwords, providing the investigator with the opportunity to guess the password and even making a brute-force attack possible.

Keyword Searching

Examiners generally have some idea of the topics that are relevant to the investigation, so an excellent way to find evidence is to perform keyword searches on the hard drive. A keyword search is a bit-level search that goes systematically through the drive looking for matches. Although string searching will not decipher encrypted text, it may turn up evidence in file slack, regular or misnamed files, swap space, and data hidden in alternative data streams.

The trick with string searching is finding an exact match and determining exactly what to search for. When defining search terms, including some spelling deviations may be helpful; for example, if you’re looking for an address such as “56th Street,” be sure to search for “56th St.” and “fifty-sixth street.” Most forensic programs have fuzzy logic capabilities that automatically search on similarly spelled words.

Compliance with Laws During Incident Response

This section provides practical pointers on legal issues that often arise for information security professionals during responses to incidents and litigation.

Law Enforcement Referrals—Yes or No?

A key decision faced by any entity responding to an information security incident is whether to contact law enforcement. With the advent of reporting requirements in some states that oblige persons with knowledge of computer crimes to report them to law enforcement officials, an entity may have no choice in the matter. But when such contact is optional, there are often pros and cons to involving government officials in an incident.

Any voluntary decision to involve law enforcement necessarily demands a cost-benefit analysis. An entity with its own investigative resources might consider whether those resources are sufficient for the task, whether civil remedies are adequate for the harm suffered, and whether involving law enforcement will limit or entirely deny the opportunity to file a civil suit.

Preservation of Evidence

As the masters of their organization’s mail server domains, information security managers are often called on to design or implement automatic e-mail retention policies. In many sectors, entities are now required by law to maintain copies of certain electronic communications for defined periods of time. Retention issues also arise in the context of civil litigation, where parties are increasingly focused on the opposing side’s e-mail and document management systems, with the result that information security professionals are finding themselves being deposed as fact witnesses.

Role of Information Security in Litigation

Information security professionals should be familiar with retention policies and adhere to them. It can be uncomfortable to get caught in a deposition (or preferably in a preparation session with your organization’s own counsel) trying to explain why six months’ worth of e-mail on the server that should have been purged still exist and are easily searchable, or worse yet, why documents that should have been preserved have been deleted. Information security staff should be prepared to work with in-house counsel to establish a protocol for working with electronic evidence immediately on counsel becoming aware that the organization may be involved in litigation. Finally, information security managers should never delete information in the context of litigation, especially outside of normal practices, and should refuse any suggestions to do so by management. Such actions potentially carry severe consequences in litigation.

Attorney-Client Privilege

The attorney-client privilege is the oldest of the privileges for confidential communications known to the common law. The purpose of the privilege “is to encourage full and frank communication between attorneys and their clients and thereby promote broader public interests in the observance of law and administration of justice.”

Accordingly, communications exchanged during an incident response that are made in the presence of counsel, and for the purpose of soliciting legal advice from counsel on how to proceed, may be protected by the attorney-client privilege. It is imperative, however, to ensure that all significant strategic information exchanged in a privileged setting not be disclosed outside that setting—for example, to any third party, such as law enforcement, a technology vendor, an upstream victim, or someone else in the organization outside the presence of an attorney. Disclosure outside of the privilege circle results in a waiver of all communications actually disclosed and potentially of all other privileged communications concerning that same subject matter.

Attorney Work Product

Written materials prepared by counsel during an incident may also be protected under the attorney work product doctrine. The work product doctrine shields documents prepared in anticipation of litigation as part of a “strong public policy underlying the orderly prosecution and defense of legal claims.” Relying on counsel to be the member of the incident response team responsible for drafting all memoranda memorializing the gathering of facts and subsequent strategic decisions about third-party notifications, investigative steps, and the like, affords the possibility of claiming work product protection in any later litigation.

After-Action Assessments

Finally, in the wake of an incident, many organizations conduct after-action assessments, in which they evaluate and critique their response to an incident, in hopes of preventing any mistakes from reoccurring and evaluating any improvements that can be made in security protections or response protocols.

These exercises are useful and necessary and often provide the impetus for information security budget increases. Particularly because of the last point, these assessments can contain dire predictions about future consequences if certain problems are not remedied.

When reduced in writing and viewed as a detached, cold record in the context of a lawsuit concerning a security breach two years down the road, however, such documents can prove to be a litigation nightmare. Accordingly, organizations should take steps to protect the confidentiality of after-action assessments.

Summary

The primary goal of intrusion response is to detect and respond effectively to disruptions of normal computer operations. Responding to an incident includes contacting appropriate personnel, identifying the cause of an outage, and developing and implementing a recovery plan. Finally, one of the most important but often overlooked steps of the incident response is to review the organization’s performance and make improvements.

Computer forensics has many applications in today’s modern world. Forensics can be used to investigate and document the use of a computer system, extract evidence in support of a criminal investigation or civil suit, and recover data that has been deleted or that was lost during a drive failure. Regardless of the purpose, when you are performing forensic work, it is imperative that information be captured intact and without alteration. Numerous forensic tools are available, and a good investigator will be familiar with many of them.