Scenario planning is one of the most underutilized techniques in security. Which is surprising given how effective it is in [good] corporate strategic planning and enterprise risk management. In its simplest form it provides a narrative structure to discuss potential future events (good and bad) and to project what reasonable steps should then be taken. This includes what early signals or triggers to watch out for that might indicate such a scenario is starting to happen.
More advanced adoption entails building a full library of scenarios that are both qualitative (structured narrative) as well as quantitative (using a variety of modeling techniques). Many financial organizations use such scenario approaches to model what capital reserves are needed and to determine required capital under stress tests.
Scenarios, even in their simplest form, are useful management and Board communication techniques to illustrate strengths and weaknesses, and hence the need for further investment. The more compelling and story-like a scenario is the better, some of the best I’ve seen look like a post-mortem incident analysis (used as a pre-mortem). Once you get going it’s easy to construct a rich library of these. One organization I know has well over 100 such scenarios regularly maintained and quantitatively modeled.
There are two major types of scenarios to consider:
Micro: scenarios that specifically affect your organization and how you respond. This could be anything from security incidents (caused by internal or external actors), outages, software errors, weather events, vendor issues, cloud resilience events, failed projects, and so on.
Macro: scenarios that effect your overall business sector, geography, product-line or customer base. This could be anything from macro economic shifts, geo-political factors, pandemics, environmental (long term and short term), step-function changes in society, rapid technological change or anything else that shifts your wider landscape.
You can develop these scenarios in the same way, using the same processes, elements and techniques but in reality they are used in different ways. The complex dynamics of how the broader macro scenarios might effect your business sector have many second and third order effects to consider depending on how your competitors respond. Similarly, in security terms, this may also model how threat actors collectively respond to structural changes in defense that impacts their incentives and economics. So, scenario analysis in many ways is the beginning of a multi-stage game.
If you are sufficiently early in your scenario planning you can address a broader scenario as if it were just affecting you with more force and priority and be ahead of your competition as a result. This can even apply in terms of threats. If your defenses are always 12 months ahead of most organizations in your sector (even small increments) then it might never be economic for attackers to focus on you if they have broader easier pickings across the vast majority of your competitors. Note that this doesn't preclude the necessary shared defensive approach of working together with competitors for the good of all.
To give you a real example. Around 2003, my former team and I did a scenario planning exercise to look at the technology / cyber-threat outlook of the future. We constructed 3 scenarios:
Digital Nirvana: a world where technology stayed ahead of the threats, where governments around the world cooperated to keep threats at bay and a whole host of other positive things - hence the title.
Death Race 2010: the world was projected to be getting significantly worse, digitizing ahead of the capability to defend, threat actors becoming more aggressive and sophisticated - including nation states. Everyone was going to feel lots of pain.
Muddled Middle: as the title gives away this was a mix of the two, essentially that we were going to see more threats but didn’t need to take drastic action to keep within a reasonable risk profile.
Over a 2 day period we explored the hypotheses around each of these scenarios, looked at early warning triggers, and projected out courses of action and consequences of each scenario. Now, you’ll probably find it obvious we decided that the scenario likely to play out was to be Death Race 2010 given what we now know (nearly 18 years later). In 2003 this, especially the role of nation states, was not thought to be that obvious. Having picked this scenario we (with tremendous support from our surrounding business and technology leadership) embarked on a multi-year program of accelerated infrastructure hardening ranging from much more aggressive vulnerability identification and remediation through to more radical (at the time) approaches of desktop virtualization / thin client technology, highly aggressive web / e-mail controls and least privilege access rights for end users and a whole series of similar mobile device controls.
This was an example of macro scenario planning, that is projecting a range of possible futures and attempting to prepare for them, or at least noting early warning triggers that let you adapt quickly. The use of micro scenarios is equally valuable as a means of talking about specific events that might occur, like a data breach, and using a similar narrative structure to be able to reason about the current levels of mitigation and preparedness. In my experience, even if the macro or the micro scenarios are backed by a degree of quantification (as they should be) it is ultimately the narrative structure that causes a much deeper level of engagement with a wider variety of stakeholders.
When doing scenario planning, of either variety, you can’t just develop scenarios and file them away - it is crucial they are living structures inside a continuously refreshed risk management framework. Such an approach is pictured below.
Use your risk taxonomy and risk inventory to show where you have gaps in prior scenario coverage as well as using current events (incidents or near-misses) to drive scenario selection. For example: the risk of a malicious data breach from a trusted insider.
Scenarios that are too broad tend to be hard to use for practical risk management purposes. Similarly, scenarios that are too specific lead you to having too many scenarios to manage effectively. Selecting a scenario that applies to major grouping of business assets, products, or services works well. Other selection criteria can be geographic or customer segment based. For example: the risk of a data breach from a trusted insider in Business Unit A’s X and Y products.
Describe the full extent of potential impacts from losses, reputation, regulatory, long term customer impact as well as the impact of handling / recovering from the scenario.
Define the steps that you will take in response to the scenario happening as well as in advance to prepare improved mitigations.
Gaps and necessary future mitigations.
What metrics / limit adjustments are needed to drive that or hold the line on current mitigations.
Hedging activities (e.g. insurance).
Identified triggers (internal or external depending not the scenarios).
Plans, playbooks and drills to deal with emergence or an actual event.
Customer supporting activities, depending on the scenario.
Bottom line: macro scenarios are useful to shape your broader strategy and prepare you to respond to the worst case by pre-planning what triggers to look for. Micro scenarios are useful as a narrative means of communicating, to various stakeholders, your state of preparedness. Both approaches are complementary and are a lot more interesting to develop and use than bland styles of risk assessment, although, those can sit behind the scenes to provide underlying rigor.