Using a Functional Cybersecurity Exercise to Test Incident Response Plans

Author: Patrick Barnett, CISA, CISM, CEH, CISSP, PCI QSA, PCIP
Date Published: 8 April 2024
Read Time: 6 minutes

Most organizations routinely review their incident response plans and playbooks to better prepare to defend against modern cyberattacks. One technique, which has been commonplace for many years, is to conduct a routine cybersecurity tabletop exercise (TTX). However, a lesser-known tactic organizations can employ is to enhance tabletop exercises with a functional exercise (FTX). An FTX empowers enterprises to test their abilities and prepare their cyberrisk teams to defend against dreaded cyberattacks that occur far too often today.

What Is an FTX?

To fully grasp the concept of an FTX, it is crucial to first comprehend the intricacies of a TTX. A TTX can be effective, but it is limiting. This is because it is not a real situation, but rather, a mock exercise that involves some imagination. Conversely, an FTX is real—but not damaging—and requires a real response. In fact, an enterprise may decide not to inform a cyberrisk team of a planned FTX at all, allowing them to believe that it is a real incident and malware has entered the network. Either way, an FTX is a true gauge of preparedness, skills, processes and procedures. Throughout the past 10 years, the author has conducted more than 1,000 TTXs with organizations all over the world. Approximately 2 years ago, the author developed an FTX and began proposing it to clients looking to elevate their routine (and sometimes mundane) TTXs.

An FTX is real—but not damaging—and requires a real response.

The process for offering an FTX is simple. The author developed a file (benign malware) that is identified as a Trojan Meterpreter. A Meterpreter is defined as “A Metasploit attack payload that provides an interactive shell from which an attacker can explore the target machine and execute code. Meterpreter is deployed using in-memory dynamic link library (DLL) injection. As a result, Meterpreter resides entirely in memory and writes nothing to disk.”1 In the author’s example, the Meterpreter only communicates with the localhost at the IP address 127.0.0.1, and there are no instructions to execute.

The file is immediately flagged and quarantined by every next generation anti-malware vendor, including Microsoft Defender. Essentially, all telemetry (measurement and data transmission) goes haywire when the file is executed, but nothing untoward occurs other than the alerts being triggered.

Setting Up the Exercise

The author often works with an inside contact (e.g., a manager, chief information security officer [CISO], chief information officer [CIO], internal counsel) to set up and perform this testing exercise. At the designated time, the inside contact executes the benign Meterpreter and alerts are automatically generated on the designated endpoint(s).

At this point, there are several routes that can be taken. One technique is to not do anything other than observe the cyberrisk team and stay silent. An enterprise may decide to conduct the FTX itself, or a preferable, less biased approach is to use a third-party cybersecurity partner to conduct the exercise and assessment on the organization’s behalf. Alternatively, another popular technique involves videoconferencing with the incident response team (IRT) to inform them of the situation. For example, this could be said to the IRT: “Malware has just been executed somewhere on your network and we want you to find it, isolate, contain, analyze, eradicate and recover.” The team would then be advised to work the incident life cycle by following policies and procedures dictated by the cybersecurity incident response plan (CIRP) and playbooks. When this has been completed, the team should present their actions and findings to the appropriate audience.

What Is Expected?

When using this approach, the author creates a slide presentation to highlight exactly what information they want the IRT to present to the audience when the IRT has completed its response. The IRT is asked to save screen clips, logs, telemetry and other artifacts in order to present the details later. Team members are instructed to include file names, IP addresses, machine names, ports, accounts used, hashes, malware analysis and more. In addition, the IRT is asked to adopt a chain of custody (CoC) technique that involves filling out a CoC form with all applicable information and hashes of digital evidence. Ideally, the IRT will also collect a forensic image of memory and disk on the affected endpoint(s). While they do not need to examine the forensic copies, they should know how to collect them and document everything on the CoC form. As is the case during a real incident, the IRT is advised to trust, but verify.

It is that simple. If one decides to conduct the exercise silently (i.e., nobody knows it is an FTX), then a post-incident review should be conducted afterward wherein all evidence and artifacts are requested. The IRT will present the information, but may not realize they have experienced an FTX.

Alternatively, the FTX can be made public knowledge. In this case, when the leader of the FTX meets with the IRT to present the exercise details and discuss what results they want to see during the post-incident review meeting, the IRT can ask questions or request additional information. The author routinely advises the IRT that they will be expecting everyone to participate in the presentation and that all logs and evidence should be made available for viewing by the audience.

Lessons Learned

After the IRT presents the incident and evidence gathered, a lessons-learned review can be conducted to identify areas for improvement. The author does not conduct pass/fail exercises, but rather, labels the entire process a learning/educational opportunity. Instead of critiquing the IRT, they are asked for input on what worked well and what could be improved. If something was missed (e.g., an action should have been taken during the FTX that was not), the IRT should be informed in an educational manner, rather than a critical one. The author recommends taking every opportunity to praise the IRT for what it did well.

If there is a notable number of missteps or actions not taken during the FTX, a repeat FTX can be conducted in the near future. Practice makes perfect.

Benefits of an FTX

An FTX tests the IRT and allows management to get a full picture of what to expect during a true incident response. It is great practice for everyone involved and can be made to be as real as one desires. It also provides an idea of the teamwork and timing required for various tasks that can be hard to estimate in a TTX scenario.

Conclusion

Conducting an FTX is an effective way to assess whether an organization’s IRT has the knowledge, communication skills, training, tools and teamwork required to perform well during a stressful incident response. This approach has obvious advantages over learning in the midst of an actual cyberattack, with threat actors and malware running rampant throughout the network.

Additionally, enterprises may benefit from using an FTX to ramp-up annual testing, rather than a traditional TTX. Management, auditors and cyberinsurance agencies love this type of testing, and so will the IRT. It can even be made fun by having competing teams work the FTX incident.

We all learn better with practice. An FTX ensures that IRTs are not forced to discover what they do not know during a true emergency.

Endnotes

1 Secret Double Octopus, “Meterpreter,” The Secret Security Wiki

Patrick Barnett, CISA, CISM, CEH, CISSP, PCI QSA, PCIP

Is an incident response principal consultant for Secureworks. He has more than 30 years of experience as a cybersecurity professional and specializes in network engineering with a focus on security. In previous roles, he acted as chief information security officer (CISO) and chief information officer (CIO) and has served as vice president at a large financial enterprise. Barnett is driven by a passion for seeing cybersecurity done right and is committed to aiding organizations in defining proper policies, procedures and mechanisms to respond to security events of any size.

Additional resources