You have completed an incentivisation event. Your developers have, however temporarily, an understanding that software security is important for your organisation, and that it is something they can affect.
Your developers’ next question will probably be: how? To answer that, we recommend you first lead your developers to a different question: not how but what? What should we be worried about? What is likely to hurt us, and how might it happen? If it involves external attackers, what do they want, how might they go about getting it and how much do we care?
Finding the answer to those questions is called ‘Threat Modelling’. It is essential for any project involving security, but is not yet common practice:
“The first conversation is with the [development team] manager to ask “what is the threat model”. There is a lot of things you can do in your head to guessimate how bad things are going to be and none of them are fool proof. But when you ask that question and the person in charge of the project says “that is an interesting question, I’ll have to think about that,” you think, this is going to be interesting. But that is not at all uncommon.” (Secure Development Consultant)
So how are you to run a Threat Modelling session? Once again you have several options to consider: a Threat Brainstorming Session, or the ‘games’ Protection Poker and Elevation of Privilege. None require a security expert to run them, though all will be helped by having security experts involved. More important, though, is the ability to facilitate a group of people working together – a skill many people can claim.
Who should be involved? Most important is the developers in the team – the session itself is an essential learning experience for the developers themselves. Remember ‘developers’ includes testers, project managers and designers: they all contribute to the security of a product. It is excellent if a security expert can also be present, and ideal if the product manager is technically-minded enough to take part as well.
The following section describes the brainstorming approach, but feel free to use either of the others instead.
Arrange the team in chairs in a circle facing each other and a flipchart (or whiteboard). Write the question, along the lines of ‘what threats do we face’. Have everyone suggest possible threats – without analysing each or attempting to filter out any of them. As they do, write down each threat (whether sensible or not) on the flipchart. There’s more about brainstorming on the web – for example here.
Consider also who might be the attackers – what would they want and how would they go about getting it. That may generate a different set of possible threats. Look at the architecture of the system in detail, concentrating particularly on interfaces between systems and components. Look for threats based on them.
Then have the team discuss each suggestion in turn. Is it viable; what might be its impact? Filter out those that are credible, and create an initial threat model document with a list of these credible threats.
Once you’ve used the Brainstorming Session, or one of the game approaches, you’ll have a list of credible threats to your system. What do you do with them? For the next step, we take the list of credible threats, and figure out what we can do about them. We suggest a two step process:
We recommend doing this in a separate session (or at least, after a break), as the analytic type of analytic thinking involved is different from the brainstorming in the previous section.
Importance: For each threat, we identify, on a scale of low to high:
We can think of the importance of the threat as the combination of the two.
Mitigations: And then, for each threat, identify 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.
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.