Threat Assessment

Find out as a team what are really the threats for your project.

Your development team has an understanding that software security is important for your organisation, and that it is something they can affect. 

But how are they to do that? 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 usually 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)

For the Developer Essentials package we use a brainstorming approach, as follows. To run it requires only the ability to facilitate a group of people working together – a skill many people can claim.

Brainstorming requires one member of the team to act as facilitator. The team sits in chairs in a circle facing each other and a flipchart (or whiteboard). The facilitator writes a question to focus the discussion, along the lines of ‘what threats do we face’. Then everyone suggests possible threats – without analysing each or attempting to filter out any of them. As they do, the facilitator writes down each threat (whether sensible or not) on the flipchart. There’s more about brainstorming on the web – for example here. 

As ways of generating idea, it’s helpful to 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. Similarly looking at at the architecture of the system in detail, concentrating particularly on interfaces between systems and components is a further excellent way to find threats. 

From the flipchart, the team creates a document listing each of the threats: the attacker, what they might get from it, how they might get it.

If you have a little more security expertise in your team, then we recommend considering the ‘games’ Protection Poker and Elevation of Privilege. These both use rather more security jargon, and will need someone with the knowledge to explain them. 

Or consult Adam Shostack’s book ‘Threat Modelling’ for a more in-depth discussion of all the possible approaches. 

The Threat Assessment session is worth repeating every year or so in a project. Whether or not it finds new threats, the discussion can be very helpful to show team members who knows what about security aspects:

I think it got everyone talking about security a bit more, especially within our team... There were a lot of security things going on that I didn't know about.  But other people knew that they were happening (Tester, Large company team)

It’s always difficult to think of everything, and you may be able to find useful prior work. Larger organisations may have existing generic threat models for applications of your kind in your industry; some have used the ISO/IEC 27005 standard (or former UK IS1). Or you may find appropriate discussions for your specific architecture or industry, such as CESG’s ‘Architectural Pattern’ work.