Do You Know Your Enemy?

You need to find out as a team what the threats really are for your project.


Once your development team has an understanding that software security is relevant for your organisation, and for them, you need to address how to go about making a difference.


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)

Developer Essentials: Threat Finding

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 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 flip-chart (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 flip-chart, the team creates a document listing each of the threats: the attacker, what they might get from it, how they might get it.

Alternative Approaches to Threat Finding

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. 

Some Other Thoughts

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 work which already exists.


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.