Threat modelling at the FT
By Lisa Fiander and Costas K
How we adapted to working fully remote, whilst still delivering beneficial threat modelling sessions
What is Threat Modelling
Threat Modelling is a structured way of thinking how something can cause damage and what can be done to prevent it. People threat model unconsciously when they cross the street or when they decide to install an alarm at their house.
However when installing an alarm in your house, instead of thinking about all possible intruders from velociraptors to ants, it’s appropriate to think of what’s more likely to happen and what can cause the most damage. You can’t successfully defend against everything all the time.
Threat modelling at the FT
It all started when Sarah Wells, our director of Operations & Reliability, gave me a deck of cards called Elevation of Privilege, that she had got from a company called Agile Stationery. The game is introduced in Adam Shostack’s threat modelling book as a great first way to do threat modelling, and it is.
One of the great things about the book is that it’s jargon free. It doesn’t require prompting people with contrived or unhelpful advice like “think like an attacker”. At the FT we have people from various backgrounds and we support a wide range of technology. We want to enable all of these people to build and maintain secure products.
Rolling out to other teams
Introducing this to teams as a new concept was received with great interest. People were fascinated just by hearing that we’re going to be playing a board game, and after that, we are all hopefully going to come out of it knowing more about the system. If anything, it’s a great way to start a dialogue and introduce the teams to each other. It fits very nicely with the agile manifesto’s first value, Individuals and Interactions Over Processes and Tools.
For a Threat Modelling session you will need…
Having your system reviewed by another party, is an inherently awkward and risky process. For starters, those reviewers don’t have context of the decisions you made, and you worry that you’ll look bad. But you need to start somewhere and a diagram of a smaller system is as good a place as any so we asked teams to supply one.
Secondly, we explained how the session would work at a high level and how this differs from standard security checklisting. Checklists can be very effective in a lot of situations and provide an easy self-serve starting point, but a single checklist is not sufficient for the variations of systems that are developed. Instead of providing a “standard security checklist” we decided to offer threat modelling As a Service.
As Adam mentions on his BlackHat talk, we wanted to have a dialogue and really understand what the system is doing and how it was built.
We can no longer all be in the same building
Until March this year, we’d only done this so far in person, in a meeting room in our HQ, with everyone being in the same room. This was clearly not an option once we were all remote working due to the pandemic. Could we run these sessions remotely? Playing a board game remotely for the first time is challenging on its own, let alone if it has a security context.
As well as the physical card deck, Microsoft also offers the deck in a digital PDF format — and this offered us a way round our problem. The cards are exactly the same as the ones in physical form that we had used in the past, so we decided that the best way forward was to use the digital card deck of the Elevation of Privileges game. The key difference here, is that in person the team would have randomly selected cards, however in these sessions, the person leading the threat modelling session will scroll through the deck. This still worked really well, we didn’t see any major impact of this change.
How does this work in practice?
Before the sessions, teams were asked to provide diagrams of the systems that we would be performing threat modelling against, as well as a minimum of three members of their team to ensure that there was a wide range of knowledge of the system. Crucial to this exercise is someone acting as an observer and taking minutes and notes, more on this later.
As threat modelling gains more interest, you need to be confident that you don’t have any key person dependencies on your cybersecurity team running the session, make sure to rotate the roles around the team.
Then we get everyone on [insert your orgs conferencing app] and start introducing teams to one another. At the FT we have found that taking the time to do proper introductions between new teams, makes for a more productive session. Knowing fellow team members’ names and a little about what they do, makes everyone feel a lot more comfortable. Follow up with explaining the purpose of this game. It’s to start a dialogue and get us all collectively thinking about the security and the threats of the system. Sometimes we might want to explicitly mention that this is not a criticism exercise, and it’s for both teams to learn more about the system and how it works.
From then on, the diagram or whatever info you have of the system will serve as your board. A person from the cybersecurity team will “drive”, i.e. present and showcase everyone the card to be played. This is where the fun begins.
So…what does a session look like?
In the session, each card in the deck is played. An example card may be something similar to “Spoofing: An attacker who gets a password can reuse it”. The card is then opened up to everyone in the session. From here, we start to identify where in the diagram there may be cases where password reuse could occur. This could be anywhere from user login portals, to jenkins instances.
To start with, the team may not instantly be open about where this is occurring, but as participants start to trust the process and everyone understands that this is a learning experience for both sides, the teams work together to identify any potential occurrences and agree to check these after the session.
You may also find that some members of the team may be less open to speaking up during the session. Eventually either quieter members of the team begin to participate as the game progresses, or you will need to ensure that everyone has a chance to speak during the session. Having everyone participating makes it more likely to identify potential attack paths that both sides may not have originally thought of.
How to get teams interested
Get them cake or stickers. No seriously it works.
Playing Elevation of Privileges with engineering teams was great, but we still need to address findings and dig deeper into those discussions.
Using a ticketing system such as Jira, we can transform the notes of the session to stories.
This gives everyone concrete goals and actions that they can follow after the session. Although the session ends after all cards are played, this is not the end of the engagement between teams and Cyber Security.
Organise on how you can follow up and have an honest conversation about what issues you’ve faced so far.
Finally don’t forget to send a feedback form right after the session. No session is perfect and you can only learn and adjust, based on your organisation’s culture.
Summary
We’re learning more about the systems that teams build and we’re establishing relationships with everyone across the FT. The teams learn a lot about security and are more comfortable approaching us in the future with either new, existing or complex security problems that they are trying to solve.
