RECOMMENDATIONS

---

Details of the recent arrest of U.S. Federal Bureau of Investigation Special Agent Robert P. Hanssen for espionage highlight the need for increasingly sophisticated computer forensic imaging and analysis tools and methodologies for their proper use. The FBI conducted a search of Mr. Hanssen’s briefcase in 2001 and found a “computer memory card,” from which they were able to retrieve a digital copy of a note Mr. Hanssen wrote to his Russian handlers in 2000. The digital copy was made in the off-limits room Hanssen kept in his basement—the one with two computers that authorities believe he used to maintain his own spy operation.

Few of us will ever be in as tense a situation as the one the FBI faced recently with Mr. Hanssen and the “computer memory card” or the off-limits room in the basement. Mess that up from an evidence-handling perspective and a major international espionage case could evaporate. But, no matter where you work in the computer security field, you may one day find yourself faced with a tough investigative challenge, looking for the right tools to accomplish an incredibly important job, facing near impossible deadlines—and always with the thought in the back of your mind that if you mess something up, life as you know it could change drastically.

The need for technical investigative capabilities has been growing steadily with the proliferation of computers in the workplace. And the discipline of computer forensics has emerged to meet that need. But computers being what they are, it takes a computer and a robust set of applications to analyze another computer in such a manner that the results of the analysis are thorough, sound, unbiased, and repeatable. That’s where the various developers and vendors of computer forensic analysis software come in. Each developer has his or her own unique perspective on the needs of the investigative community and his or her own approach as to how to meet those needs. But few have started the software-development process with a well-stated computer forensic analysis requirements document.

What tasks must computer forensic analysis software be able to accomplish? And how can you measure the performance of various tools against one another without a well-defined requirements definition? The speed of a forensic analysis tool is of little consequence if it is not also thorough, unbiased, and forensically sound; so speed alone cannot be the primary consideration. And the knowledge, skills, and experience of the analyst at the keyboard can also play a significant factor in the performance of a tool, when no thorough requirements document exists.

This final recommendations chapter is concerned with how to conduct a relevant and meaningful review of computer-forensic-analysis software tools. Let’s start with a requirements definition.

With more practitioners involved in stating requirements and designing tests, the tests will be more relevant to the computer forensics community. And, hopefully, where tools fall short of meeting requirements, developers will take the results to their labs and work to improve the tools. So, it is the intent of this recommendations part of the chapter to initiate discussion and solidify the various computer forensics requirements.

Requirements Definition

Let’s begin this look at requirements by identifying certain capabilities that a forensic examiner needs, based on tasks the examiner must perform to complete a thorough, unbiased, and forensically sound examination of computer media. The requirements definition is not intended to mandate specific procedures or to endorse certain products. It is also not intended to mandate that any specific software tool be used in any specific set of circumstances. Where possible, the requirements definition is also media independent, operating system independent, file system independent, and hardware platform independent.

This requirements definition also takes into account the fact that law enforcement officers have different requirements than corporate security/investigations personnel. Whereas law enforcement officers typically have legal authority to seize computer systems as evidence in criminal cases, corporate security/investigations personnel are typically involved in civil cases and rarely have authority to seize equipment. But corporate security/investigations personnel typically have some authority to preview systems, determine which ones may have relevant evidence, and preserve evidentiary images of systems deemed to contain relevant evidence. Likewise, where the law enforcement officer may remove evidence to a lab environment for analysis, the corporate security officer will typically remove only evidentiary images of media, leaving the original media on-site.

At a fairly fundamental level, the forensic analysis toolbox needs certain capabilities. For instance, you must be able to complete forensically sound searches of computer media at both the logical and physical levels of the media. That requirement exists because certain data in the logical file system may not be readily available or readable at the physical level. As an example, much of the Windows registry is written physically to disk in binary form, but is readable logically with a tool such as REGEDIT.EXE. Adobe Acrobat portable document format (.PDF) files are, likewise, physically written to disk in a manner that obscures the textual content of the document. Compressed files, encrypted files, and other “special” files written physically to disk in a format other than text format, likewise, will not show their real content at the physical level.

A search of computer media at the physical level also might miss plain text words in a document, if the document is fragmented physically on disk and the word of interest is partially contained at the end of one sector and the beginning of a noncontiguous sector. Only a logical search of the file system can ensure that relevant text contained in logical files fragmented physically on disk is found, because a logical search can account for fragmentation.

This requirements definition also sets forth minimum requirements for functionality taking into account a wide variety of technical, logistical, and legal circumstances. The “Identify–Preserve–Analyze–Report” model continues to serve to describe the overall process investigators use to conduct an investigation involving computer-based evidence. An investigator at a crime scene must be able to identify computer systems or media possibly containing digital evidence relevant to the case. If a crime scene contains computers, and investigators leave the scene without them (or without forensically sound evidentiary images of them), then the process ends and no analysis or reporting can take place. Any evidence on the media is possibly lost.

Once an investigator identifies the systems or media possibly containing data of an evidentiary nature, he or she must properly preserve their digital contents in a forensically sound manner. After preserving the evidence, an investigator will conduct some series of examinations (analyze) of the data on the media to extract from it relevant information. After identifying relevant media, preserving appropriate evidentiary images of the media, and conducting a thorough, unbiased, and forensically sound examination of the media, the investigator will report the results of their efforts in some fashion.

The capabilities an examiner requires in any one step of the process may sometimes overlap with capabilities required in other steps. Essentially, without the capability to do each of these functions, an investigator might not have in his or her toolkit the requisite tools necessary to accomplish a thorough, unbiased examination of media, finding all relevant and potentially incriminating or exculpatory evidence on the media under examination. But it is recommended that the following capabilities be useful as a starting point to develop a set of minimum requirements:

1. An investigator requires a capability to simultaneously preview a large number of systems on-site to determine which ones contain relevant evidence.

2. An investigator requires the capability to conduct a search at the physical level of the target media, ignoring operating system and file system logical structures, and searching from sector 0 to the end of the media regardless of the logical content.

3. The search tool must be able to reliably report the physical location on the media where responsive data were found.

4. An investigator requires the capability to conduct a thorough, read-only search at the logical level of the target media.

5. An investigator requires an ability to generate a listing of all logical files in a file system.

6. An investigator requires an ability to search the contents of the regular files in a file system without changing either the data in the file or any date/time data recorded by the operating system about the file.

7. An investigator requires an ability to identify and process special files.

8. Investigators require the capability to recover pertinent deleted files or portions thereof that have not been overwritten.

9. Investigators require the capability to make forensically sound images of a wide variety of media.

10. Investigators require the capability to restore forensic images to suitable media.

11. Investigators require the capability to perform a sector-by-sector comparison of two pieces of media to determine where they differ.

12. Investigators require the capability to thoroughly document their investigative activities and succinctly document the data recovered from a piece of media that are relevant to the allegations under investigation.

Simultaneously Preview a Large Number of Systems on Site

In some situations, identifying which computers or media at a scene may contain information or data of evidentiary value is fairly straightforward. The hacked Web server, a compromised file server, a firewall, or other networked devices may be, due to the nature of the investigation, an obvious system to preserve. But, in other cases, particularly where the allegation concerns activities of insiders, it may not be so easy to determine which systems contain information of evidentiary value. In cases where an office has multiple computers, and a subset of those computers might contain relevant evidence, then seizing or imaging all the computers at that site could be a tremendous waste of vital resources.

In most cases, an initial search at the physical level of the media may be sufficient to determine if a specific computer system or piece of media contains relevant information and should be imaged/preserved for further, more detailed analysis. However, keep in mind that a fruitless search at the physical level may have actually missed relevant information for a wide variety of reasons, including that relevant keywords in logical files may be physically fragmented on disk; relevant files may be compressed or encrypted; or relevant files may be otherwise encoded or obscured. So, the investigator must decide, based on the circumstances of the case, whether a fruitless search at the physical level of the media is sufficient to exclude the media from further processing. Previewing computer media has two subcomponent requirements: a validated read-only methodology and a controlled boot process.

Validated Read-only Methodology

For previewing media on scene, an investigator requires a capability to preview media using tools and methodologies that have been tested under various circumstances and validated not to make changes to the original media. Otherwise, the preview process itself may taint the evidence by changing pertinent date/time stamps on files or otherwise modifying data on the target media. Unintentionally modifying date/time stamps in particular could unnecessarily complicate the evidence-analysis process.

Controlled Boot Process

For previewing media on scene, an investigator requires a boot process that can be precisely controlled. Whether the preview process will be done via a remote connection to a computer system or will be executed locally on the system, the investigator must know exactly what the boot process is, ensure that the boot process used does not make changes to any of the data on the media to be previewed, and ensure that the preview tools and methodologies are forensically sound.

The preview process itself can be conducted several ways, including either remotely or locally. A local preview of media involves using a controlled boot process to boot the suspect machine and conduct a review of the system locally. If the entire process can be contained on floppy diskette or bootable CD-ROM, this could allow as many simultaneous iterations as there are suspect systems to be previewed. But the local preview process must not make changes to the media being previewed.

Like a local preview, a remote preview must be conducted in such a manner that it does not make changes to the media being previewed. If the investigator uses a tool with a remote preview capability, they will actually boot two computers: the one housing the media to be previewed and the one from which the preview will be accomplished. Using a remote preview capability may limit the number of simultaneous iterations that can be conducted because it requires more hardware; but, in cases where only a few systems need to be previewed, a remote capability could be very useful. Typically, remote previewing involves connecting two computers via a parallel port, com port, video port, or other port, running a “server” version of an application on the machine to be previewed, and running a “client” version of the software on the machine from which the preview is conducted. No matter the exact mechanism used, the preview process must be forensically sound, and must not make changes to the media being previewed.

Conduct a Search at the Physical Level of the Target Media

A physical search of the media essentially searches all logical files, file slack, free or unallocated space, and all space on the media outside any logical data areas. The search tool must have the ability to use both ASCII and UNICODE character sets. Some operating systems write documents and other files to disk using printable and nonprintable ASCII characters. But other operating systems can use the UNICODE character set as well as the ASCII character set. A search for a word using the ASCII character set will not find that word if it is written to disk using the UNICODE character set. So an investigator requires a search tool that can use both character sets in its searches. Preferably, a single pass through the media will search using both character sets simultaneously.

The search tool must be capable of searching all sectors of the physical media. If the tool cannot see and search all sectors of the media, the resultant search may not be thorough enough to establish that evidence either does or does not reside on the media.

The search tool must be capable of using a keyword list. Tools that require separate passes through the media to search for each keyword would unnecessarily constrain the investigator in terms of both time and efficiency, especially when searching one of today’s 80GB and larger hard drives. The keyword list must be able to include regular ASCII text as well as hexadecimal notations. Some file type headers and all binary files will contain nonprintable ASCII characters. Hexadecimal notation is the best way to search for this type of data.

Report the Physical Location on the Media

This report could use either the cylinder-head-sector (CHS) or logical block addressing (LBA) address of the responsive data. In the best case, even though a physical search is conducted, the search tool may be able to determine whether the keyword resides in a logical file on the media, file slack, free space, or areas of the media outside the logical data area.

The search tool must be able to show results in context. Rarely is a keyword or phrase so unique to an investigation that its mere presence on a piece of media indicates the media contains data of evidentiary value. The investigator must be able to discern the context within which a word or phrase resides on the media to determine whether the context is relevant to the investigation. So, the search tool must be capable of displaying some amount of data that resides on disk immediately prior to the keyword and some amount of data that resides on disk immediately after the keyword. Otherwise, the investigator must use a hex editor to preview each sector containing the key word to determine whether it actually contains relevant data.

An investigator also requires the ability to calculate a hash of the physical media. The hash process must take into account every bit of every byte of every sector on the media, from sector 0 to the last physical sector, regardless of whether any specific sector is included in any logical volume on the media. In most cases, the minimum standard is the 32-bit cyclic redundancy check (CRC) algorithm. But for hard drives, the 128-bit message digest 5 (MD5) algorithm is preferred.

Conduct a Thorough Read-only Search

A search of the logical file space is likely to require less time than a search of the physical media, but likely will not search every sector of the media. If an investigator begins with a logical search to preview media, and that search produces no relevant results, the investigator may have to follow up with a search of the physical media to ensure a thorough search. And if the search tool used on one logical partition does not understand the file system formatting of another partition on the media, then a different search tool must be used on the other partition. For instance, a hard drive may be partitioned and formatted to boot multiple operating systems, each using a different file system. That may require several logical level search tools if no one tool understands all the file systems on the media.

As with the physical level search, the search tool must have the ability to use both ASCII and UNICODE character sets. This is for exactly the same reasons as previously stated, on searching at the physical level.

The search tool must be capable of searching all sectors within the logical boundaries of the file system. If the tool cannot see and search all sectors of the file system, the resultant search may not be thorough enough to establish that the evidence either does or does not reside on the media. And for reasons already stated, the search tool must be able to use a keyword list.

Generate a Listing of All Logical Files

This listing must include not only all the regular files in a file system but also all files with special attributes, such as hidden files, read-only files, system files, executable files, directories, links to files, device files, and so on. And, the tool that creates this list must be able to write the list of files to appropriate media, whether that is a network accessible volume, a local hard drive not under investigation, or some appropriate removable media connected to the analysis machine. Preferably, the tool that generates the list of files would not allow the list to be written to the media being searched.

In addition, an investigator requires an ability to generate a listing of all the date/time stamps an operating system may store in relation to each file in the file system. Some operating systems store various dates and times in relation to the files in the file system. Those dates/times may include Date/Time Last Modified, Date/Time Last Accessed, or Date/Time Created. Not all operating systems record all date/time combinations. But if an operating system records any date/time stamp data in relation to files in a file system, the tool must list all date/time data available.

Furthermore, an investigator requires the ability to identify and generate a listing of all deleted files in the file system. Various operating systems handle deleting files in various ways, so the specific capability of a tool will be dependent on the file system the tool is examining, but to some degree, all file systems have a way of at least identifying that a file once existed in a certain space.

Search the Contents of the Regular Files

Searching the contents of the regular files is a particularly important requirement for the search tool. If the search tool opens a regular file to search its contents for a keyword, and that process changes either the file contents or a date/time stamp maintained by the operating system about the file, then the investigator may have to restore an image of the media to get back to the original file contents or date/time stamps. Some search tools that operate at the logical level of the media do not quite meet this requirement, because most operating systems keep a Date/Time Last Accessed timestamp and will attempt to update this stamp when the search tool opens or closes the file.

It is particularly important to test search tools under very controlled conditions to ensure they actually meet this requirement. If a search tool, in fact, allows the operating system to update Date/Time Last Accessed when the tool runs, then the investigator must take steps to preserve those date/time stamps prior to using the search tool.

An investigator also needs the capability to validate file types where applicable using known header-extension pairs, and to hash all the logical files using a recognized and appropriate hashing algorithm. In most cases, the minimum standard at a file level is the CRC algorithm. But for very large files, the MD5 algorithm is preferred.

Ability to Identify and Process Special Files

Special files are in a format in which their contents are either not written to disk or not maintained internally in a readily readable, searchable format. “Special files” include encrypted, compressed, or password-protected files; steganographic carrier files; graphics files, video files and audio files; .PDF format files; executable files or binary data files; files housing e-mail archives and/or active email content; swap files or virtual memory files; and other such file formats that obscure their plain text content. Some password-protected files can be processed in a manner to remove or expose the password. Other types of special files, such as encryption or steganography, may require a more dedicated effort to bypass the security mechanisms.

Recover Pertinent Deleted Files

Recovering pertinent deleted files would logically include a capability to identify and search all file slack. This would also include identifying and searching all free (unallocated) space, identifying relevant file headers in free space, identifying deleted directories in free space, including directory entries for deleted files, and recovering deleted directory entries as well as all pertinent deleted files that are not overwritten

Make Forensically Sound Images

Once the preview process has identified that certain systems or media contain information relevant to the issues at hand, an investigator must have tools capable of making forensically sound images of those systems or media. The criteria for “forensically sound” media images is fairly straightforward: The image must include a true, validated copy of every bit of every byte contained on the media, without regard to media contents, from the absolute beginning of the media to the end of the physical device.

The exact mechanism by which that data is retrieved from the “evidence” media, stored in an image file, and validated will vary. But the image file must contain validated copies of all data from the original media. In today’s world of smartcards and “computer memory cards,” where cameras can store hundreds of pictures on memory cards (where these cards can supply memory to portable or handheld devices), the investigators are faced with an ever-widening variety of media. Today’s media is outdated tomorrow. New imaging and analysis tools must keep apace.

Restore Forensic Images to Suitable Media

Where the functionality of an application is the issue, merely analyzing the files comprising the application at a physical or logical level may not be enough to satisfy the questions. This requirement stems from a need to be able to run applications installed on drives that have been preserved as evidence. For instance, in a fraud investigation, if an investigator needs to print reports from a large financial application installed on a drive, that she or he has imaged, and she or he no longer has access to the original drives, she or he may need to restore the image to run the application to print the reports. Today’s large applications rely on installation processes that do more than just copy the application files to the media. So, running the application in its installed environment may be necessary. This cannot currently be done from within the image files, so the image must be restored.

Perform a Sector-by-Sector Comparison

To verify that one piece of media is an identical copy of another, investigators typically use media hashes of some type. But where two pieces of media are thought to be identical copies of each other, but hash differently, it must be possible to compare sector-by-sector. In most cases, simply knowing that two pieces of media have different hashes will not give you an indication of where on the media the difference occurs. And this capability would be especially useful when an investigator must restore an image of a piece of media to a dissimilar piece of media. This tool could verify that any differences between the original and the copy are merely sectors filled with hashes and are accounted for by geometry differences only.

Thoroughly Document Investigative Activities

Thoroughly documenting investigative activities would preferably be an automated part of the forensic analysis software. If the software is self-documenting and certain reports are automatically generated for the user, based on the results of exercising the capabilities of the software, this could help make reporting results much simpler.

Now that we’ve looked at computer forensics requirements definitions, let’s look at digital evidence standards and principles. This next part of the chapter recommends the establishment of computer forensics standards for the exchange of digital evidence between sovereign nations and is intended to elicit constructive discussion regarding digital evidence.

Standards and Principles of Digital Evidence

The latter part of the 20^th century was marked by the electronic transistor and the machines and ideas made possible by it. As a result, the world changed from analog to digital. Although the computer reigns supreme in the digital domain, it is not the only digital device. An entire constellation of audio, video, communications, and photographic devices are becoming so closely associated with the computer as to have converged with it.

From a law enforcement perspective, more of the information that serves as currency in the judicial process is being stored, transmitted, or processed in digital form. The connectivity resulting from a single world economy in which the companies providing goods and services are truly international has enabled criminals to act transjurisdictionally with ease. Consequently, a perpetrator may be brought to justice in one jurisdiction while the digital evidence required to successfully prosecute the case may reside only in other jurisdictions.

This situation requires that all nations have the ability to collect and preserve digital evidence for their own needs as well as for the potential needs of other sovereigns. Each jurisdiction has its own system of government and administration of justice, but in order for one country to protect itself and its citizens, it must be able to make use of evidence collected by other nations.

Although it is not reasonable to expect all nations to know about and abide by the precise laws and rules of other countries, a means that will allow the exchange of evidence must be found. This part of the chapter defines the technical aspects of these exchanges.

Standards

To ensure that digital evidence is collected, preserved, examined, or transferred in a manner that safeguards the accuracy and reliability of the evidence, law enforcement and forensic organizations must establish and maintain an effective quality system. Standard Operating Procedures (SOPs) are documented quality-control guidelines that must be supported by proper case records and use broadly accepted procedures, equipment, and materials.

Standards and Criteria

All agencies and/or organizations that seize and/or examine digital evidence must maintain an appropriate SOP document. All elements of an organization’s policies and procedures concerning digital evidence must be clearly set forth in this SOP document, which must be issued under the agency’s management authority.

The use of SOPs is fundamental to both law enforcement and forensic science. Guidelines that are consistent with scientific and legal principles are essential to the acceptance of results and conclusions by courts and other agencies. The development and implementation of these SOPs must be under an organization’s management authority.

Management must review the SOPs on an annual basis to ensure their continued suitability and effectiveness. Rapid technological changes are the hallmark of digital evidence, with the types, formats, and methods for seizing and examining digital evidence changing quickly. To ensure that personnel, training, equipment, and procedures continue to be appropriate and effective, management must review and update SOP documents annually.

Procedures used must be generally accepted in the field or supported by data gathered and recorded in a scientific manner. Because a variety of scientific procedures may validly be applied to a given problem, standards and criteria for assessing procedures need to remain flexible. The validity of a procedure may be established by demonstrating the accuracy and reliability of specific techniques. In the digital evidence area, peer review of SOPs by other organizations may be useful.

The organization must maintain written copies of appropriate technical procedures. Procedures should set forth their purpose and appropriate application. Required elements such as hardware and software must be listed and the proper steps for successful use should be listed or discussed. Any limitations in the use of the procedure or the use or interpretation of the results should be established. Personnel who use these procedures must be familiar with them and have them available for reference.

The organization must use hardware and software that is appropriate and effective for the seizure or examination procedure. Although many acceptable procedures may be used to perform a task, considerable variation among cases requires that personnel have the flexibility to exercise judgment in selecting a method appropriate to the problem.

Hardware used in the seizure and/or examination of digital evidence should be in good operating condition and be tested to ensure that it operates correctly. Software must be tested to ensure that it produces reliable results for use in seizure and/or examination purposes.

All activity relating to the seizure, storage, examination, or transfer of digital evidence must be recorded in writing and be available for review and testimony. In general, documentation to support conclusions must be such that, in the absence of the originator, another competent person could evaluate what was done, interpret the data, and arrive at the same conclusions as the originator.

The requirement for evidence reliability necessitates a chain of custody for all items of evidence. Chain-of-custody documentation must be maintained for all digital evidence.

Case notes and records of observations must be of a permanent nature. Handwritten notes and observations must be in ink, not pencil, although pencil (including color) may be appropriate for diagrams or making tracings. Any corrections to notes must be made by an initialed, single strikeout; nothing in the handwritten information should be obliterated or erased. Notes and records should be authenticated by handwritten signatures, initials, digital signatures, or other marking systems.

Any action that has the potential to alter, damage, or destroy any aspect of original evidence must be performed by qualified persons in a forensically sound manner. As discussed in the preceding standards and criteria, evidence has value only if it can be shown to be accurate, reliable, and controlled. A quality forensic program consists of properly trained personnel and appropriate equipment, software, and procedures to collectively ensure these attributes.

Finally, now that the establishment of computer forensics standards has been made, it is time to recommend some auditing techniques. The following auditing techniques are based on how to audit your internal computer forensics and Internet security policies.

Computer Forensics Auditing Techniques

Companies that believe their networks and the Internet can be completely protected by a phalanx of add-on computer forensics and security products may be in for a rude awakening. Underlying vulnerabilities, embedded and unseen many layers down in network infrastructures and the Internet, may be unwitting invitations to even moderately skilled attackers.

Computer forensics and security-auditing companies can give a company expert analysis of obscure but potentially devastating loopholes, along with estimates of cost versus risk for each of many possible approaches to address them—and a basis for deciding whether spending a little more money up front will save much more in the long run. So, without further ado, this last part of the chapter makes some recommendations into how computer forensic and security auditors go through a network and what steps are necessary for companies to lock down their networks—especially the ones that are connected to the Internet.

How to Audit Your Network and Internet Security Policies with Computer Forensics Techniques

The Internet has allowed businesses to communicate in new and strategic ways with various types of people and organizations. Thus, system administrators do not have to argue for an Internet connection anymore. Instead, they have to fight for the resources to secure it. Auditing your Internet and network security with computer-forensics techniques is a responsibility that should be frequently revisited and improved, and you should not hesitate in dedicating resources to security when you find shortcomings.

The Internet Octopus

Over the years, you have added feature upon feature to your Internet and network connections. As the needs have changed, you have found yourself needing more robust services, faster connections, and more flexibility in what can be done. In the beginning, services such as simple POP3-style e-mail and Web access were the extent of an Internet connection. Today, you have site-to-site VPNs; client-side and home-user VPNs; streaming media; Web-based training; company Web sites; Internet applications; e-commerce;^[vi] and business-to-business extranets. During all these changes in the last few years, you have probably changed IT personnel, Internet platforms, and network connections at least once in your organizations. This scenario makes it easy to have some unforeseen, yet preventable, exposures.

Any network connection to the Internet is vulnerable to exploitation. The most basic vulnerability that all network connections face is that they could be made unavailable and bring down mission-critical services with them. Today, you are finding more intelligent defenses against attacks, such as denial of service attacks (see sidebar, “How DoS Attacks Work”), as routers and other devices can be set to verify source addresses and ignore packets if they are bogus or carry a suspicious pattern. However, beyond the DoS category of vulnerabilities, there are always the standard concerns of open ports, easy passwords, unsecured routers, and unknown “features” that any Internet device may have.

^[vi]John R. Vacca, Electronic Commerce, Third Edition, Charles River Media, 2001.

---