Risk and Cost Assessment

Assess your threats for both impact, and cost to mitigate.

Once you have a list of credible threats to your system, you will have a better idea what are likely to be the security requirements. 

A common misconception is that it is the programmers’ role to make security decisions. This is wrong. Implementing security improvements of any kind costs effort and usually money, and decisions about resources are very rarely for the developers to make. Typically, all but the most trivial security decisions will need to be made by the Product Manager – the person who decides how to allocate resources to development. The task of addressing each security threat then enters the project workflow just like any other task, such as functional enhancements and functionality bug fixes.

Developers don't fix security; issues, tasks, epics and stories do! (Johanna Curie, AppSec Europe 2018)

Fortunately, balancing risks against costs is a normal part of a Product Manager’s role, and they are all trained to do exactly that. To make informed decisions, though, they will need more information:

1. The likelihood of each threat,

2. The impact on the organisation if an incident occurs and

3. The cost of addressing (mitigating) the threat.

In the Developer Essentials package we tackle this in a workshop that follows the Threat Assessment. We recommend making it a separate session (or at least, after a break), since the analytic type of thinking involved is different from the brainstorming in the previous section.

In this workshop, the threats are written up on a list – usually on a display screen. The participants address each in turn, perhaps by voting on which ones look most important to address first. For each, they estimate:

1. Likelihood: Low, Medium or High

2. Impact: Low, Medium or High.

Obviously, these will be relatively inaccurate assessments: the aim will only be for finger-in-the-air accuracy. If the workshop can involve a Security Specialist, they may have helpful knowledge about likelihoods of different threats, and possibly even typical impacts. 

And then, taking the threats with high impact or likelihood first, the team identifies possible mitigations – possible things we can do to deal with the threat. Some mitigations may be in code, or changes to functionality; others might be processes, discussions with other teams, or even preparing a plan for dealing with a successful attack. They then estimate development costs for each using the same process as estimates for any other piece of development (story points, for example).

During this workshop, it’s important to consider some of the other techniques described in this book. These three are particularly important:

• Security Negotiation,
• Component Choice, and
• Automated Static Analysis

Both are good ways to mitigate some kinds of threat – though they may or may not be appropriate in any given case. 

Some organisations may even have professional Risk Assessors, who can support this even better. Or you might chose to have a smaller group of people making these assessments. 

As an example of a threat model and mitigations, here is a practical Threat Model from a past project, showing all these as a table. Observe that the descriptions of both threat and mitigation are very short: the minimum sufficient for the developers who know the product well; at this stage there are no cost estimates.