Threat modelling is a way to identify the potential security flaws in your system, and prioritise mitigations. On Monday I attended a session comparing some card games you can use to help you, at SPA conference. This is a brief write-up.
There are various ways to do threat modelling, for example the National Cyber Security Centre (NCSC) recommends attack trees.
Security cards are a way to help a group think laterally about the problem, and bring up ideas and discussion of potential security flaws that might not have come up on first thinking about it. They can also be a way to engage everyone in the team with the problem.
The idea of this conference session was to compare three such card decks to see what kinds of insights they generated.
The session was run by Charles Weir, Lucy Hunt and Shamal Faily. They had documented a basic banking application with a simple architecture diagram. We then used one of the three card decks to generate potential security issues with the application. After ten minutes we swapped to another card deck, and then the third. The three groups each used the three decks of cards in a different order.
At the end of the three games we spent a few minutes dot voting on the issues we’d identified – black dots for the most important, red dots for the most interesting.
Each of these decks were quite different with different activities involved.
The Elevation of Privilege cards are very technical. They outline something that might happen, divided into the six areas in the STRIDE framework. For example, one card is titled “Spoofing” and reads “An attacker could squat on the random port or socket that the server normally uses”.
The actual game involves placing cards on the diagram to indicate where in the architecture the situation described on the card could be a problem, but for our shortened version of the game we were to indicate what situation was present for this to be a problem.
All the cards were more or less that level of technicality, requiring a fairly high base level of architectural knowledge and understanding of security terms. It would be hard to imagine playing this game with the product owner or even junior engineers.
It did however prompt some advanced thoughts and useful discussion about what security flaws there might be in our system.
This was the second game our group played and was very different. It had cards about human impacts (e.g. “Societal wellbeing”), cards about Adversary Motivations (e.g. “They are incompetent”, “They need to influence politics”), cards about Adversary Resources (e.g. “They live in tomorrow’s world”).
You play this game by first understanding what you are protecting (the impact) and then getting into character as one of the adversaries, and then using the resources to see if that affects how you think about that persona. The end goal is to identify the top three personas who are most likely for your organisation and then identify what and how they might attack your system.
As for all the games, we didn’t play the full version in the session. Instead, we talked about the personas and impacts and used that discussion to identify some potential issues.
This one generated some really interesting discussion, and people with less technical or security experience were able to get fully involved.
This was the third game we played, and after the other two it was very odd. Each card in this game has A LOT of information and suggestions. For example, a card headed “Technological Attack: Adversary’s Methods” reads:
What kinds of technical attacks might the adversary perform over an analog or digital link? How would this enable or amplify an attack on confidentiality, integrity, or availability?
Example Related Concepts:
Coming straight after Adversary Personas, which had really encouraged unbounded thinking, it was hard to engage with these cards at first. With the above one, for example, it lists quite a lot of the potential answers, which doesn’t feel very motivating to come up with more.
The activities for these cards are different to the other two sets and they can also be used for education rather than for securing a particular system. It seemed like they might prompt good ideas for a group less familiar with security concepts, and we did generate quite a few potential issues from them.
When coming together and looking across the three groups at the end of the session, the interesting thing was that each deck of cards, regandless of the group or the order, had generated roughly the same number of black dots, i.e. important security issues to address.
However, in all groups, the Adversary Personas had generated the most red dots, i.e interesting issues raised.
I found this exercise really interesting. All of the decks of cards prompted the group to think outside our default ways of thinking, so I would advocate using a deck of cards as a supplement to any threat modelling session I was doing.
Which deck I would want to use would depend on the context, e.g. the technical understanding of those taking part, what other methods we were using, whether the priority of the session was to identify new risks or gain a collective understanding, etc.
Other security cards are available, for example protection poker.
And other threat modelling methods are also available! This a useful summary.
Charles, Lucy and Shamal plan to write up a more detailed blog post with the outcome of the session, which I look forward to reading.
If you’d like to be notified when I publish a new post, and possibly receive occasional announcements, sign up to my mailing list: