Cyber Forensics: Effective Use of Incident Response Experts
The role of cyber forensics and the need for incident response experts is often misunderstood and underutilised in the wake of a data breach incident, with serious consequences for the long-tail goal of resolution and recovery. Sometimes considered the ‘black box’ of incident response, cyber forensics ultimately is the application of investigation and analysis techniques to gather and preserve evidence from a particular computing device in a way that is suitable for presentation in a court of law. Best practice in incident response warrants a better understanding of cyber forensics and the critical need to leverage experts throughout the lifecycle of an incident, in particular during post-incident activity. Organisations are called on to re-hash, defend, and re-defend how they handled a particular incident, yet technical experts often exit the scene and are entirely absent after the incident has been contained, when much work remains to be done.
To illustrate the role of technical experts in cyber incident response, this chapter presents a ‘triple extortion’ ransomware attack scenario in which the attacker applies multiple techniques to infiltrate not only an organisation, but also a third-party data controller, thereby achieving access to multiple other businesses. This is a highly realistic scenario, and one that has played out in the recent past. Ransomware is a headline risk that all organisations face. Business interruption is highly likely, and costs associated with ransomware are expected to reach US$20 billion in 2021. No longer confined to the simple model of ‘pay to decrypt’, data is now extorted, breached or even erased. At the close of 2020, seven in 10 ransomware attacks involved the threat to leak exfiltrated data, and some variants threatened to auction stolen data. There was also an emergence of data destruction, in which servers or clusters of data are permanently wiped.
After presenting the ransomware scenario, the chapter then takes the reader through a response simulation following the National Institute of Standards and Technology (NIST) Incident Response Life Cycle for Incident Handling to examine the organisation’s response, from technical investigation and restoration of critical systems to ensuring that the necessary lines of inquiry and evidence are preserved. Post-incident forensics is a focal point of this section, as it is often underestimated in its importance. This stage in the incident response process is often in fact the starting point for answering fundamental questions: What was the root cause of the attack? What data was accessed, and from where? Was data exfiltrated, and if yes, what data? These questions are the heart of understanding the organisation’s exposure.
Next, the chapter presents the value of technical experts in the long-tail of the incident. It details the key questions an organisation needs to answer if, and when, it is called to defend its cyber security measures, its approach to response or its handling of an incident in conjunction with connected third parties. Only with technical support can an organisation identify the full set of questions that need to be investigated and be clear on how – and in what time frame – they can be answered. In situations where key questions do not have a definitive answer, which frequently occurs, the forensics expert provides insight into what evidence is indirect or circumstantial, so that the organisation and advisers can act accordingly. To round out the discussion, the chapter then examines how organisations can, and should, launch regular cyber forensic investigations even without a detected incident, and discusses the often-overlooked importance of cyber forensics due diligence in a deal context, such as in mergers and acquisitions (M&A).
Case study scenario: ‘triple extortion’ ransomware attack
The chief information security officer (CISO) of a global software-as-a-service (SaaS) provider that runs an online content platform rises Monday morning to find the platform is down. The organisation is the victim of a ransomware attack, and the demand is €20 million. Thankfully, the organisation has back-ups and a disaster recovery system, so leadership chooses to not pay the ransom. The internal information technology (IT) team activates, calls in the organisation’s incident response partner, and together they tackle the development of a new infrastructure, and commence the process of restoring content to get the platform back up and running.
Twenty-four hours later
The organisation’s network and content platform begin to come online. Then comes bad news. A handful of employees receive individual emails from an anonymous sender who claims to be the attacker. The email informs the employees that, as part of the attack, a substantial amount of data hosted on the organisation’s content platform was stolen. The attacker expects to receive the €20 million and issues a threat to release the stolen data if the demand is not met. The attacker posts online a sample of the files as proof and sends a link to confirm validity. The organisation again refuses to engage.
Seventy-two hours pass
A customer relationship manager receives an urgent call from a client. The client received an email from someone claiming to be the ransomware attacker. The attacker claims to have stolen the client’s data from the organisation’s content platform and threatens to expose or sell the data if the customer does not pay €1 million.
Over the course of this three-day period, the SaaS organisation precisely executed its incident response plan. The IT team began the restoration of data, and external experts comprised of legal counsel and an incident response team were brought in to assist. During this initial stage, the main response goals were to:
- contain, restore, and bring all systems back online;
- communicate with clients and provide assurance that the incident was contained and would not be repeated;
- figure out what happened; and
- make any legal filings required, to the extent necessary.
Using the organisation’s configuration management and deployment tooling, the team rebuilt and hardened the environment. Data was restored, an antivirus system was deployed, and credentials for administrator access were removed where found to be unnecessary. In sum, the organisation hardened its network and improved defences across the Cyber Kill Chain, the Lockheed Martin model that identifies what activities the adversaries must complete to achieve their objective.
A non-forensics expert might consider this the end of the response and recovery plan. But this is only the beginning of uncovering more substantial insight that will help protect the organisation from further compromise and mitigate its exposure to losses and liability arising from the incident.
Applying the NIST framework: a cyclical model for incident response
The NIST Incident Response Life Cycle was developed by the National Institute of Standards and Technology in the United States to present a framework for managing response to, and recovery from, a cyber breach or attack. This model is frequently presented as a cornerstone of cyber incident response. In this chapter, the reader is asked to refrain from taking a simplistic, or narrow, view of the NIST Incident Response Life Cycle. An essential takeaway from the NIST framework, for organisations and lawyers, is that incident response is cyclical, not linear. When implemented effectively, organisations investigate, or ask and answer questions, in an iterative manner and open to receiving answers that set the investigation on a new path. This path might even be to a prior branch, or step, in the NIST Life Cycle. It might be the case that as an organisation moves through an investigation, what one thinks is the end of the investigation is just a new beginning.
The answers might not come easily. To illustrate using the SaaS ransomware scenario, as an investigator moves through the first set of machines known to be touched by the attacker, they might find that on the first 50 machines accessed within the network, the attacker did not move laterally or exfiltrate data. But, on the 51st machine analysed the investigator finds that the attacker accessed 25 additional machines from that, and only that, single machine. Then, from those 25 machines (previously unknown to the investigator), it is discovered that the attacker did indeed exfiltrate data.
In applying the NIST framework, pay particular attention to post-incident activity. This is a principal component within the response process. Many organisations misinterpret this phase, falsely assuming that once a breach is contained, the investigation is near its end and the risk has abated. This is false. If an organisation does not painstakingly pursue post-incident recovery, critical questions will likely be missed and regulators, legal teams, and partners will take notice.
National Institute of Standards and Technology, Special Publication 800-61, Computer Security Incident Handling Guide (rev. 2) (2012)
The SaaS ransomware breach through the lens of the NIST Life Cycle
Preparation ensures an organisation is ready to respond. Within the SaaS breach scenario, it is clear that the organisation had spent time preparing. An incident response team was immediately engaged, systems were brought back online within 24 hours, the network was hardened and clients were notified. There was a plan and they followed it well.
Detection and analysis
During detection and analysis, forensic experts collect data from a range of different systems, security tools, even public information sources. The objective is to identify precursors, signs an incident may be about to expand or escalate; or indicators, signs an attack has happened or is happening now. Network-based indicators are highly informational. For example, an expert might learn from where an attack originated, which helps determine what machines are connected to that attack source, and are thus vulnerable. The expert might come to the breach knowing what malware was used, for example in the ransomware attack. Armed with this knowledge, the expert can search for this particular malware, and copies of this malware, on the network. If the forensics expert knows that the identified malware uses a particular naming convention or hides itself in a certain folder (for example the ‘system’ folder), these locations are searched. This is detection. All too often, organisations stop at simple detection and response. But continuous detection, and analysis, is crucial.
Analysis is the continuous questioning phase, in which the forensics expert builds out the indicators. Questions asked and answered include: Is there any other malware on this computer? Is there a high-level of activity that indicates the attacker is accessing additional machines on the network? This level of analysis is evident in the ransomware scenario, when the 51st machine is identified; the machine that opened the attack surface to 25 additional machines on the organisation’s network. Thankfully, in this case, the team had the wherewithal, or automation, to analyse another machine after 50 had similar findings. Some investigations rely on sampling that might miss such a scenario.
Containment, eradication and recovery
While the organisation may have other questions, the number one priority is to be certain the attacker is out of the network. For most organisations, a second and competing number one priority is becoming operational. Every minute of downtime impacts the balance sheet, of not just the organisation, but potentially third parties. Within the ransomware scenario, the organisation initially shut down all the machines thought to be affected, and substanttial segments of the network. Now, the organisation needs to turn things back on. This is necessary to confirm eradication. Without this, recovery cannot be safely implemented.
While other response frameworks might separate these elements, it is nearly impossible to not execute these processes hand-in-hand. During the SaaS breach scenario, for example, the incident response team might ask for certain machines, known to be infiltrated by the attacker, to be shut down or isolated to contain the attacker to those machines. The team might implement a firewall rule to prevent the attacker from moving from a known compromised machine to a clean machine. Malware might be removed from machines, and some machines will be destroyed and rebuilt. The team may have to take other machines off the network to clean and patch. Other machines will be turned on to get evidence or allow access to disconnected data or areas of the network. This is the iterative, or cyclical, nature of the NIST Life Cycle: Contain, eradicate, and recover in a constant cycle until the organisation is confident the attacker is out, and the network is secure.
What is not explicitly called out in this process, but is deeply important, is that the team must preserve evidence of what actually transpired. It is not sufficient to kick the attacker out and bring business back up to operation. In haste, the response team might be destroying machines with log files or computer artifacts that will help inform further actions. There is a need to expertly balance how the organisation will document actions and preserve enough evidence to enable future analysis, while still achieving the priority goal of rapidly detecting and shutting down the attack. Designing a secure network is different than rebuilding one out of the ashes of a compromised one.
Ultimately the most important factors, at least with regard to data, in incident response will likely fall into the post-incident recovery phase. Three core questions still need to be posed and investigated. Questions that likely remain to this point are:
- What was the root cause of the attack?
- Was data accessed and if yes, which data and was there exfiltration?
- Were lateral movement and persistence mechanisms evident in the attacker’s path?
It is entirely possible that, during the initial hours of the investigation, the response team observed access or exfiltration of data. The team may have some preliminary insight, but still have many more questions. To illustrate with the ransomware scenario, the attacker claims to have exfiltrated client data. While the organisation is aware of this critical fact, this insight is temporarily set aside for later investigation, as they rightfully want to make sure more is not exfiltrated. Doing a deeper dive on data exfiltration during an active breach is counterproductive. So long as the attacker has access, it is like chasing a moving target. Only once containment, eradication, and recovery are complete, can the deeper forensic investigation begin.
For the breached SaaS content platform, across all machines where malware was identified it is important that the team ties the access back to the first compromised machine. It is highly likely that this will identify the attacker’s entry point. This is a detailed and often manual process and not necessarily a simple ‘scan and compare’. Malware will often try to cover its tracks. The investigation might involve looking at time stamps (whether they are authentic or not) or event and system logs, that provide trails to help identify when the malware first ran on the network. Unfortunately, on most computers there is not a single running log to answer this.
Apart from logs, forensics experts might identify that the attacker was using a specific username to conduct the attack. Now the investigative trail asks, on what computer did this username first log in? Or, on what computer did this username log in where we do not think it was a legitimate log-in? Many attackers will use a name that is already in use, for example a particular employee. Alternatively, the forensics expert might infer first compromise based on where the attacker likely found the employee credentials. For example, if a username is assigned to a specific individual, and that individual only uses one computer on the network, the team can often reasonably assume that this was the first computer to be compromised.
With the entry point confirmed, it is only at this point that the team is coming close to identifying the root cause. An analysis of the identified computer asks: How did the attacker get access? At times, even when the team is sure they are looking at the first computer impacted, the trail gets more intricate. For example, assume in the ransomware scenario that the attacker gained entry via a standard phishing attack. The targeted employee only used his or her desktop, and no other machine. However, the investigation then reveals that the attacker phished, stole credentials, and then used those credentials to get into a remote desktop environment that did not have multifactor authentication (MFA) controls. Thus, the root cause in this scenario was a combination of phishing and remote desktop vulnerability.
Data access and exfiltration
During data access and exfiltration, the forensics expert is determining whether the breach is classified as a security breach, where the attacker penetrated the network but no files were accessed, or a data breach. Returning to the ransomware scenario, the attacker’s theft of client information confirms a data breach. In many jurisdictions, there is now an obligation to identify what information was accessed, and what information if any was exfiltrated?
In this process, forensic experts are looking for signs that indicate the attacker was searching for information. Is there evidence of file access? Were folders examined? When data is accessed, the attacker will typically stage that data, using some form of archive copy (such as a .zip file) on a particular machine or series of machines usually in hidden places, for example a system folder or recycle bin. This makes it easier to transfer the files out of the network environment, likely using common file sharing protocols or cloud storage. Traffic that is not normally blocked in an organisation’s network.
The investigator may identify where the attacker was staging the data, but after exfiltrating the data the attacker deleted the files so the exact contents is still unknown. Or, the forensics expert may find the staged data, but learn it has been encrypted with an unknown password. Using the ransomware scenario, the investigator might have discovered that a 10 GB .zip file was exfiltrated, but the contents of that file are unknown. The team is dealing with a ‘black box’ of data. Forensic questioning continues: What did the attacker access around the time that the data was staged? It may be the case that the investigator can, from a variety of artifacts, identify what data was accessed from any given computer. Remember, as illustrated in the ransomware scenario, the attacker might have used 50 different computers to get to the 51st computer that delivered access to the sought files.
Sometimes, it becomes even more challenging to identify exactly what files were accessed. The artifacts might be such that the forensic expert can only determine that the attacker accessed a highly confidential client folder on client server, but it cannot be confirmed what files within the folder were accessed. To illustrate, if the SaaS organisation’s content portal had 2TB of data on file server, and it is known that the attacker accessed that file server, and the attacker staged 10 GB of data, the investigator can reasonably assume that the attacker stole only one tenth of a percent of the accessed data. But, finding out exactly which files, or which percentage, is formidable. It unfortunately may be impossible, and while the investigator expertly employs reverse engineering malware and memory analysis techniques, the ‘black box’ remains.
For any forensics analysis, even if the team is investigating only one computer, there are feasibly tens of thousands to hundreds of thousands of data points to analyse. In a scenario with 75 machines impacted, one can easily have tens of millions of data points to comb through to piece together the attacker’s actions. Weeks might pass after the containment, eradication and recovery process is complete before an organisation knows the best answers on root cause, if data was accessed or exfiltrated, and what data was involved.
As stated at the beginning of this chapter, the most important actions in incident response fall into the post-incident recovery bucket. It is critical to give this element of the NIST Life Cycle its place in the incident response cycle, and to document in detail actions taken and evidence found. Not only is this necessary to understand the nature of the attack, so that the organisation can more effectively build its cyber resilience, but is necessary to protect the organisation from questions sure to come from clients, partners, regulators and potentially litigators.
Defensibility: preparing to advocate for the organisation’s approach in a potentially contentious incident
Defending the approach from a technical perspective
We can assume that any incident suffered by the organisation may, and often will, give rise to a host of competing pressures to articulate how it happened, whether it could have been prevented, whether the security measures and controls were adequate, and whether the actions that the organisation took in response were legitimate and justified by the facts. Experienced investigative experts will help build a position from which one can advocate for the organisation after a significant cyber incident. A mature organisation is litigation-aware and adept at preserving the integrity of the forensic investigation to help defend the organisation’s position for the long-term. This is highly important given the increasing prevalence of follow-on class actions, commercial disputes and enforcement actions. Nevertheless, cyber incidents are fundamentally a business problem, and incident response experts will be also able to apply their particular expertise, which is distinct from that of corporate security experts, to help the organisation make accurate and defensible communications in these potentially contentious situations with parties such as employees, business partners, customers, and insurers.
A common weakness in incident response (IR) is relying too heavily on the organisation’s ‘business-as-usual’ IT and security resources to own and implement every technical aspect of the response – whether that be aligned to a pre-existing incident response plan (IRP) based on the NIST framework, or to a custom strategy developed in consultation with breach counsel. Neglecting to use experts at the appropriate points in the response can turn a minor incident into a major disruption. To illustrate, in the ransomware scenario the dedicated forensic resources enabled the discovery of an infection at the 51st machine. This was achieved only by bringing technical expertise and automation to the investigation. Without this level of support, regulators and future litigants will inevitably challenge the efficacy and adequacy of the response and will be sure to zero in on the lack of expert support.
To understand whether forensic experts are being properly leveraged throughout an incident, ask the following questions:
- Is the use of experts built into the IRP? The IRP must provide for the referral to and use of technical incident response experts (not an IT vendor), external ransomware negotiators, a law firm with breach counsel experience and a PR firm at a minimum.
- Has the expert been given what they have requested? An effective incident response expert will be very clear on what data, information, and access they will need to conduct the investigation. This can be difficult for the organisation and its IT function in the middle of a crisis. It is best if an organisation has fully onboarded its incident response expert in advance to avoid losing time.
- Is the expert being given too limited a brief? In delegating investigation work to experts, the organisation often chooses to focus investigation only on identifying what machines were compromised. We often see root cause analysis not being consistently applied to incident handling, nor is the expert granted sufficient visibility of the system architecture to perform an independent root cause analysis. This often prevents mitigation activities.
Defending the approach through robust incident documentation
One of the most common ways in which an organisation can undermine its ability to mount a defence is by failing to keep documentation. The organisation can expect to receive questions during and after an incident and the risks of an inaccurate, misleading, or incomplete response are considerable. To ensure that the organisation is ready to defend its approach, ask the following questions:
- Is a detailed chronology being made in real time? A detailed incident chronology will be a cornerstone of post-incident advocacy. It should detail what technical facts were known and when, why decisions were made or certain views taken based on those facts. There will be competing business and technical considerations, and an action that supports one might negatively affect another, so the organisation should be able to present context and detail to defend the choices it makes in a crisis. In the ransomware scenario described, the organisation should have documented in detail the facts and the basis on which it turned some machines back on to restore operations and left others offline for longer periods of disruption.
- Are the investigation experts included in all incident communications, and how frequently are technical updates needed? It is much simpler to gather the truth if communication is confined to a small group of channels accessible to the entire incident response team – not only internal IT teams. Confining the technical expert communications to the same channels as breach counsel also can help maintain potential claims of privilege.
- Exactly what is in the compromised data? Often overlooked is the need for a thorough understanding of what is in the data accessed, stolen, or exposed by the threat actor. In the ransomware scenario, the organisation will need to know precisely which customers’ data was present on the content platform at the time of the attack, and at earlier periods in which the forensic investigation shows the attacker could have accessed the data. Processing email communications of compromised mailboxes also allows the organisation to know how the attack spread within the organisation or to third parties via email communications. Most organisations do not know, to a level of granularity to be helpful in a breach scenario, what data they hold and where it is. Assessing the compromised data helps to better understand the potential damage to others – for instance, how sensitive was the data, and was personal data accessed? Knowing this will also help direct the notification strategy for potentially affected data subjects, regulators, internal stakeholders and others.
- What kind of written reporting is required? The potential for written reports to be discoverable in future disputes warrants a careful consideration of why a particular report is commissioned and what its scope should be. Should there be an internal summary report or a formal export report that’s going to be rigorously examined and interrogated later? The expert should also advise on technical facts in reporting to other parties, such as law enforcement, insurers and the public.
Soundly deploying forensic expertise
Forensic experts are careful to maintain a position of independence, yet balance this with supporting the legal team in post-incident advocacy, providing technical facts and arguments in fine negotiations with data protection and industry regulators, or in group actions and litigation arising out of data breaches. In deploying forensic expertise where there is a potential enforcement or disputes situation, make sure to consider the following questions:
- What technical facts are available within mandatory reporting time frames? The organisation might detect a potential breach on a Monday but may not know with reasonable certainty whether data has actually accessed or exfiltrated for weeks. Once an incident is detected, the organisation and its counsel will understandably be fixated on how soon they can know the facts that trigger the need to report – and to whom. In most cases, this information cannot be known within the very short time frames mandated by a regulator.  Organisations need to be mindful of this and work closely with their counsel and experts to make a call on whether to report, when to report, and how much detail to report. If later called to defend the timing of when the reporting was made, having access to the documentation and detailed incident chronology will be vital.
- Have the experts been consulted before sharing findings? The organisation never wants to walk back statements about the nature of the incident. Details such as how much data was exposed, how sensitive was the data, is there evidence that data was taken, have massive implications for potential exposure. Before conveying technical findings outside the incident response team, verify with the expert that all the analysis and peer review steps are completed. Preliminary views communicated within the team may be subject to change, and it is important to make sure confidence levels are discussed before findings are communicated.
- Does the team understand the limitations of the available evidence when it comes to proof? The lack or limitations of evidence is another point the organisation and its counsel can expect to need to defend. The data may never be absolutely conclusive or provide certainty or comfort, but the forensic expert will be able to help the organisation and its counsel navigate those limitations.
- Is there evidence beyond the forensic artefacts that can help in the defence? Digital forensic artefacts are only part of demonstrating how the organisation’s response to an incident, and the security posture it had in place, was appropriate. For example, it is usually relevant to be able to argue whether the organisation was in step with its industry or met independent security standards. Artefacts can also help explain causation, such as which technical measures and controls actually contributed to a breach or could have actually prevented it.
Launching a cyber forensics investigation without a detected incident
Cyber threats are constantly evolving and adapting to meet technical advances, big data, new communication channels and ways of doing business. Given the increasing volume and sophistication of attacks, there is now increasing pressure on businesses to take additional steps to seek out threats proactively. There are scenarios where organisations must take action to conduct cyber forensics analysis on their systems, even if the security programme has not detected a potential incident. Set forth below are some examples where this might occur.
Threat hunting as an early warning system
Attackers are likely to move undetected for a long time and by the time the attack is executed, the threat actors might have taken time to collect and test passwords, infect networks, disable firewalls, and gain trusted access to the network, allowing them to entirely evade detection by the organisation’s existing security controls. Threat hunting allows organisations to help answer the question: ‘Have we already already been breached?’ It is ideally part of a structured ‘early warning system’ and is the act of proactively searching technology estates and company data sets for evidence of compromise or intent, such as for signs of malware, suspicious persistence mechanisms and lateral movement. It can identify widely known attack patterns as well as potentially suspicious activity and outliers that might otherwise evade traditional or more automated security solutions.
The areas of investigation are illustrated in frameworks such as Mitre ATT&CK. The scope and analysis are highly dependent on the context, but as a general approach the forensic expert will be looking for primary evidence (eg, digital artefacts such as suspicious executable files, log-ons or files in common locations for dumping malware) that are ‘red flags’. The expert will also examine secondary evidence for context, detail, and verification. A threat hunt is not a full-blown investigation – it is being done to find whether one is warranted, in which case the NIST Life Cycle presented earlier in this chapter will apply.
Threat intelligence is also essential and involves continuous monitoring or proactive searches of information from multiple data sources to identify existing and upcoming threats. For instance, regular scanning of the Deep and Dark Web can locate breached corporate data, compromised credentials, and security vulnerabilities associated with corporate assets. Organisations should also employ continuous network vulnerability scanning of critical systems or those connected to the internet at a minimum. The information gathered should be reported and shared with management as well as the IT and security function.
Cyber due diligence in M&A
A proactive assessment of cyber threats is extremely important at times of key business or technology change. During a merger and acquisition, if no technical cyber security due diligence is conducted, an organisation might acquire great risk that erodes the value of the deal, for example, compromised or unsecured digital assets or evidence of breaches that bring potential liability and losses. Cyber due diligence that includes forensic analysis of the target company’s technology infrastructure is extremely useful in three core areas of deal value:
- Digital Risk. Only technical experts can get inside the organisation’s network to search for evidence of security or data breaches and hidden vulnerabilities. Experts look for evidence of compromise and cost of remediation to help the organisation and its counsel identify potential risk of fines or costs for compliance.
- Digital Value: A forensic examination assesses whether the intellectual property (IP) and digital assets are adequately protected. Experts also look at the organisation’s network for indicators of malicious or fraudulent user traffic that might potentially erode value.
- Digital Performance: Forensic analysis is useful in finding evidence that might affect key performance indicators that underpin valuation. Experts can help identify malicious, fraudulent or bot-like activity on the platform, and forensically examine the platform being acquired for indicators of compromise.
Concluding guidance: Do not let cyber forensics remain a ‘black box’
This chapter illustrates the vital importance of forensic experts throughout the life cycle of incident response, in particular during post-incident response. To overlook this could be detrimental to the long-term goal of resolution and recovery in the wake of a cyberattack, and not knowing when to use experts can turn a minor incident into a major disruption. Similarly, technical experts are instrumental in achieving cyber readiness, whether it be via a proactive threat-hunting programme or M&A due diligence.
Incident response is cyclical and, contrary to what some think, does not end at containment, eradication and recovery. Too often, organisations think they have reached the end of an investigation when, in fact, the most important factors regarding data have yet to be explored. Beyond these questions, the need to defend the organisation’s approach from a technical perspective is of utmost importance. A mature organisation is litigation-aware and adept at preserving the integrity of the forensic investigation. Organisations will receive questions during – and after – an incident. Robust documentation can mitigate the risk of providing inaccurate, misleading or incomplete answers, and soundly deploying forensic expertise is essential to providing this document trail.
By following the recommendations and lines of questioning illustrated in this chapter, organisations can more confidently investigate, and answer, the right questions.
 Lutkevich, Ben (2021, May). ‘What is Computer Forensics (Cyber Forensics)?’ SearchSecurity. https://searchsecurity.techtarget.com/definition/computer-forensics.
 Aon (April 2021). ‘2021 Cyber Security Risk Report. Balancing Risk and Opportunity Through Better Decisions.’ https://www.aon.com/2021-cyber-security-risk-report/.
 National Institute of Standards and Technology, US Department of Commerce (August 2021). ‘Computer Security Incident Handling Guide’ https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf.
 When an incident occurs, a structured incident response workflow will help ensure a consistent and repeatable approach to incident management. Having a clear understanding of incident response processes – who does what, when, how and why can enable the efficient delivery and enablement of an IRP. There are reputable sources in the cybersecurity field that provide guidance on incident response processes (e.g., NIST; SANS Institute), and supporting activities might include the development of incident categorisation models and technical playbooks. National Institute of Standards and Technology (NIST) Computer Security Incident Handling Guide: https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf; SANS Institute, Digital Forensics and Incident Response: https://www.sans.org/digital-forensics-incident-response/.
 We note that picking these firms and negotiating contracts with each of these takes time. Regulatory reporting and cyber claims add further layers of complexity to incident management, making close coordination between the technical experts and breach counsel critically important.
 For example, why was the organisation able to respond with a security fix so quickly to stop the attack? Regulators and other parties might want to know why a security fix was not made earlier? This potentially reveals that the security strategy was deficient, and the organisation could or should have acted earlier to prevent the incident.
 In fact, the organisation should consider whether to engage the services of the forensic expert through its breach counsel.
 This is particularly complex when the compromised data sets consist of large, unstructured company data (such as email communications and file shares). Data analytics tools should be deployed for this, particularly for large unstructured data like mailboxes and file systems that are difficult to search but impossible to review manually. Using sophisticated technical tools originally designed to help organisations assess large data sets for litigation disclosures (known as ‘eDiscovery’), the experts apply searching techniques, natural language processing, AI-driven machine learning, and visualisation tools to help find the necessary facts.
 Separate workstreams and reporting on different security issues should ideally be in place – for instance, the root cause investigation may warrant separate reporting from a post-incident security audit or impart report commissioned for the business to improve their security posture based on ‘lessons learned’ in the course of investigating a specific incident.
 It is also not unusual for a different forensic expert to become involved post-incident, with a brief that is entirely separate from the incident responder involved in analysis and containment.
 But, for example, under the EU’s GDPR, the data protection regulator expects that notice of a personal data breach will occur within first 72 hours, see https://globaldatareview.com/insight/handbook/2021/article/european-union-privacy.
 For example, relevant and necessary data may never have existed; not have been preserved due to the organisation’s technical configuration or oversight; may be difficult to access without specialist skills; or corrupted or lost due hardware damage; or lost due to deliberate tampering.
 For instance, under GDPR, the standard is ‘appropriate technical or organisational measures’; see https://globaldatareview.com/insight/handbook/2021/article/european-union-privacy.
 These are not the only scenarios in which an organisation might decide it is in its interest to run a threat hunt. They may be seeking assurance around the overall ‘health’ of environment – and an active hunt for evidence of historic undetected breaches are often included in audits, risk assessment, cyber insurance cover applications. It can be an extension part of the response to a detected incident – for example, if one business unit suffers a breach, look for any evidence that other units or operating companies were attacked in a similar fashion. It may also be required in by regulators.
 Threat actors often begin with a reconnaissance phase, seeking to identify a vulnerable target and the best ways to exploit it. Once they have accessed the network, to gain ongoing access when launching their attack, they may create admin accounts to escalate their privileges, disable firewall rules, activate remote server access, and even set up a persistent backdoor into the network, bypassing normal authentication or encryption. Before the attack even happens, often they will already have exfiltrated data both to prove that they have access and to threaten exposure. In the next phase, weaponisation, the criminals apply what they’ve learned and shape the direction of their attack, perhaps by crafting credible-looking phishing emails.
 MITRE ATT&CK® is a globally-accessible knowledge base of adversary tactics and techniques based on real-world observations. The ATT&CK knowledge base is used as a foundation for the development of specific threat models and methodologies in the private sector, in government, and in the cybersecurity product and service community – see https://attack.mitre.org/matrices/enterprise/.
 Monitoring involves using cyber experts to design and execute search parameters tailored to key targets outlined by the organisation. Alert notifications are provided based on preferences for communication and frequency. A mature threat intelligence function should have the ability to monitor across industries, geographies, languages and a variety of information sources (eg, the Deep and Dark web, hacking forum and underground marketplaces) and correlate information to determine the likelihood and extent of threats facing the organisation.
 Organisations should give careful consideration to the tooling and services able to provide this, with a critical output being the reporting – this should provide an IT team with the tools needed to identify security vulnerabilities in the network infrastructure, applications and APIs (either on the internet or internally), and then track and manage remediation of identified issues before they can be taken advantage of by an attacker.
 Cybersecurity due diligence in the context of deals is a complex, fast-evolving area, and for more detail, see https://globaldatareview.com/insight/handbook/2021/article/data-driven-ma.