The Complete Reference™: Information Security

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.

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.

• Incident detection

• Response and containment

• Recovery and resumption

• Review and improvement

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. Intrusion detection systems (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. These technologies are covered in Chapter 18.

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.

• 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?

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 in order to have system evidence that is admissible in court (which is discussed in the “Forensics” section of this chapter). 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. The “Forensics” section provides more detailed information about working with a potentially compromised system.

Appropriate communication, between 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 temporarily disconnect the affected systems 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 their logs, which may shed more 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.

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.

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.

• Perform a damage assessment. How long were systems unavailable? Could systems have been recovered quicker if better backups or spare hardware was available? Did monitoring systems fail? Was there evidence of the impending failure that was not reviewed in a 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.

• Ensure 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.

The field of computer forensics is dedicated to the identifying, extracting, preserving, 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.

• 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.

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 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. For cases where 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.

As stated, 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.

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.

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.

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. The forensic imaging process is discussed in greater detail shortly.

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.

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 drives are actually comprised of many nested data structures. The largest structure on the drive will be a partition. A hard drive can contain one or more partitions, each of which can be referenced separately by the operating system. 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.

Bit-stream backups can be created 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.

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.

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.

• 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 platforms, 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 capture open files on a Unix system with the lsof command (list of open files). For Windows, use the Handle utility from www.sysinternals.com.

The Danger of 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.

Rootkits are automated packages that create back doors, remove incriminating log entries, and alter system binaries to hide the intruder’s presence, and 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, and a common rootkit function is to replace the system’s version of ps with a modified one that conveniently 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 operating system itself. The ps command obtains its output by asking the operating system 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 operating system 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.

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.

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 of tampering. Such an endeavor on a large disk could keep an examiner busy for months.

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.

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.

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.

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 make it possible to 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.

Encryption is a technique that an individual can use to hide data on a given 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 most likely a trivial process, the examiners can’t decompress and search such files if they’re unaware of their existence.

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. Figure 33-3 shows forensic software performing a keyword search on a hard drive.

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 but to contact law enforcement. But in cases where such contact is optional, there are often pros and cons to involving government officials in an incident.

• It sends a powerful message to would-be predators that an organization will report incidents.

• It can potentially save money—the government takes on some of the burden of investigation.

• It provides access to more powerful investigative tools—the government can use search warrants and the grand jury, whereas private entities are limited to civil discovery.

• It allows for mandatory restitution for damages under the Mandatory Victims Restitution Act, where victims are entitled to recover the “full amount of each victim’s losses”¹ for most federal offenses.

• There is often no likelihood of recovery through civil litigation.

• Doing so cedes control over the process, which can potentially lead to timing, coordination, and interference issues.

• It creates some danger of exposing internal information.

• It creates potentially bad publicity regarding your organization information security.

• It can disrupt business activity.

• It potentially exposes any wrongdoing in which the plaintiff itself may have engaged.

• The client waives attorney-client privilege.

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.

The Securities and Exchange Commission (SEC), the National Association of Securities Dealers (NASD), and the New York Stock Exchange (NYSE) have each recently imposed obligations on covered entities to retain electronic communications, such as e-mail and instant messaging. Whereas some of the obligations derive from explicit retention requirements, others arise as a practical matter in the course of satisfying employee supervision and control requirements.

SEC Rule 17a-4 requires covered entities, which includes exchange members, brokers, and dealers, to “preserve for a period of not less than three years, the first two years in an easily accessible place … originals of all communications received and copies of all communications sent (and any approvals thereof) by the member, broker, or dealer (including inter-office memoranda and communications) relating to its business as such.”² Subsequent consent decrees and interpretive decisions have consistently applied the three-year retention period to e-mail and other electronic communications.³ Records stored on electronic media must meet a detailed set of format requirements: the media must (1) preserve records exclusively in a non-rewritable, non-erasable format; (2) verify automatically the quality and accuracy of the storage media recording process; (3) serialize the original and duplicate units of storage media; and (4) time-date for the required retention period the information placed on the electronic storage media. In addition, the entity must have the capacity to download indexes and records preserved on the media to other media.⁴

NASD Rule 3110 incorporates the requirements of Rule 17a-4, and a recent NASD release has indicated that instant messaging communications are covered by its retention requirements.⁵ The SEC has yet to rule on the retention of instant messaging, but it is reasonable to anticipate that it will follow the lead of the NASD. In addition to these detailed retention requirements, the NASD and NYSE both require members to develop written procedures for reviewing incoming and outgoing communications with the public relating to investment.⁶ Such communications include electronic communications. Compliance with these procedures is not possible without a retention policy in place so that the communications can be stored for later review.

The SEC, NASD, and NYSE have displayed a willingness to enforce their rules regarding retention of electronic communications, as emphasized by a recent $8.25 million settlement with five large financial services companies, which resulted from their failure to retain e-mails.⁷ As such, entities in the financial services industry should be on notice that compliance with retention rules is essential immediately. Even those outside of financial services should be aware of the requirements and be prepared for regulation by their own industries, in much the same way that other industries have adopted safeguards similar to Gramm-Leach-Bliley’s information security standards.

In the context of litigation, parties are increasingly mindful that the most meaningful evidence is often maintained in electronic form. For this reason, it is now commonplace to begin the discovery process in litigation (the procedure by which the opposing parties request and produce relevant evidence to each other) with an initial request that the opposing party identify their basic network topology and electronic document retention practices. Rule 26(b)(2) of the Federal Rules of Civil Procedure gives courts the power to limit discovery “if the burden or expense of the proposed discovery outweighs its likely benefit.” The burden of providing information about these systems, and even of restoring documents from backup media, however, is unlikely to be considered overly burdensome. “Upon installing a data storage system, it must be assumed that at some point in the future one may need to retrieve the information previously stored. That there may be deficiencies in the retrieval system … cannot be sufficient to defeat an otherwise good faith request to examine the relevant information.”⁸

Depending on the party and its counsel’s level of sophistication, these requests may seek information about all software and hardware used in the storage and transfer of documents and electronic communications and about routine backup and disaster recovery procedures, and they may probe a party’s ability to restore electronic evidence. In nearly all cases, these requests overtly emphasize identifying the universe of media where relevant evidence might be found and implicitly scrutinize the responding party’s forensic and retention practices. This somewhat recent development has had the secondary effect of turning information security managers into regular witnesses.

For this reason, 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 the litigation.

NOTE In Kucala Enterprises, Ltd. v Auto Wax Co., Inc., 2003 WL 21230605 (N.D. Ill. 2003), the court held that litigants “have a fundamental duty to preserve relevant evidence over which the non-preserving entity had control and reasonably knew or could reasonably foresee was material to the potential legal action” in granting a defendant’s motion to dismiss and for an award of attorneys’ fees as sanctions for the plaintiff’s use of the software program “Evidence Eliminator” to delete over 15,000 potentially relevant computer files.

In the wake of an incident, an organization must, as a matter of course, perform investigations, review responses, and evaluate the effectiveness of its incident response plans. Reports and documents generated by these processes, however, can be subject to discovery if the organization later faces legal challenges related to the incident. Thus, an organization’s ability to keep communications and strategic decisions made during the incident response confidential can be of the utmost importance in any potential litigation that might follow. One helpful legal doctrine that can provide some confidentiality protection is the 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.”⁹ Against this background, the attorney-client privilege ensures that “[w]here legal advice of any kind is sought . . . from a professional legal adviser in his capacity as such . . . the communications relating to that purpose, . . . made in confidence . . . by the client . . . are at his instance permanently protected . . . from disclosure by himself or the legal adviser” except when waived.¹⁰

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.

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.”¹¹ It “is intended to preserve a zone of privacy in which a lawyer can prepare and develop legal theories and strategy ‘with an eye toward litigation,’ free from unnecessary intrusion by his adversaries.”¹² As a result, “[w]here a document was created because of anticipated litigation, and would not have been prepared in substantially similar form but for the prospect of that litigation,” the work product doctrine bars its discovery.¹³ Accordingly, 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.

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 recurring 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 to 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.

• The information must result from a critical self-analysis undertaken by the party seeking protection.

• The public must have a strong interest in preserving the free flow of the type of information sought.

• Flow of such information must be curtailed if discovery were allowed.

• The document must be produced with an expectation of confidentiality, and the confidentiality must be maintained.

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 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.

Jones, Keith, and Richard Bejtlich. Real Digital Forensics: Computer Security and Incident Response. Addison-Wesley, 2005.

Kruse, Warren, and Jay Heiser. Computer Forensics: Incident Response Essentials. Addison-Wesley, 2001.

Maras, Marie-Helen. Computer Forensics: Cybercriminals, Laws, and Evidence. Jones & Bartlett Learning, 2011.

National Institute of Standards and Technology. Special Publication 800-72: Guidelines on PDA Forensics. http://csrc.nist.gov/publications/nistpubs/800-72/sp800-72.pdf

National Institute of Standards and Technology. Special Publication 800-86: Guide to Integrating Forensic Techniques into Incident Response. http://csrc.nist.gov/publications/nistpubs/800-86/SP800-86.pdf

National Institute of Standards and Technology. Special Publication 800-101: Guidelines on Cell Phone Forensics. http://csrc.nist.gov/publications/nistpubs/800-101/SP800-101.pdf

Nelson, Bill, and Amelia Philips. Guide to Computer Forensics and Investigations. Course Technology, 2009.

Prosise, Chris, and Kevin Mandia. Incident Response and Computer Forensics. McGraw-Hill, 2003.

Schultz, Eugene, and Russell Shumway. Incident Response: A Strategic Guide to Handling System and Network Security Breaches. Sams, 2001.

van Wyk, Kenneth, and Richard Forno. Incident Response. O’Reilly, 2001.

Volonino, Linda, and Reynaldo Anzaldua. Computer Forensics: Principles and Practices. Prentice-Hall, 2006.

Whitman, Michael, and Herbert Mattord. Principles of Incident Response and Disaster Recovery. Course Technology, 2006.

¹ 18 U.S.C. § 3664(f)(1).

² SEC Rule 17a-4(b)(4).

³ See In re Robertson Stephens, Letter of Acceptance, Waiver and Consent No. CAF030001 (Jan. 2003), p. 12; In re Deutsche Bank Securities, Inc. et al., Letter of Acceptance, Waiver and Consent No. CAF020064 (Nov. 2002), p. 5; SEC Release No. 34-38245 (Jan. 1997) (“Electronic Records Release”), p. 16.

⁴ SEC Rule 17a-04(f).

⁵ See NASD Notice to Members, Instant Messaging: Clarification for Members Regarding Supervisory Obligations and Recordkeeping Requirements for Instant Messaging (July 2003), p. 343.

⁶ See NASD Rule 3010(d); NYSE Rule 342.17.

⁷ See In re Deutsche Bank Securities, Inc., Goldman, Sachs and Co., Morgan Stanley & Co., Inc., Salomon Smith Barney, Inc., U.S. Bancorp Piper Jaffray Inc., Letter of Acceptance, Waiver and Consent No. CAF020064 (Nov. 2002).

⁸ Kaufman v Kinkos, Inc., Civ Action No. 18894-NC (Del. Ch. Apr. 16, 2002).

⁹ See Upjohn Co. v United States, 449 U.S. 383, 389 (1981) (citing 8 J. Wigmore, Evidence § 2290 (McNaughton rev. 1961)).

¹⁰ See In re Richard Roe, Inc., 68 F.3d 38, 39-40 (2d Cir. 1995).

¹¹ See United States v Nobles, 422 U.S. 225, 236-37 (1975) (quoting Hickman v Taylor, 329 U.S. 495 (1947)); see also Upjohn Co. v United States, 449 U.S. 383, 397-98 (1981).

¹² See Hickman v Taylor, 329 U.S. 495, 510-11 (1947).

¹³ See United States v Adlman, 134 F.3d 1194, 1195 (2d Cir. 1998).