Section 9.3 Post-Incident Activities

As you study this section, answer the following questions:

• What is the purpose of a lessons learned meeting?
• Why is the chain of custody so important?
• What is the goal of a root cause analysis?

In this section, you will learn to:

• Utilize digital forensics and indicator analysis techniques

The key terms for this section include:

Key Terms and Definitions

Key Terms and Definitions

Term	Definition
Lessons learned meeting	A meeting where staff reviews the incident and responses.
Chain of custody	The record of evidence handling from collection through presentation in court.
Root cause analysis	An investigative technique used to identify the underlying cause of a problem.
Mean time to detect	A metric that measures the average time between the initial appearance of a security incident and its detection.
Mean time to respond	A metric that measures the average time it takes to respond to an incident.
Mean time to remediate	A metric used to measure how quickly an organization can resolve an incident.
Business continuity	Covers the range of activities from the development of a business continuity plan through the creation of response plans, evaluation activities, and plan maintenance.
Disaster recovery	A component of an overall business continuity plan that focuses on the immediate needs of a disaster when things are most frantic and pressing.

This section helps you prepare for the following certification exam objectives:

Exam	Objective
CompTIA CySA+ CS0-003	1.1 Explain the importance of system and network architecture concepts in security operations Infrastructure concepts Virtualization 1.3 Given a scenario, use appropriate tools or techniques to determine malicious activity Common techniques File analysis Hashing 2.1 Given a scenario, implement vulnerability scanning methods and concepts Critical infrastructure Supervisory control and data acquisition (SCADA) 3.2 Given a scenario, analyze output from vulnerability assessment tools Detection and analysis Chain of custody Legal hold 3.3 Explain the preparation and post-incident activity phases of the incident management life cycle Preparation Business continuity (BC)/disaster recovery (DR) Post-incident activity Forensic analysis 4.2 Explain the importance of incident response reporting and communication Incident response reporting Executive summary Recommendations Evidence Root cause analysis Lessons learned Metrics and KPIs Mean time to detect Mean time to respond Mean time to remediate
TestOut CyberDefense Pro	2.2 Detect threats using analytics and intelligence Perform digital forensics investigations 4.2 Manage devices Implement data loss prevention

9.3.1 Post-Incident Activities

Click one of the buttons to take you to that part of the video.

Post-Incident Activities 00:00-00:16 Post-incident activities provide an opportunity to learn from experiences. The feedback gathered in this phase of your incident response plan can help you improve existing security policies and procedures.

Lessons Learned Meeting 00:16-01:18 A good way to gather this information is to hold a meeting to discuss the incident and the incident response. These meetings could be scheduled on a regular basis to discuss small, regularly occurring incidents, or they could be scheduled as the result of a larger, more impactful incident. During this meeting, you should strive to find the who, what, where, when, why and how of the incident.

Who was the attacker? Who detected the incident? Is there anything that could have been done to prevent the attack? What would have improved the response? Are there policies or procedures that would have helped make the response run more quickly or smoothly?

Where did the incident occur? When did it occur, and when was it detected? Why did the incident take place? What was the motivation for the attack? How long did it take to contain, eradicate, and recover from the incident?

While the intent of the meeting isn't to point fingers, it's important to pinpoint what caused the incident. Doing so can go a long way toward preventing similar events in the future.

Lessons Learned Report 01:18-02:36 After the lessons learned meeting, analysts should create a lessons learned report, or LLR. The LLR should dig a bit deeper into the same questions that were addressed in the lessons learned meeting.

In addition to clarifying what happened and what actions were taken, you want to have some takeaways such as "Would you respond the same way if this incident happened again?" or "Will we make changes to the incident response plan or security policy because of this incident?"

Improvements could include changes to procedures or policies, improvements, or addition to trainings for incident responders. New methods or templates may help improve communication or existing security controls.

Updates generate several things. One is new indicators of compromise. An incident may prompt a response team to adjust their security monitoring or logging services. If they didn't receive enough information to resolve the incident, they may want to increase monitoring. If they had far too much unnecessary information, they may want to limit the scope of the data they collect.

During the incident, the analysts may design new scripts or queries that could be useful in the future. These should be added to a knowledge base or collection of response resources. If new malware signatures were detected, they should be added to the security systems for ongoing monitoring.

Change Control Process 02:36-03:45 Changes that are made in response to a security incident should be implemented using a change control process. This ensures compatibility with existing systems and reduces impact on daily operations.

Change control regulates changes to policies and practices that could impact security. The primary purpose of change control is to prevent unchecked changes that negatively impact security. Change control must be a formal, fully documented process. The change control process steps include identifying the need for a change and submitting it for approval, conducting a feasibility analysis (including technical and budgetary considerations), designing the method that you'll use to implement the change, implementing the change, and then testing it to make sure it conforms to the plan and that the change doesn't adversely affect confidentiality, integrity, or accessibility.

If a change unintentionally diminishes security, an effective change control process includes rollback. A rollback makes it possible to revert the system back to the state it was in before the change was put into effect. And lastly, don't forget to document all the changes you have made!

Evidence Retention 03:45-04:17 As you can imagine, preserving and retaining evidence is a critical part of the incident response process. There's no way to know which incident–even a routine one–could end up in court. During each phase of the incident response process, you should collect and back up important evidence. During the post-incident phase, you'll want to collect all this previously gathered evidence and retain it securely in one location for future use. Depending on the nature of the incident, there could be a regulation for how long the evidence should be retained, how it should be gathered, or how it should be stored.

Summary 04:17-04:38 That's it for this lesson. In this video, we discussed post-incident activities, including the lessons learned meeting, the lessons learned report, the incident summary report, and IOC generation. We also discussed the importance of the change control process and evidence retention.

9.3.2 Lessons Learned Facts

Post-incident activities provide an opportunity to learn from experiences. An essential post-incident activity is to review security incidents to determine their cause, whether they were avoidable, and how to avoid them in the future. This analysis is referred to as lessons learned. The feedback gathered in this phase can be used to improve existing security policies and procedures.

This lesson covers the following topics:

• Lessons learned meeting
• Lessons learned report

Lessons Learned Meeting

The lessons learned activity starts with a meeting where staff reviews the incident and responses. These meetings could be scheduled on a regular basis to discuss small, regularly occurring incidents, or they could be scheduled as the result of a larger, more impactful incident. The meeting must include staff directly involved along with incident handlers, who can provide objective, external perspectives. All staff must contribute freely and openly to the discussion, so these meetings must avoid pointing blame and instead focus on improving procedures. Leadership should manage disciplinary concerns related to staff failing to follow established procedures separately.

The lessons learned process should invoke root cause analysis or the effort to determine how the incident was occurred. Root cause analysis takes work. To understand "why" requires asking, "What was the immediate thing that allowed this to happen?" Keep asking the same question with each answer, working backward to the ultimate cause of the incident. Another approach might be to step through the incident timeline to understand when things happened, what was known, what actions were taken and the reasoning for each decision, and what options or controls might have been more beneficial to the response.

The lessons learned meeting must answer some crucial questions, including the following:

Question	Description
Who	Who was the adversary (insider driven, external, or a combination of both)? Who detected the incident?
What	What security controls would have provided better mitigation, improved response, or prevented the attack? What security measures failed or hindered the response?
Where	Where did the incident occur (host systems and network segments affected)?
When	When did the incident occur? When was it detected?
Why	Why did the incident take place? What were the motivation and target assets?
How	How did the incident occur (tactics, techniques, and procedures (TTPs) employed by the adversary)? How was the incident contained? How long did it take to contain, eradicate, and recover from the incident?

Lessons Learned Report

After the meeting, analysts should create a lessons learned report (LLR) or after-action report (AAR). When the report has been reviewed and finalized, it should form the basis for incident summary reporting and recommendations to a wider, non-technical audience. Most of the LLR answers a few simple questions, such as:

• What happened?
• What actions were taken?
• Were the TTPs known and documented in a knowledge base such as ATT&CK, or were they unique?
• Is this the best solution? In other words, is the solution a stop gap measure or something that could be reproduced consistently?
• Are there more capable solutions available?
• How did the teams react to the issue? Could it have been solved more quickly or efficiently?
• If the same incident occurred again, how would the response differ?
• Do the answers to these questions require changes in the security policy or an update to the incident response plan? Is a change control process in place enabling the organization to implement these corrective actions?

The conclusions provided in the LLR may motivate updates to the incident response plan. Improvements could include:

• Procedural changes.
• Policy changes.
• Better training for incident responders.
• New communication methods or templates.
• Changes to security controls.

9.3.3 Legal Process Requirement Facts

Digital devices are so common in the workplace that any incident, possibly including both civil and criminal cases, requires the collection and analysis of digital evidence.

This lesson covers the following topics:

• Evidence preservation and retention
• Chain of custody
• Legal holds
• e-Discovery

Evidence Preservation and Retention

Preserving and retaining evidence is a critical part of the incident response process. Be aware that:

• There is no way to know which incident, even the routine ones, could end up in court.
• During each phase of the process, you should collect and back up important evidence.
• During the post-incident phase, you should consolidate all evidence for the incident and retain it in one location.
• There may be a regulation indicating how long the evidence should be retained, how it should be gathered, and how it should be stored.

The physical devices and media taken from a crime scene should be labeled, bagged, and sealed using tamper-evident bags. Tamper-proof bags (most vendors prefer the term "tamper-evident") cannot be opened and resealed covertly. It is also appropriate to ensure that the bags have antistatic shielding to reduce the possibility of data being damaged or corrupted on the electronic media by electrostatic discharge (ESD). Each piece of evidence should include a chain of custody form.

The evidence should be stored in a secure facility with physical access and environmental controls so that condensation, ESD, fire, and other hazards do not damage the electronic evidence. Similarly, transport methods must also be secure if the evidence is moved.

Data validation techniques, such as mass storage devices, are essential for digital evidence. Hashing is used to validate data integrity. For example, forensic analysts will generate the hash value of a disk drive before performing any analysis. The hash is extremely important because it allows a forensic analyst to make copies of evidence and prove the copies are exact. By comparing the hash values of the original evidence to the forensic copy, the analyst can confirm they are identical (so long as the values are the same). By regenerating the hash periodically, a forensic examiner can prove that evidence has not been modified during analysis.

Chain of Custody

The chain of custody is the record of evidence handling from collection through presentation in court. The evidence can be hardware components, electronic data, or telephone systems. The chain of custody documentation reinforces the integrity and proper custody of evidence from collection, analysis, storage, and presentation. The chain of custody form should include where, when, and who collected the evidence, who subsequently handled it, and where it was stored. When security breaches go to trial, the chain of custody protects an organization against accusations that evidence has either been tampered with or is different from when it was collected. Every person in the chain who handles evidence must log the methods and tools they use.

Criminal cases or internal security audits can take months or years to resolve. You must preserve all the gathered evidence in a proper manner for a lengthy period. Computer hardware is prone to wear and tear, and important storage media like hard disks can even fail when used normally or when not used at all. A failure of this kind may mean the corruption or loss of your evidence, both of which may have severe repercussions for your investigation. You should also be careful when selecting where to physically store this hardware. Rooms without proper climate controls will increase the risk of hardware failure, especially if these electronics overheat.

Evidence can become overwhelming by its sheer size and scope. Therefore, it is important to create metadata that accurately defines characteristics of digital evidence, such as its type, the date it was collected and hashed, and its purpose. A major incident may generate large quantities of evidence. A consistent naming scheme for labeling archive boxes and evidence bags must be established early in the process. The naming scheme could use a combination of date and time of collection (use a yyyy-mm-dd:hh:mm format rather than leading with day or month), case number, and evidence type.

Lastly, evidence rooms should have proper physical controls such as locks, guards, surveillance cameras, visitor logs, and other access controls. Digital evidence may warrant forensically sound imaging techniques for investigative purposes and as backups, so long as they are protected with the same measures as the original evidence.

Legal Holds

A legal hold, or litigation hold, describes the notification received by an organization's legal team instructing them to preserve electronically stored information (ESI) and paper documents that may be relevant to a pending legal case. Legal hold authority can be complicated by jurisdiction, but these details are managed by legal teams. It is imperative that the cybersecurity team be notified of legal holds as soon as possible in order to ensure data is preserved in accordance with the order. Legal hold requirements often exceed the data protection and retention periods ordinarily in place.

e-Discovery

e-Discovery describes the electronic component of identifying, collecting, and providing the electronically stored information (ESI) identified by a legal hold. The scope of information included in e-Discovery can be vast and include everything from files, emails, logs, text messages, voicemail, databases, and social media activity. The scope of information requested in an e-Discovery request can be difficult for many organizations to comply with. For organizations that are involved in regular legal activities, generally large organizations and government, specific strategies are often employed to defend against e-Discovery requests. Defenses often include well-crafted data retention policies that define stringent periods for which data can be retained. However, data retention policies cannot conflict with existing laws that dictate retention periods.

9.3.4 Incident Summary Report

This lesson covers the following topics:

• Incident summary report
• Root cause analysis
• Measures and metrics

Incident Summary Report

Reports that summarize the incident should be provided to stakeholders. Depending on the target audience, include summaries that answer the following questions.

• What caused the incident, and what security measures have been taken?
• What was the financial, systems, and reputational impact of the incident?
• How have policies and procedures been updated because of the incident?

Root Cause Analysis

Root cause analysis is an investigative technique used to identify the underlying cause of a problem. It is a systematic process used to determine the most fundamental cause of a problem and its consequences. This process is used to identify what went wrong and why and then take corrective action to prevent similar issues from occurring.

One cannot overemphasize the importance of root cause analysis, which is foundational to understanding why an event occurred. On the surface, a computer may be infected with malware, but the root cause is much deeper. Why and how the computer was infected strikes at the center of the problem and may reveal user awareness issues, insufficient content filtering, ineffective patch management, improperly provisioned user accounts, or numerous other issues.

Measures and Metrics

One of the objectives of incident response reporting is to understand if existing people, processes, and tools are sufficient to manage the organization's security program. Security Operations Centers are subject to close scrutiny of their performance and are often evaluated based on the following metrics:

• Mean Time to Detect - A metric that measures the average time between the initial appearance of a security incident and its detection. It is an essential metric in security incident management as it can help organizations understand potential gaps in their response processes.
• Mean Time to Respond - A metric that measures the average time it takes to respond to an incident. It measures the speed and efficiency of response activities related to a detected event. For example, security software tools may detect an event quickly, but staff may not effectively respond to the alerts it generates.
• Mean Time to Remediate - A metric used to measure how quickly an organization can resolve an incident. MTTR is a valuable metric for evaluating an organization’s effectiveness in responding to and resolving incidents.

Mean time to detect may depend upon identifying trends such as alert volume, which describes the total number of specific alerts generated by a logging or monitoring system, such as a SIEM, and indicates the presence of a potentially hazardous condition.

9.3.5 Incident Response Reporting Facts

This lesson covers the following topics:

• Leadership's dependence on IR reporting
• The executive summary
• Recommendations
• Change control process

Leadership's Dependence on IR Reporting

Leadership is responsible for managing and responding to risk in the organization. Managing risk involves many different areas outside of information technology. A comprehensive risk management program includes all risk areas, including IT. This has only sometimes been the case, as many leaders viewed IT as a separate and independent risk area. The organization depends upon IT operations and is impacted significantly by the legal, regulatory, and stakeholder requirements that frame it.

Leadership must demonstrate an effective risk management program. This includes proving that a program is in place to identify and respond to problems on an ongoing basis and that leadership is actively managing the risk program. It is important to remember that leadership has many responsibilities, and leadership teams are pulled in many different directions as they address a wide range of problems. To be effective in this type of role requires accurate and actionable information. Incident response reporting is critical in helping leadership teams manage and respond to risk.

The Executive Summary

The act of decision-making defines leadership teams. A famous quote states that "Inaction is the enemy of progress." The entire organization suffers when leadership teams fail to respond to problems effectively. Leaders must often make decisions swiftly and therefore need useful and accurate data conveyed efficiently.

The executive summary should provide a brief overview of the document, including the purpose, key points, and conclusion. It should include relevant background information to provide context for the rest of the document. It is important to remember to include the main points in the executive summary to ensure that readers can understand the report without having to read the entire document. The executive summary should be clear and concise but still provide enough detail to give readers a good understanding of the report's contents.

An executive summary should be tailored to its audience and written in a way that will be accessible to them. When writing an executive summary, it is crucial to be specific and concise. Keep in mind the length limit of the executive summary, and avoid adding unnecessary detail. An executive summary should be written in a professional tone and should not contain any opinion or bias.

Recommendations

Incident response recommendations include details regarding what to do in response to the incident. Some of the suggestions will be in direct response to containing the immediate damage, but others may focus on longer-term objectives. The recommendations must be specific and actionable, and the decisions made in response must be measured and tracked to demonstrate their successful completion.

Some examples of recommendations may include the following:

• Replace outdated desktops.
• Add additional licensed features to a security product.
• Remove access permissions to specific assets.
• Prohibit the use of personal devices.
• Increase security awareness training frequency.
• Change specific elements of the patch management policy.
• Prohibit access to specific websites.
• Monitor user activity in additional ways.
• Disable specific types of accounts.
• Reset passwords.
• Implement multifactor authentication (MFA).

Lessons learned, and after-action reports are valuable sources of information to identify recommended changes. It could be that the teams responsible for incident response were slow to act, made mistakes, or needed to be more coordinated. Recommendations should address these problems, and leadership teams need to identify ways to measure improvements and provide assurance that changes are incorporated. Response time and mean time to recover are popular measures used to evaluate the effectiveness of incident response teams. When response and recovery times show a downward trend, this generally implies improvements but requires complete analysis.

Change Control Process

Changes made in response to a security incident should be implemented using a change control process. This ensures compatibility with existing systems and reduces the impact on daily operations. Keys points to remember include the following:

• Change control regulates changes to policies and practices that could impact security.
• The primary purpose of change control is to prevent unchecked change that could result in reduced security.
• Change control must be a formal, fully documented process.

The following are the change control process steps:

1. Identify the need for a change and submit it for approval.
2. Conduct a feasibility analysis, including technical and budgetary considerations.
3. Design the method for implementing the change.
4. Implement the change.
5. Test the implementation to ensure it conforms to the plan and does not adversely affect confidentiality, integrity, and accessibility.
6. Document the change.
7. Analyze feedback.

An effective change control process includes rollback. A rollback makes it possible to revert the system to the state it was in before the change was put into effect. This is helpful if a change unintentionally reduces security.

9.3.6 Business Continuity and Disaster Recovery Facts

This lesson covers the following business continuity and disaster recovery (BCDR) topics:

• BCDR threshold
• Business continuity
• Disaster recovery

BCDR Threshold

There is a threshold when an incident becomes a disaster. After crossing this boundary, the response becomes more comprehensive and includes many levels of support across the organization. The boundary is not rigid; it is determined by senior leadership and typically based on the scope of impact. For example, a malware infection of one or two desktops may be well managed by incident response processes. The response must be different if the malware infection impacts all desktops because the organization can no longer operate.

Sometimes, something appears to be an incident, such as malware detection on a single desktop. However, the investigation determines that the malware was part of a more extensive campaign and that an attacker had access to protected data. The scope of impact for this incident is much more significant than the malware on the desktop. The investigation has identified a data breach incident, and the business must now respond in full force.

Business Continuity

Business continuity (often referred to as a Continuity of Operations in government and nonprofit organizations) has a broad scope. It covers the range of activities from the development of a business continuity plan through the creation of response plans, evaluation activities, and plan maintenance.

In short, business continuity (BC) describes the efforts the organization takes to keep the organization running during and after a disaster event. It describes how the organization continues operating in the face of significant adversity and the effort needed to work through the event and restore operations to normalcy. Bringing systems back online is part of the objective; returning things to normal takes more time. For example, employees may need to complete or track work using alternative methods during a disaster. At some point, that information will need to be entered into the systems that were unavailable during the disaster. If the organization had to operate out of an alternative facility, all of the people and equipment would need to move back after the event passes. These activities are part of the business continuity plan.

Disaster Recovery

Disaster recovery (DR) is a component of an overall business continuity plan. Business continuity is much broader in scope and covers a more extended time than the disaster recovery plan. Disaster recovery plans focus on the immediate needs of a disaster when things are the most frantic and pressing. The tasks required to bring critical systems back online are the most crucial issue—for example, recovering systems after a wide-scale ransomware infection. Disaster recovery describes the efforts to restore infected systems to a safe operating state. By comparison, business continuity describes the work the organization does to keep running, manage the legal ramification of the event, keep staff employed, work with insurance companies, provide internal and external communications regarding the event and its ramifications, investigate the root cause, develop plans to prevent reoccurrence, and much more.

9.3.7 Digital Forensics Overview

Click one of the buttons to take you to that part of the video.

Digital Forensics Overview 00:00-00:44 Detectives use a variety of tools. They have special lights, fingerprinting kits, and DNA analysis. Digital detectives also have a long list of tools that help them identify digital criminals. In this lesson, I'm going to go over a few of the tools we have available to help us investigate digital crimes.

One tool you have in your arsenal is Endpoint Threat Detection and Response, or ETDR. It monitors endpoint and network events and stores the information in a central database for further analysis. Software monitors the database and finds, flags, and investigates irregularities. These systems help prevent attacks or, at least, mitigate their effects.

Drive Copies 00:44-01:46 In digital forensics, you shouldn't directly examine the original electronic media. Always create a copy to conduct your investigation. The type of copy you're probably most familiar with is a logical copy. This is when you duplicate the known, visible files in a particular amount of memory. For example, if your hard drive has 500 gigabytes of space and your computer files only use 200, a logical copy of the files would only copy the 200 gigabytes of used space.

A forensic copy replicates everything on a hard drive, whether or not the space is allocated. If you did a forensic copy of your 500 gigabyte hard drive, you would copy the full 500 gigabytes, including the 200 gigabytes of allocated space and the 300 gigabytes of unallocated space. Unallocated space can contain deleted files, metadata, timestamps, and other leftover data that provides clues that wouldn't be available in a logical copy. Making these forensic copies does require specific hardware, software, and training.

Memory Dump 01:46-02:45 When a computer crashes, it creates what's called a memory dump. This is a copy of the computer's memory at the time when the crash happened, and you can use it as a forensics tool. By analyzing the memory, you can determine what led up to the crash in the first place. There are a few different types of memory dumps.

A complete memory dump includes absolutely everything that was used in physical memory. This is often too much information to be useful, so a kernel memory dump is usually preferrable. This is only a portion of the memory, and it doesn't include any unallocated memory or memory for user-mode applications. It's often more useful because it's much smaller, and it only leaves out the parts of memory that probably weren't involved in the crash.

There's also a third kind of memory dump called a small memory dump. It only contains the bare bones of what was going on at the time of the crash. This can be useful in figuring out a few things, but it's usually not enough for a complete forensic analysis.

Mobile Devices 02:45-03:40 These days, investigating digital crimes involves getting information off of mobile devices, such as smartphones or any device that has both memory and communication capabilities. These devices are useful because they store personal contact information that identifies the device's owner. As the capabilities of mobile devices increase, more and more pertinent information is available on them. We

can know where the user has been, what they've purchased, whom they've contacted, and which sort of media they've created.

Because these devices have unique capabilities when compared to a regular computer, some different forensic techniques are required. Mobile devices are constantly evolving and coming out with updates, and this makes them more difficult to deal with than a typical computer. While it's possible to track the general area a call came from, this still isn't an exact science that allows investigators to pinpoint a precise location.

Cloud Forensics 03:40-04:22 Forensics in the cloud presents its own set of challenges as well. For example, when a digital crime happens in the cloud, who has jurisdiction over it? The whole point of the cloud is that people from many locations can store data from remote locations, which might be in different cities or even different countries. Cloud applications are also tricky because they change so often. Data can be held all over the place, and so it could prove difficult to even track down the data you need to investigate in the first place. It's also harder for us to assure that digital evidence hasn't been tampered with on the cloud since many different people might have access to the same data. This can make it difficult to collect evidence that actually holds up in court.

Virtualization 04:22-04:50 Next, let's talk about virtualization. Virtualization is running multiple virtual instances of a device on a single piece of physical hardware. It's like your computer's virtual copy. Sometimes, forensic investigators create virtual copies of the environments they're investigating so that they can test their theories without compromising the original environment. Investigators often test their theories in these environments to see how various scenarios would actually play out.

Legal Holds 04:50-05:44 A legal hold is a way to preserve data that might potentially be important to an ongoing legal investigation. It's sometimes known as a litigation hold. Basically, it's a legally binding order that requires the custodians of the data in question to preserve it until the time when it's no longer needed. To do this, the data custodians must be given a legal hold notification in writing. This notice spells out which data needs to be preserved and why.

As soon as a legal hold applies, the data can't be altered in any way from its original form. Altering the data would destroy its usefulness as evidence. The custodians must immediately suspend any activities that would alter the data until the legal hold has been lifted. For example, if a company routinely deletes old records after a certain period of time, they should stop doing so until the legal hold is done.

Summary 05:44-06:32 That's it for this lesson. In this lesson, we talked about the many different forensic tools. As investigators, we can use ETDR to spot irregular events soon after they happen. We also need to make digital copies of drives so that experts can examine them in full. Memory dumps are also useful for analysis, and using virtualization helps us run through scenarios without affecting the original machine.

Mobile and cloud computing digital forensics does present its own unique challenges, but these new technologies are an ever-increasing presence in our modern world. Finally, we learned that a legal hold is an official order that keeps those in charge from altering any data that could be useful in an ongoing investigation.

9.3.8 Digital Forensics Facts

Digital forensics is a science focused on gathering and analyzing digital data in relation to a computer crime or cyber attack. The focus of digital forensics is gathering pertinent evidence and studying it to draw conclusions about how or why something happened.

This lesson covers the following topics:

• Digital forensics process
• Data acquisition
• Mobile forensics
• Cloud forensics
• Virtualization
• Legal holds

Digital Forensics Process

Investigating an incident can be broadly categorized into two main classes: those that support legal proceedings and those that support an organization's internal requirements. Sometimes internal investigations can take a legal turn; for example, an internal investigation may reveal illegal activity, which would likely result in a change of process and scope for the investigation. Investigations involving legal matters should be performed by qualified forensic investigators who understand the legal circumstances and requirements surrounding digital forensics in this type of setting.

Sometimes data acquisition will result in changes to evidence but will still be admissible so long as it occurred under the proper circumstance. For example, performing a forensic investigation on a mobile phone or tablet will require inserting a cable into the device, resulting in a state change on the device.

A forensic investigation includes the following four phases:

1. Identification
   • Ensure that the scene is safe. Threat to life or injury takes precedence over evidence collection.
   • Secure the scene to prevent contamination of evidence. Record the scene using video and identify witnesses to interview.
   • Identify the scope of evidence to be collected.
2. Collection
   • Ensure authorization to collect the evidence.
   • Use tools and methods that will withstand legal scrutiny.
   • Document and prove the integrity of evidence.
   • Store evidence in secure, tamper-evident packaging.
3. Analysis
   • Create a copy of evidence for analysis, ensuring that the copy can be related directly to the primary evidence source. The integrity of evidence copies is verified by generating hashes of the files on a recurring basis in order to detect any unintended changes.
   • Use repeatable methods and tools to analyze the evidence.
   • Analyze evidence using tools known to produce trustworthy and legally defensible results. A list of tested forensic tools is available from NIST at https://www.nist.gov/itl/ssd/software-quality-group/computer-forensics-tool-testing-program-cftt .
4. Reporting/Presentation
   • Create a report of the methods and tools used.
   • Present findings and conclusions in accordance to the specific reporting requirements necessary (and dependent upon the type of incident).

Data Acquisition

Data acquisition describes obtaining a forensically clean copy of data from a device held as evidence. If the organization does not own the computer system or device, there is the question of whether search and seizure is legally valid. This impacts bring-your-own-device (BYOD) policies. For example, accusing an employee of fraud may require the employee's equipment and data to be lawfully seized and searched. Any mistake made while collecting and analyzing evidence will render it inadmissible in court.

Data acquisition is complicated because capturing evidence from a digital "crime scene" is more complicated than from a physical one. Some evidence will be lost if the computer system is powered off; on the other hand, some evidence may only be attainable once the system is powered off. Additionally, evidence may be lost depending on whether the system is shut down or "frozen" by suddenly disconnecting the power.

Data acquisition often requires specialized software or equipment to create a disk image from the target device. The image can copy volatile or nonvolatile storage, and a system memory snapshot (memory dump) is also often created to aid in later analysis. Evidence capture prioritizes collection activities based on the order of volatility, initially focusing on highly volatile storage. The ISOC best practice guide to evidence collection and archiving, published as tools.ietf.org/html/rfc3227 , sets out the general order as follows:

1. CPU registers and cache memory (including cache on disk controllers, GPUs, and so on)
2. Contents of system memory (RAM), including the following:
   • Routing table, ARP cache, process table, kernel statistics
   • Temporary file systems/swap space/virtual memory
3. Data on persistent mass storage devices (HDDs, SSDs, and flash memory devices)—including file system and free space
4. Remote logging and monitoring data
5. Physical configuration and network topology
6. Archival media

The tools available to gather data include:

• Packet analyzers such as Wireshark and TCPDump.
• Endpoint Threat Detection, a tool that monitors endpoints for threats.
• Drive copy tools.
• Memory dump tools.

Mobile Forensics

Mobile devices have become an integral part of the business world. They are often an important part of digital forensics. Forensics on mobile devices can tell you:

• Where users have been.
• Whom they have contacted.
• What media they have created.

There are different levels of data acquisition types in mobile devices. The following table shows five types of acquisition:

Type	Description
Manual acquisition	Information is accessed through the device's interface. Pictures are taken of the evidence. No tools or other devices are used, making this the simplest method. Only information available through the interface is accessible.
Logical acquisition	Directories or files found in logical storage objects are copied using an API from the device's original manufacturer. The files are copied to a computer, where it is easier to examine the data.
File system acquisition	Files are extracted from the device's database. This includes files that were marked deleted and not available from the device's interface. This is done through the synchronization interface.
Physical acquisition	The entire flash memory is copied. This includes deleted files and data remnants. You can use bootloaders to override passwords or other access blocks in order to access the flash memory.
Brute force acquisition	You can use a brute force tool to try a large number of password combinations in a short period of time. With the password cracked, you can access the data. These tools are intended for law enforcement and are expensive.

Cloud Forensics

Many organizations use a cloud service provider (CSP) for network services, applications, and storage. Performing forensics in the cloud environment has unique challenges. A key issue is the storage location. CSPs can store data in multiple states and even multiple countries. Each state and country has different laws and regulations, which makes jurisdiction complicated.

The basic steps in following cloud forensics are:

1. Identify the suspicious activity or crime.
2. Collect data without tampering with it. You must do this through legal means and following the CSP's policies.
3. Use filtering or pattern matching to establish the questionable activity.
4. Analyze the data. You can do this with forensic tools.
5. Notify appropriate law enforcement if a crime was committed.

Virtualization

Virtual machines create a challenge in performing forensics because they leave a very light footprint on the host machine. A disk image file called a VMDK is a container for a virtual machine hard disk. A host machine uses a VHD file to host a virtual machine.

These two types of files can provide a door for the forensic investigator to extract data. Through the emails stored in these files, an investigator can access files in the virtual machine using a virtual machine email recovery tool. Virtualization can also provide a safe environment for investigators to test theories without compromising evidence or the actual environment. An investigator can create a virtual replica of the environment to test theories.

Legal Holds

A legal hold is a way to preserve data that might potentially be important to an ongoing legal investigation. It is sometimes known as a litigation hold. A legal hold is a legally binding order that requires the custodians of the data to preserve it until the time when it is no longer needed for discovery or litigation. The data custodians must be given a legal hold notification in writing. Key aspects of a legal hold are:

• The notice identifies the data that needs to be preserved and why.
• As soon as a legal hold applies, the data cannot be altered in any way from its original form.
• Altering the data would destroy its usefulness as evidence.
• The custodians must immediately suspend any activities that would alter the data until the legal hold has been lifted.