Threat Modeling vNext for the Business Decision-Maker

Welcome to the new installment in the Threat Modeling vNext series.

We have gone through a lot, starting from what Threat Modeling is and identifying the problems practicians are facing, providing simple, proven recommendations to address them. We have discussed the importance of flexibility and how different roles may look for different things out of Threat Models. We have learned that experts and beginners have very different needs and that Threat Modeling is not only for security experts. On the contrary, it may provide a lot of value to other roles, including Project Managers and Product Owners, who may benefit from a Threat Modeling experience fully integrated with their Tracking tool of choice.

Today we will further develop those concepts by introducing a different role. Please meet George, who represents the impersonification of the last example we are going to cover on those screens: the Business Decision-Maker. As such, George has little knowledge about Threat Modeling and other technicalities, and quite frankly, he has no time to spare on them.

With an already filled schedule, George has little patience for indefinite information. What matters to him is to understand if the risk is acceptable and, if not, how to achieve acceptability. Of course, simple situations should be handled by the team autonomously: when mitigations are cheap and have no negative consequences, why bother him? But if the cost of the fix is comparable with the potential loss due to a vulnerability, or when it has a significant impact on the usability or operation costs, then a decision is in order.
Now, put yourself in George’s shoes: imagine that some security expert provides you vague information like “this is a Critical issue” with no clear indication of how it is so and what that practically means. Imagine that the same expert generically refers to usability or operation costs deriving from the implementation of the mitigations he proposes, without providing any measure of them. How easy would it be for you to make a choice?
For more technical-focused people like the average Security Expert, achieving the highest security possible is typically the only goal. As a result, we tend to stuff our communications with details, to provide all the information we deem necessary to grasp the specifics of threats and related mitigations. Doing that would be a mistake because it would only dilute the information required by the Business Decision-Makers with unnecessary details. Where we see only a security risk and nothing else, a Business Decision-Maker would recognize the loss due to an event that may or may not occur, but also the impact on the Business that will be determined for sure by the mitigations we are proposing. On top of that, a good CxO would also consider other essential aspects, like the potential legal and social implications of the proposed mitigations. Having to deal with so many angles for any decision, makes Business Decision-Makers impatient towards the most enthusiastic of us, who want everyone to grasp all the tiny details of their work.

Moreover, a wise Business Decision-Maker knows also that Security Experts may be biased. Let’s be frank, have you ever been asked in your life at least once to push a service or a product? Of course, you have, and you may have decided to follow up on that request because it made sense at the time. There is nothing wrong with that, provided that it is still an ethical choice because what you recommend represents a reasonable answer to the risk you have identified. Some of us go beyond this understandable and reasonable bias, and behave unethically, proposing products or services that are not required, or that may even increase the risk. This unethical behavior is unfortunately not unheard of, even if relatively uncommon, so much that organizations like (ISC)2 have defined a Code of Ethics they impose to all their members. If you wonder, as a proud (ISC)2 member, I wholeheartedly adhere to that code.
Another common reason for bias is the misguided convincement some of us have, that to secure a solution, you have to implement all possible mitigations, in the hope that this will close all the possible doors and thus make the solution impermeable to most attacks. To force the owner of the solution to do so, they would classify all their findings as Critical or Highly Severe. That would be a mistake: in fact, not only the customer would be forced to waste the few resources it has, but this would also demonstrate that the findings provided are not trustworthy, undermining the Threat Model as a whole.
In any case, this unfortunate situation forces an increasing number of Business Decision-Makers to adopt a skeptic approach. It is our responsibility to provide credible findings. We have already discussed how to do that, for example in article Quality for Threat Models (cont’d).

Now that we have credible Threats and quality Mitigations, how can we express the risk and an evaluation of the potential impact of the proposed mitigations to the Business Decision-Maker? If you are a faithful reader of the Threat Modeling vNext series, you may have already guessed: by using a Quantitative Risk Analysis methodology like FAIR, of course! Again, this approach may not be entirely suitable for the significant amount of Threats and Mitigations identified during a typical Threat Modeling exercise, but stay tuned because things may change in the future. So, what could we do? The next best thing would be to show simple summary information, like the distribution of the severities for the Threats. If you have various Critical severity findings and they are credible enough, then the risk would be very high, so much that even the installation of the assessed solution in Production should be reconsidered.

Another useful graph for the Business Decision-Maker would be a representation of how the Residual Risk changes with the implementation of the Mitigations as part of the Roadmap. You’ll recall that we introduced some ideas on how you could calculate it when we discussed Threat Modeling vNext for the Project Manager.

Our George may also have another responsibility: he may be involved in the Exception management process, which would be required to handle those situations occurring when for a reason or another, it is not possible to achieve acceptable risk. This is typically a situation that occurs for a limited time, after which the implementation of some mitigation would be brought back to an acceptable state. Still, there is a situation which may last months, where the risk would not be acceptable. When this occurs, someone must accept the risk for the Organization, and the said risk must be tracked so that it is not left unchecked for more time than strictly required. Sometimes, it may be necessary to require the implementation of some compensating security control, to limit the risk in the short term. An example of that is represented by Detective and Corrective Controls. When Preventive Controls are not feasible in a short time for some reason, then implementing other mitigations even when they are less effective in controlling the risk, like a specialized monitoring function, may represent the next best thing. Threat Modeling vNext would mean for George to have an integrated experience that would allow him to express his evaluation about the risk, eventually allowing him to accept with conditions or to reject the exception request. The solution needs to track George’s decision as required by the Organization, supporting the necessary follow-ups and checks to ensure the effective implementation of the required mitigations when the time comes.

We are at the end of the article already. Much has been said about how a role who would not typically benefit from direct access to a Threat Model would instead need direct exposure to it, even if in a very personal and specific way. But a lot more still could be said and done, to provide the Business Decision-Makers the value they need to take their decisions out of a Threat Model. Quantitative Risk Analysis is only the tip of the iceberg. Indeed, Threat Modeling needs to be evolved to cover the needs of Organizations around the globe nowadays, and this is the reason why we have Threat Modeling vNext.

Next week we will further investigate this need, discussing why we need a single tool to provide all those features, instead of dedicating multiple specialized tools for each role.

Meanwhile, happy Threat Modeling to all!