The Threat Scenario is the heart of the risk assessment process, because it pulls together and focuses the three components of Impact, Vulnerabilities and Threats. When performed individually, the three components can yield a daunting set of information. For example, identifying and prioritizing the Threat sources to a large organization can yield an almost infinite set of possibilities. The Threat Scenario simplifies this process by focusing on high Impact processes, significant Vulnerabilities and meaningful Threats. For example, in the course of identifying the Controls for a process you may identify a Vulnerability (an application shows the password in clear text on the computer screen when the employee logs in). When viewed on its own, the Vulnerability appears significant - passwords should never be displayed in clear text because it increases the likelihood they will be viewed by unauthorized persons. But is this Vulnerability so critical that it would require expenditure of significant resources to immediately correct the defect? A Threat Scenario would be used to dimension the level of risk created by this Vulnerability - who are the likely Threat sources, what level of privilege is achieved if the password is disclosed, how important is the application to the process, etc. Is there a scenario, a combination of factors, that yields an unacceptably high level of risk to the organization? Is the application significant or just a simple low-risk spreadsheet used by a limited group of employees? Can the application be accessed by a large number of Threat sources (i.e. is it available on the Internet) or does it reside on a computer with no network access? Even if the application is important to the organization and it is available on the Internet, does the password only give access to a function with a low privilege (the password grants access to a menu, but a further, more secure log in, is required to access any of the functions on the menu).
In conducting training on Threat scenarios, I have found that most people find it difficult to develop credible, detailed and meaningful Threat Scenarios. The reason is simple - the normal reaction when confronting a problem is to try to find a way to improve the situation. A Threat Scenario asks you to think about how to make things worse. For example, using the hypothetical above, most people would likely develop a scenario that showed there was minimal risk, because a further log in is required to access the menu functions. The problem is, in performing a Threat Scenario you have to think like a crook, assume the role of someone who wanted to exploit the Vulnerability to inflict maximum damage. You want to find ways to break the system, not secure it. If you were a "crook" and were confronted with a second log in on the menu screen, would you give up? No. You would assume (correctly) that most people are lazy in their use of passwords and that it is highly likely that the password selected by the employee on the initial log in screen where the password is displayed in clear text is the same password used for the menu functions. My advice - when creating Threat Scenarios try to suppress the natural tendency to find something good in everything. Instead, turn to the dark side. Think like a crook.
As an alternative, the next page deals with using Attack trees as a way to systematically structure your Threat Scenarios.
©2009 ISRMC, LLC