So far, the evidence that has been analyzed has focused on those elements that are obtained from the network traffic or the system’s memory. Even though an incident’s root cause may be ferreted out from these evidence sources, it is important to understand how to obtain evidentiary material from a system’s storage, whether that is removable storage such as USB devices or the larger connected disk drives. These containers carry a massive amount of data that may be leveraged by incident response analysts to determine a root cause. It should be noted that this chapter will only be able to scratch the surface as entire volumes have been devoted to the depth of forensic evidence that’s available.
To provide a better understanding of analyzing system storage, this chapter will focus on the following topics:
System storage analysis is a complex process. The depth and breadth of it cannot be explored in a single chapter; due to this, we hope that this chapter provides some concrete areas of focus with the understanding that responders will gain a better sense of some of the tools that can be employed, as well as an understanding of some of the critical data that can be leveraged.
Over the past 15 years, there has been an increase in the power of disk forensics platforms. For the incident response analyst, there are options as to what type of platform can be leveraged to examine disk drives. Often, the limiting factor in utilizing these platforms is the cost of more robust systems, when a lower-cost alternative will be just as effective for an incident response team.
Several factors should be addressed when examining software for disk analysis. First, has the platform been tested? Several organizations test platforms for efficacy, such as the National Institute of Standards and Technology Computer Forensic Tools Testing Program (https://www.cftt.nist.gov/). Second, the tool’s use in criminal and civil proceedings must be examined. There is no single court-accepted standard, but tools should conform to the rules of evidence. The use of a platform that has not been tested or does not conform to the rules of evidence may lead to the evidence being excluded from legal proceedings. In other, more disastrous consequences, it may lead to an analyst arriving at the wrong conclusion.
Forensically sound tools
An example of an untested and forensically unsound toolset that was used in a criminal proceeding was in the case of The State of Connecticut versus Amero. In this case, a law enforcement agency utilized unsound forensic methods and tools to convict a woman for allegedly allowing children to see sexually explicit pop-up ads. A subsequent review of the methods and facts of this case indicated that there were significant deficiencies with the forensic examination. An excellent examination of this case is also available from the Journal of Digital Forensics, Security, and Law at https://commons.erau.edu/jdfsl/vol7/iss2/5/.
One final consideration is how the tool fits into the overall incident response planning. For example, commercial disk forensics tools are excellent at locating images and web artifacts. They are also excellent at carving out data from a suspect's drive. This is often because forensic software is utilized by law enforcement agencies as a tool to investigate child exploitation crimes. As a result, this capability is paramount to bringing a criminal case against such suspects. While these are excellent capabilities to have, incident responders may be more interested in tools that can be utilized for keyword searches and timeline analysis so that they can reconstruct a series of events before, during, and after an incident.
While most commercial and free forensic platforms have a variety of features, several common ones can be of use to incident response personnel:
In terms of commercial options, the following three platforms are generally accepted as sound and are in use by commercial and government entities all over the world. Each uses the features we described previously, among other, more specialized, tools:
Each of these platforms has a rich feature set and provides responders with a powerful tool for conducting a wide range of forensic tasks. The specific tools in each of these platforms are outside the scope of this book. As such, it is recommended that responders are trained on how to use these platforms to ensure that they fully understand these tools’ capabilities.
One alternative to commercial forensics programs is Autopsy. Autopsy is a GUI-based forensic platform based on the open source The Sleuth Kit toolset. This open source platform provides features that are commonly found in commercial platforms. This includes timeline analysis, keyword searching, web and email artifacts, and the ability to filter results on known bad file hashes. One of its key features is its ease of use. This allows incident responders to have a light platform that focuses on critical tasks and obtain the critical evidence that’s needed.
Several of the Linux distributions we discussed previously have Autopsy preinstalled. It is good practice for responders to ensure that the platform they are using is up to date. For the Windows operating system, download the Microsoft self-installer file located at https://www.sleuthkit.org/autopsy/download.php. Once downloaded, execute the MSI file and choose an install location. Once you’ve done this, the application will be ready to use.
Once Autopsy has been installed, the analyst can open a case with very little pre-configuration. The following steps will discuss the process of opening a new case:
Figure 11.1 – E01 files
In the preceding screenshot, an image file has been taken from a suspect system. The image has been divided into two separate files. Looking back to Chapter 8, imaging applications such as FTK Imager will divide an image into multiple files. So long as the separate files are in the same directory, Autopsy will be able to take the two files and reconstruct the entire volume that has been imaged.
Sample image file
For our examination of Autopsy, a sample image file taken from a Windows 10 system can be found at https://cfreds.nist.gov/all/MagnetForensics/2022WindowsMagnetCTF. For more practice, additional testing images can be downloaded from the Computer Forensic Reference Data Sets located at https://www.cfreds.nist.gov/.
Figure 11.2 – Autopsy – creating a new case
Figure 11.3 – Autopsy – New Case Information
Figure 11.4 – New Case Information – Optional Information
One way to think of the case is as a container for all the related case data and evidence related to an incident. Autopsy allows the analyst to add multiple data sources such as disk images and virtual machine disks as well. At this stage, we will load the E01 file as a data source:
Figure 11.5 – Add Data Source – Select Host
Autopsy can automatically detect the hostname. If the analyst knows the hostname, it can be added in the Specific new host name field. From a best practices perspective, if known, the host’s name should always be entered. Once complete, click Next.
Figure 11.6 – Add Data Source – Select Data Source Type
Figure 11.7 – Selecting the E01 file
One other option is to process unallocated space (this is important!). This captures all the information in the space that’s not currently allocated to data on the hard drive. There are methods where unallocated space can be utilized to hide information. Once done, click Next:
Figure 11.8 – Add Data Source – Configure Ingest
This will start the processing procedure:
Figure 11.9 – Data source processing
Figure 11.10 – Data source complete
Autopsy will now go through the process of analyzing the files from the image. Depending on the size of the image, this will take between several minutes and a couple of hours. The process bar in the lower-right corner of the screen will show its progress. How long this process takes is often dependent on the processing speed of the computer, as well as the size of the image file(s). At this point, Autopsy will start to populate the specific fields in the left-hand pane, even though additional processing is taking place. The lower right-hand corner of the GUI will show the progress of the processing:
Figure 11.11 – Evidence source processing
As was stated earlier, processing may take some time, depending on the forensic system’s specifications and the size of the file. Analysts can conduct some analysis with the understanding that not all data may be available.
The Autopsy GUI is divided into three main sections. These sections display details relating to the system and specific files. When Autopsy has finished processing a new case or opening an existing case, the analyst will see the following window:
Figure 11.12 – Autopsy GUI
As shown in the previous screenshot, Autopsy is divided into three main panes. The first of these is the left-hand pane, which contains the data sources and file structure, as well as search results. Clicking on the plus (+) sign expands the results while clicking on the minus (-) sign collapses them. This allows the analyst to access the system at a high level, and also drill down to specific elements. The center pane contains directory listings or results from searches. For example, the following screenshot shows the Program Files directory that was located on the system:
Figure 11.13 – Autopsy’s center pane
Finally, the bottom pane contains the metadata and other information about individual files contained in the center pane. In this example, the desktop.ini file has been selected. Clicking on the File Metadata tab displays information specific to that file:
Figure 11.14 – File metadata
Finally, the file’s hexadecimal content can be viewed by clicking on the Hex tab:
Figure 11.15 – Hex view
This view is excellent if an analyst wants to inspect an application or another file that is suspected of being malware.
What Autopsy offers is the ability to perform some of the actions and analyses that can be found on other commercial platforms. However, it should be noted that in the case of more complex investigations, it may become necessary to utilize more sophisticated platforms. Autopsy also provides responders that are new to disk forensics with a more user-friendly platform so that they can gain experience with one before they move on to a more sophisticated commercial solution.
Once the case has been processed, the left-hand pane will be populated with the number of artifacts located in the system:
Figure 11.16 – Autopsy’s artifacts pane
In the previous screenshot, there are several items listed under the Data Artifacts portion. These include looking at programs that have been installed, the operating system’s information, and recent documents. Another key feature of Autopsy is the ability to examine the entire folder structure of the image file. Clicking on the plus (+) sign next to Data Sources expands the entire folder structure. This is useful if, through other sources, an analyst can identify the location of a suspect file:
Figure 11.17 – Data Sources
Different data points can be examined by utilizing Autopsy. What to search for and how to search for it is often dictated by the type of incident or examination under investigation. For example, a malware infection that originates from a compromised website may involve examining the system for URLs that the user may have typed in or otherwise accessed via a browser. Furthermore, the actual file may be located by utilizing information that’s been obtained by examining the system memory, which we covered in the previous chapter. For example, if an analyst was able to locate a suspect process and was subsequently able to also locate the executable, they may utilize Autopsy to find the last time the executable was launched. This can provide responders with a time so that they can examine other systems for evidence of compromise.
In another scenario, responders may be tasked with identifying whether an employee accessed confidential files so that they could pass them on to a competitor. This may involve examining the system for the times and dates when files were accessed, email addresses that may have been used, external cloud storage sites that were accessed, or USB storage that was connected to the system. Finally, a full list of these files may provide insight into the confidential documents that were moved.
There are several types of incidents where it may be necessary to examine a system for evidence of malicious activity that’s been conducted by a user. Previously, we mentioned accessing cloud-based storage where a malicious insider had uploaded confidential documents. In other circumstances, social engineering attacks may have an unsuspecting employee navigate to a compromised website that subsequently downloads malicious software. In either case, Autopsy provides us with the ability to examine several areas of web artifacts.
The first of these web artifacts is web history. In the event of a social engineering attack that involves a user navigating to a malware delivery site, this data may provide some insight into the specific URL that was navigated to. This URL can then be extracted and compared with known malicious website lists from internal or external sources. In other cases, where an insider has accessed an external cloud storage site, the web history may provide evidence of this activity. Let’s take a look at this case in detail:
Figure 11.18 – Web History
Figure 11.19 – Web history metadata
Figure 11.20 – Web Downloads
Figure 11.21 – Web download metadata
As the preceding screenshot shows, there are some more details concerning the downloaded file. For example, the analyst can gather time information, file location, and an MD5 hash, which can be utilized to compare any extracted files that are examined further. In some circumstances, a suspect may decide to delete the browsing history from the system to hide any malicious activity. Another location that may provide evidence of sites that have been accessed by a malicious insider is web cookies. These can be accessed in the left-hand pane under Web Cookies. Clicking on this produces a list of the cookies that are still on the system:
Figure 11.22 – Web Cookies
Depending on the type of incident, web artifacts can play an important role. Autopsy has some functionality for this, but responders may find that other commercial solutions provide a much more robust platform. Evidence Finder by Magnet Forensics (www.magnetforensics.com) scours the entire system for internet artifacts and then presents them in a way that is easy for the analyst to view. Another key advantage of commercial solutions such as this is that their functionality is updated continuously. Depending on the frequency of internet and web artifact searching, the inclusion of tools such as this may be beneficial.
Locating suspect emails continues to be a task that incident responders often engage in. This can include externally caused incidents such as social engineering, where responders may be tasked with locating a suspect email that had malware attached to it. In other circumstances, malicious insiders may have sent or received communication that was inappropriate or violated company policy. In those cases, responders may be tasked with recovering those emails so that they can be included in termination proceedings or legal action.
Autopsy can locate emails contained in the system. From these emails, they may be able to identify one or more suspicious emails and domains that can be further researched to see if they are associated with social engineering or other malicious activity. Simply click on Keyword Hits and then the Email Addresses tab in the left-hand pane. From there, the analyst can see the email addresses that are located on the system:
Figure 11.23 – Email addresses
Next, let’s look at attached devices.
Another key piece of evidence that may be useful to an analyst is data about when specific devices were attached to the system. In the scenario of a malicious insider attempting to steal confidential documents, knowing whether they utilized a USB device would be helpful. Autopsy utilizes the registry settings located on the system to identify the types of devices attached and the last time that they were used. In this case, the output of clicking Devices Attached in the left-hand pane produces the following results:
Figure 11.24 – USB devices
Drilling down into the Data Artifacts tab, the analyst can identify the type of device and the date and time that the USB device was attached:
Figure 11.25 – USB device artifacts
Finally, a more detailed examination of the Source File Metadata area would show additional data that can be utilized to reconstruct the time that the USB device was accessed on the system:
Figure 11.26 – Device entry metadata
Next, let’s look at deleted files.
Files that have been deleted can also be reconstructed, either partially or completely. The Windows operating system will not delete files when the user selects deletion. The operating system will mark the space a deleted file takes up in the Master File Table (MTF) as available to write new files to. As a result, responders may be able to view deleted files that have not been overwritten.
Solid-state drives
As discussed in Chapter 8, keep in mind the challenge that forensic analysts have when examining solid-state drives (SSDs). Deleted files can often be recovered from traditional platter hard drives, even after a system is powered down. With SSDs, the operating system will often remove deleted files to make storing files more efficient. The following website has an excellent breakdown of this if you want to find out more: https://www.datanarro.com/the-impact-of-ssds-on-digital- forensics/.
To view the deleted files on a system, click on Deleted Files in the left-hand pane. From here, the analyst can see all of the files that have been marked for deletion:
Figure 11.27 – Deleted files
From here, the analyst can search through deleted files. These files may hold evidentiary value. For example, in the case of malicious insider activity, if several sensitive files are found in the deleted files, all of which have been deleted within the same time, it may be indicative of the insider attempting to cover their tracks by deleting suspicious files.
One key advantage that forensic applications have is the ability to perform keyword searches. This is especially advantageous as disk drives have gotten larger and responders would have to parse through an overwhelming quantity of data. Keywords are often derived from other elements of the investigation or by using external sources. For example, if an analyst is investigating a malware incident, they may use a suspicious DLL or executable name from the analysis of the memory image. In other instances, such as a malicious insider being suspected of accessing confidential information, keywords in those documents, either secret or confidential, can be used to see if the suspect used the system to access those files.
Autopsy can perform keyword searches while utilizing an exact or a substring match. For example, let’s say an analyst has been tasked with determining what evidence can be located concerning the ZeroTier One executable, which had been located in the Web Downloads entries. The analyst is tasked with locating any trace evidence that would indicate that the file was executed and if possible, identify the user.
The analyst would navigate to the top-right corner and input ZeroTier One in the field. In this case, an exact match will be utilized. Once selected, they would click the Search button. The left-hand pane will indicate whether there were any hits on that text. In this case, the pricing decision has 82 hits:
Figure 11.28 – Keyword search hits
As shown in the preceding screenshot, the center pane will contain a list of the files that contained the hits. One file that stands out is the Master File Table entry. This entry shows the dates and times the file was first placed on the system, along with any modifications and changes:
Figure 11.29 – Master File Table entry
Further review shows a Windows PowerShell event log entry, which shows that the application was executed by the user account Patrick based on the file path:
Figure 11.30 – Keyword search results
Digging further into the hits, there is an entry within the Windows PowerShell Operational event logs indicating that the executable was associated with a network connection established via a PowerShell script:
Figure 11.31 – Keyword PowerShell script
Further down within the entry is a Base64-encoded PowerShell script entry:
Figure 11.32 – Base64 PowerShell script
Taken together, this may point to some suspicious activity. For example, ZeroTier One is a commercial VPN solution, so it is not out of the ordinary for it to be establishing a connection. What is suspicious is the Base64-encoded PowerShell script, which is often used by adversaries to download additional malware or perform malicious actions. We will look at some of these scripts later in Chapter 16.
Next, we will look at how Autopsy can build a timeline of the system’s activity.
When investigating an incident, it is critical to have an idea of when applications or files were executed. Timestamps can sometimes be found in other aspects of the investigation, such as when examining memory images. Also, identifying specific DLL files or executable files in the memory image can be compared to the date and time they were accessed to correlate other activity that’s been observed on the system.
Time normalization
One aspect of digital forensics that bears repeating is to ensure that all the systems are using the same time zone. With network systems, this is usually accomplished with the Network Time Protocol (NTP). There are times when systems do not have normalized time through NTP. Responders should take great care in understanding what time zone and synchronization should be used. The best practice regarding time is to set all the systems to UTC. This is critical if an organization is geographically diverse.
Autopsy has functionality specifically for timeline analysis. Simply clicking on the Timeline button at the top of the window will make Autopsy begin the process of parsing out timeline data. Depending on the size of the image file being analyzed, it may take a few minutes. Once completed, the following window will open:
Figure 11.33 – Timeline viewer
From here, the analyst can utilize several features. First is the text filter on the left-hand side of the screen. Using this, the analyst can search for specific text in files. For example, the analyst has already identified that the executable named ZeroTier One had been executed on the system under investigation. If the analyst would like to know whether that file was accessed at any other times, they could enter pricing into the Text Filter box and click Apply, which would produce the following results:
Figure 11.34 – Keyword timeline
From this graph, the analyst can further drill down into the specific times the file was accessed by clicking on the colored bars. The responders can now see that the executable was only accessed at one particular date and time from this system.
Next, we will look at extracting specific evidence items from a disk image and processing them with additional tools.
Another technique that can be leveraged for timeline analysis is utilizing external tools to analyze the MFT. Autopsy allows the analyst to export the MFT for analysis using third-party tools. In this case, we will use MFT Explorer, one of several tools developed by Eric Zimmerman.
Eric Zimmerman's tools
Eric Zimmerman is a former FBI agent, SANS course developer, and digital forensics expert. He has created a suite of tools for carving and analyzing data available at https://ericzimmerman.github.io/#!index.md. Additionally, the SANS Institute has created a cheat sheet for the tools available at https://www.sans.org/posters/eric-zimmerman-tools-cheat-sheet/.
In this instance, we will look at processing the MFT from the image that was examined with Autopsy. The MFT can be found within the root directory of the filesystem. Find the $MFT file, right-click it, select Extract Files, and then save the file to an evidence drive. As good practice, change the name to something that reflects the case.
Next, find the MFTECmd.exe executable. The following command processes the MFT and outputs the results to a Comma-Separated Value (CSV) file:
C:UsersforensicsDocumentsimmmermanTools>MFTECmd.exe -f "D:Suspect_$MFT" --csv "D:" --csvf SuspectMFT.csv
The CSV file can now be opened and examined. In this case, the CSV has been opened via Microsoft Excel. This allows for keyword searching and examination of times and dates to identify when a file or files were placed on the system. Going back to the previous keyword search, we can use the filter option within Excel. Under the ParentPath column, the ZeroTier keyword has been entered:
Figure 11.35 – ZeroTier filter MFT results
The MFT can be difficult to work with in terms of the amount of data. In this case, the MFT has over 410,000 separate entries that may need to be sorted through. It is a good idea to have a starting point such as a date and time or a filename to search for. This allows analysts to work with only those results that are pertinent. Other tools, such as Eric Zimmerman’s Timeline Explorer, can be used to process and extract those data points that are important to the investigation.
Now that we have looked for the presence of the file on the system, we can look at evidence of execution.
One question that analysts will often have to answer is determining if an executable has run. One of the best sources of data to answer this question is Prefetch files. When an application or other executable is run, a file is created and stored within the C:WindowsPrefetch directory. If the program is run in multiple locations, an entry is created for each of these. Another key aspect of Prefetch files is that they are not deleted when the application or program has been deleted. So, if an adversary is attempting to clean up the system of malicious executables or DLL files, proof of their execution may still be located in the Prefetch directory.
The Prefetch files do have some quirks that should be understood. First, even unsuccessful program execution can still produce a Prefetch file. It should be noted that the operative word is can, meaning that not every unsuccessful execution creates a file. Second, the Prefetch directory is specifically limited to 1,024 separate files. Older files are overwritten in favor of new files. On most end user systems, this generally does not present an issue if analysts can capture the evidence promptly. Third, a program that has been previously executed can still create a new Prefetch file. Finally, there is a time lag with Prefetch files. In general, the creation of the file itself might be 10 seconds off other time stamps an analyst may find.
Acquiring the Prefetch directory is straightforward. Triage tools, like those that were discussed in Chapter 6, can collect the directory. The directory can also be extracted directly through Autopsy. Simply navigate to the Prefetch directory and right-click and select Extract Files. Select the directory to output the files to. It is good practice to place the output in an evidence drive or use Autopsy’s default export directory. Once extracted, the Prefetch entries will look as follows:
Figure 11.36 – Prefetch file entries
This output directory can then be processed with the Prefetch parser with the following command:
C:UsersforensicsDocumentsimmmermanTools>PECmd.exe -d D:Suspect_Prefetch -q --csv D: --csvf suspect_prefetch.csv
The previous command outputs two files. The first is a CSV that contains the Prefetch entries. The second contains a timeline breakdown. Let’s look at the timeline version. The CSV file’s output allows for the same type of searching and filtering that was used in the previous section, Master File Table analysis. In this case, again, we will use ZeroTier for filtering. In this case, the search reveals several entries showing the execution of the ZEROTIER_DESKTOP_UI.EXE executable:
Figure 11.37 – ZeroTier Prefetch entries
There is a great deal of activity that occurs under the hood of the Windows operating system. One place where this activity occurs and is documented is in the Windows Registry. The Windows Registry is a database that stores the low-level system settings for the Windows operating system. This includes settings for devices, security, services, and the storage of user account security settings in the Security Accounts Manager (SAM).
The registry is made up of two elements. The first is the key. The key is a container that holds the second element – the values. These values hold specific settings information. The highest-level key is called the root key and the Windows operating system has five root keys, all of which are stored on the disk in the registry hives. These registry hives are located in the %SystemRoot%system32config folder on the Windows file structure:
Of the five root keys, the most valuable during an incident investigation is the HKEY_LOCAL_MACHINE or HKLM key. This key contains the following subkeys (these are the ones that are the most interesting during an investigation):
Another source of data that can be critical to an incident investigation is the HKEY_CURRENT_USER key. Attackers may make changes to a user account or profile as part of a privilege escalation attack. Changes that have been made to the user’s data are recorded in that user’s NTUSER.dat file. An NTUSER.dat file is created for every user account on the system and is located at C:Users*UserName*. This file contains the user’s profile settings and may provide additional data on the systems that are connected, network connections, or other settings. Data contained within the HKEY_CURRENT_USER key may be of benefit in some incidents where user activity or user account modification of the system is suspected.
Responders can access the various registry hives using Autopsy. Simply navigate to the Windows/System32/config folder from the file structure in the left-hand pane:
Figure 11.38 – Registry location
The SAM registry file is located in the center pane:
Figure 11.39 – SAM location
The actual examination and evidentiary value of registry key settings are, like many aspects of digital forensics, very detailed. While it is impossible to cover all of the aspects of registry forensics in this chapter, or even in this book, it is important for responders to be able to acquire the registry keys for evaluation, and also to have some familiarity with tools that can allow responders to gain some hands-on experience with evaluating registry settings.
In this case, the system, SAM, security, and software registry keys will be acquired for analysis. For this, the analyst can use Autopsy to acquire the proper keys and then examine them with a third-party tool. Let’s take a look at how to do this:
Figure 11.40 – Suspect registry
The Windows operating system records and maintains artifacts of when USB devices such as mass storage, iOS devices, digital cameras, and other USB devices are connected. This is due to the Plug and Play (PnP) manager, which is part of the Windows operating system. The PnP receives a notification that a USB has been connected and queries the device for information so that it can load the proper device driver. Upon completion, the Windows operating system will make an entry for the device within the registry settings.
To determine what USB devices were connected, follow these steps:
Once loaded, the following window will appear:
Figure 11.41 – Registry Explorer view
Figure 11.42 – USB registry key location
Figure 11.43 – Registry values
From here, the analyst has a lot of information they need to review. Of particular importance is the hardware ID. Clicking on that section of the output produces the following in the lower-right window:
Figure 11.44 – HardwareID data
As we mentioned previously, registry analysis is a deep subset of digital forensics in and of itself. Whole volumes have been written on the evidentiary value present in the settings and entries in registry hives. At a minimum, responders should be prepared to acquire this evidence for others for further examination. That being said, as responders gain more and more experience and skill, the registry should be an area that can be leveraged for evidence when examining a disk image.
In many ways, this chapter just scratches the surface of what information can be found by leveraging disk forensic tools. Exploring a disk image using Autopsy demonstrated some of the features that are available to responders. From here, extracting other data stores such as the Windows Registry and MFT were explored to provide responders with an idea of what data is available during an incident analysis.
Specific tools and techniques are largely dependent on the tool that’s utilized. What’s important to understand is that modern operating systems leave traces of their activity all over the disk, from file change evidence in the MFT to registry key settings when new user accounts are added. Incident responders should have expertise in understanding how modern operating systems store data and how to leverage commercial or freeware tools to find this data. Taken in concert with other pieces of evidence that are obtained from network sources and in memory, disk evidence may provide more clarity on an incident and aid in determining its root cause. One area of focus when it comes to system storage analysis is extracting and examining log files. Log files are critical data points that provide responders with a great deal of information.
The next chapter will carry on from the work that was done here and address how log files can be utilized in an incident investigation.
Answer the following questions to test your knowledge of this chapter:
For more information about the topics covered in this chapter, refer to the following resources: