F5’s executive leadership got an urgent message: a malicious actor within the company was sending confidential information to a third party that could put customers at serious risk. We immediately formed a combined response team of technical cybersecurity experts, executives, and business process stakeholders. Working together, we began to gather information about the nature and scope of the threat so we could assess the situation and determine what our next actions should be. The decisions we made over the next few hours could be critical to the future of the company.
By now any F5 PR people reading this are probably having a panic attack, so I’ll pause here to say that this was not an actual cybersecurity incident: It was a tabletop exercise that my team and I developed to simulate an actual security incident in real time.
Why a Tabletop?
We had several goals for this exercise. One was to run my technical team through the drill to validate and develop the roles, responsibilities, processes, and levels of decision-making authority we’d established for incident response. Another goal was to teach the less technical, more business-focused F5 stakeholders how to think—and communicate—the way cybersecurity professionals do.
Revenue, reputation, and customer trust all depend on how well the business and technical sides of a company work together. As Chief Information Security Office (CISO) for F5, my challenge is often having to communicate how technical risk translates to business impact. Much more than any memo or presentation, one of the most effective ways to help a business leader see the connection between technical risk and business risk is to let them experience firsthand what can happen if things go wrong.
Business Risk vs. Technical Risk
What’s the difference between business risk and technical risk? Put simply, a business risk is an uncertainty that can limit or threaten the viability of a commercial business. Such risks can be external or internal—anything from supply chain issues to changing customer preferences, or an executive’s behavior on their personal social media account.
A technical risk is an uncertainty that can cause limitations or failures in the functionality and performance of technology. These risks include complexity, integration with other products, and service outages.
The Known Exploited Vulnerability (KEV) catalog maintained by the Cybersecurity and Infrastructure Security Agency (CISA) is a good example of how technical and business risk intersect. If a product is on that list, customers who purchased it need to upgrade or patch it to reduce the likelihood of compromise by known threat actors. From a business risk standpoint, a vendor's appearance on the list represents customers' investment in time, energy, and money—which has an impact on that customer’s business, as well as on the vendor's reputation, share price, and revenue.
Why Your Business Stakeholders Need to Think Like Security Pros
Over the past few decades, business leaders have had to become technically savvy. They can’t just leave those details to technology specialists—not in today’s world, where increasingly apps are the business. In the coming years you can expect to see most companies including cybersecurity in their top five risks to the enterprise. The impact of security on the business will become so pronounced that the distinction between “business” and “technology” will become as hazy as the distinction between “personal” and “work” devices.
You can see this shift at the level of government policy. The Securities and Exchange Commission (SEC)—an independent agency of the United States federal government tasked with enforcing the law against market manipulation—recently proposed new disclosure rules for public companies. These new rules include the role cybersecurity plays in a company’s strategy, financial planning, and capital allocation; how frequently the board discusses cybersecurity and the processes by which it is informed; whether a company has a CISO, and that individual’s expertise and company reporting lines; and the cybersecurity expertise of individual directors.
Also, since taking office, President Biden has signed two executive orders on cybersecurity. Executive Order 14028 focuses on the security and integrity of the software supply chain. While Executive Order 14017 seeks to secure critical supply chains for four key product sectors against numerous threats, including bot attacks.
Game Day
As we huddled in F5 Tower discussing how to respond to our fictional incident, my role was to present business leaders with information and options so they could get firsthand experience making business decisions informed by the risk analysis the technical team was conducting in a separate conference room. Had this been an actual incident everyone would have been together in the same room. For the tabletop we kept the technical team separate because we wanted to give the business folks breathing room to talk through the issues without getting too bogged down in the weeds from a technology standpoint. We also would have had a project manager present to run the entire process, but for the tabletop our lead investigator pulled double duty.
For two hours the technical team used their expertise to run down answers to questions from the executive and business process teams. I used the information they gave me about the technology issues involved to help the business side evaluate both the business and technical risks that certain actions might introduce. Representatives from Legal and HR ensured that we stayed compliant with regulations. Comms made certain that what we decided to communicate to customers, partners, and the media would accurate and informative without revealing sensitive information that might increase the risk.
The tabletop ended with a presentation to the executive leadership team of the gathered facts and planned actions, plus decisions the executives would need to make about how best to address the incident. One exec told me later that the exercise helped him realize how many key decisions leadership would need to make in a very short amount of time during a real cybersecurity incident.
This was not an actual cybersecurity incident: It was a tabletop exercise that my team and I developed to simulate an actual security incident in real time.
Conclusion
In the end we accomplished our goals and discovered ways we could improve the exercise for the future. If you’re thinking of running a similar tabletop in your organization—and I highly recommend doing so—I think the most important elements are making sure the right people from the business side are participating, and crafting a scenario that connects business and technical risk in ways that make the participants think differently than they’re used to. It might be a malware outbreak that impacts the ability of Sales to operate in a region, or an ominous Twitter post by a cybersecurity influencer that’s sending ripples of uncertainty through the industry (and possibly the stock market).
If you’re a business leader who isn’t sure a tabletop is worth the time and energy, here’s some hard-earned wisdom from the trenches: it’s better to learn about the business impact of cybersecurity when it’s a hypothetical exercise, not the top story on global news.
