It’s a beautiful autumn day, and for the staff of a Midwestern manufacturer on a waterfront property—we’ll call them XMPL Corporation—it’s business as usual. The weather is sunny and seasonally mild, with a strong breeze. An Estonian-flagged bulk carrier is moored outside the company headquarters while material is offloaded to the pier.
Suddenly the carrier’s conveyor malfunctions, spilling material onto the pier and into the water. The crew reacts quickly, shutting down the malfunctioning system within minutes and containing the spill. XMPL executives follow proper protocol, notifying the appropriate state and local agencies, as well as the U.S. Department of Homeland Security and the Coast Guard, since the ship is foreign. The local NBC affiliate, whose reporter was flying over the harbor and saw the spill take place, calls XMPL for comment and is told only that the proper authorities have been notified. Shortly afterward, an unknown individual is seen coming out of a restroom in the XMPL headquarters; he identifies himself as a crew member and is escorted back to the ship—a somewhat unusual but not unheard-of occurrence at the company. With the spill contained and its contents found to be relatively harmless, the incident is soon concluded, and it’s back to business as usual.
Two days later, however, a routine product quality check shows that its specs have clearly been tampered with. Later that afternoon, XMPL’s CFO finds that several files containing sensitive financial data have been altered, with the modifications timestamped late the previous evening.
What has happened? Could this more serious security breach be related to the seemingly minor incident a few days earlier? More importantly, how will XMPL respond now? How will they contain the damage and recover the ensuing losses to their company and their clients?
It’s Only a Game—This Time
Though the above scenario is fictional, it was recently used by a very real company as part of a tabletop disaster recovery exercise led by CyberNINES cybersecurity experts Greg Zacharski, Todd Streicher, Steve Krueger, and Tyler Heggestad. “A tabletop exercise—TTX for short—is a valuable tool,” Zacharski said. “It’s important for companies and their people to evaluate their processes in response to security breaches and other potentially damaging situations. A TTX can help them think these things through.”
It was Zacharski who first established the TTX as a service provided by CyberNINES, having previously served for 31 years in the Navy, where such exercises are held frequently and are vital to national security. As many of our clients are Department of Defense contractors, the security of their systems is also in the national interest; and realistically, any company, whether government-affiliated or not, can greatly benefit from an exercise designed to improve the security of their systems and data.
A TTX includes at least one participant from every department of the client’s company, as it’s crucial to involve all stakeholders. During the exercise depicted above, representatives from the client’s managed service provider (MSP) and their insurance company also participated. Insurance companies, in particular, often appreciate TTXs, which can provide a tangible understanding of a client’s security policies and demonstrate their commitment to mitigating risks.
The participants work through a fictitious but plausible scenario designed to stress-test the client’s existing policies and procedures for disaster response. It’s a learning exercise, as the client may discover gaps in their current plan and come away with ideas for tightening their security. It’s also a continuous cycle; since cybercriminals constantly evolve new ways to infiltrate, companies must constantly evolve their security plans. Many companies stage TTXs on a regular basis, verifying the improvements made since the last exercise and discovering new areas to work on going forward.
Crafting the Scenario
Creating a TTX scenario requires research and creativity. The Department of Homeland Security provides templates—generalized playbooks applicable a variety of business sectors—which can provide a framework for getting started, but it’s up to the facilitators (such as CyberNINES) to build that framework into a believable, compelling scenario for their client. The plan also needs to be flexible enough to adapt on the fly based on the players’ responses during the exercise, making it somewhat like a kids’ “choose your own adventure” story, albeit with much higher stakes.
The TTX for “XMPL Corporation” was created by Zacharski and Krueger, who extensively researched the company’s business, facilities, and systems. “It’s like a game of ping-pong,” Krueger said. “We bounce ideas off each other. First we come up with a general idea and a game plan, and then we get down to specifics.”
In addition to reviewing information provided by the client, Zacharski and Krueger look at Google Maps to gain an understanding of the client’s building and its environment, and they study their operations network and connections, looking for possible trails into and within the company. “For example,” Zacharski said, “an incident might start on the IT network, but because of the way it’s connected to the controls, the shop floor shuts down. The important thing is to make the players feel like this is happening where they are in a way that’s specific to their business.” In the XMPL scenario, the chaos caused by the initial spill provides an opportunity for an intruder to infiltrate the building and from there, to breach the company’s IT systems.
Setting the Ground Rules
Once the scenario is developed, the players meet. Zacharski introduces the exercise, stressing that the TTX is to take place in an open, low-stress, no-fault environment. Participants play the roles they would normally play for their company during an actual incident, using their own knowledge, abilities, and understanding of current procedures. They are encouraged to express their varying viewpoints and even to respectfully disagree with each other; the CyberNINES facilitators—Zacharski, Krueger, Streicher, and Heggestad—are on hand to draw the players out while preventing the discussion from becoming heated. They also ensure everyone understands that it’s not the participants being evaluated, but rather the client’s systems, plans, and procedures.
Running the Simulation
The scenario is played out step by step, with Zacharski narrating each occurrence and then allowing the participants to react. In the case of the XMPL scenario, the occurrences were: 1) the spill; 2) the call from the local news affiliate; 3) the crew member found in the building; 4) the discovery of the altered product specifications two days later; 5) the discovery of the altered financial files.
After each step, discussion takes place mainly between the participants, who determine what steps should be taken based on the company’s stated policies as well as their own knowledge. The facilitators occasionally step in to provide clarification or gently push back on a particular response, prodding the participants to question their own assumptions. For instance, a common first response to the intruder scenario is that “no one can get into the building without the proper authorization.” The facilitators come back with a series of “what if” questions that may lead the participants to realize it is indeed possible. Including participants from all areas of the company is also valuable here, as one person might know what the “rules” are, whereas another can speak to what occurs in actual practice.
Another thing the facilitators try to draw out from the participants is the chain of responsibility. For the XMPL exercise, one of the company’s key players was unable to attend, which turned out to be beneficial. Whenever this person was identified as the one responsible for taking action, the question immediately arose: “She’s not here; who’s responsible in her place?”
As the discussions continue and the participants state their responses to each situation, the facilitators continually press for specifics. In the investigation of the altered files, they might ask, “What else would you look for? What other evidence would you collect?” If someone’s response seems tentative or uncertain, the facilitators might urge them to examine the relevant policies, or lack thereof. “Is there a checklist for this situation? Is this written into the policy? What is the documented procedure?”
Finally, communication is key. One thing the XMPL participants realized was that because there was no communication to their MSP about the intruder found during the spill, they didn’t know to investigate a possible connection when the altered files were reported two days later. Had they known, they might have proactively started looking for a breach much earlier. “The one thing we can control is communication,” Zacharski observed. “The more we communicate, the better. We can’t assume that everyone involved has the same level of knowledge, so it’s important to have an environment where people feel it’s safe to communicate.”
Taking the Next Steps
Because the TTX takes place within a finite amount of time, it isn’t possible to come up with a final resolution to every occurrence presented, nor is that the point. Rather, the client should come away from the TTX with a clear understanding of the gaps in their security policies and at least some preliminary ideas on how to address them. In other words, the participants have more work to do.
Zacharski aids this effort by providing a list of questions for the client to consider, such as: What actions need to be taken and by whom? What internal and external communications are required? What are the legal and public relations implications? Ideally, each participant will answer the questions from their own perspective, after which CyberNINES will host a follow up meeting with all participants to discuss their answers. In any case, the exercise and follow-up questions provide a valuable tool that the client can use to tighten their security procedures.
In the end, it comes down to adaptability. “We don’t live in a perfect world,” Streicher said. “There will be breaches, there will be hacks. It’s about minimizing the risk. A company may have an incident response plan, describing the general steps and calling out who is supposed to do what and when; a TTX challenges that plan and puts it through its paces. At the end of the day, the plan needs to be adaptable, and the TTX can really help with that.”
As Zacharski noted, “The only way to harden an incident response plan is to have an incident—and it’s better to have a synthetic incident than a real one.”