Review your content’s performance and reach.
Become your target audience’s go-to resource for today’s hottest topics.
Understand your clients’ strategies and the most pressing issues they are facing.
Keep a step ahead of your key competitors and benchmark against them.
add to folder:
Questions? Please contact [email protected]
Alex Campbell, Spencer Lynch and Brandy Wityak, Stroz Friedberg, an Aon company
This is an extract from the 2022 edition of the GDR Insight Handbook, published by Global Data Review. The whole publication is available here.
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:
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.
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:
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:
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:
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:
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:
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.
This article was originally published on Global Data Review, the only publication that holistically analyses the law and regulation of the use and trade of data around the world. Subscribe now.
This article was originally published on Global Data Review, the only publication that holistically analyses the law and regulation of the use and trade of data around the world. Subscribe now.
add to folder:
If you would like to learn how Lexology can drive your content marketing strategy forward, please email [email protected].
“I really enjoy Lexology and incorporate into my practice everyday. I find the content very timely and well written. Keep up the good work.”
© Copyright 2006 – 2022 Law Business Research