Threat modelling at Adyen

Threat modelling is a tool for enabling the design, development, and deployment of more secure products. It is a collaborative approach that allows teams to gain a better understanding of their system, supporting them in making proactive risk-based security decisions. Common facets of most software-centric threat modelling approaches include:

• Sketching data flows.

• Identifying the attack surface and trust boundaries.

• Listing key assets and assumptions.

• Going through the diagram, using it to brainstorm what could go wrong.

• Prioritising threats based on their expected impact and the team’s confidence in existing controls.

• Determining remedial actions such as redesign or mitigating controls.

• Linking mitigations to testing activities such as penetration testing.

In applying this recipe at Adyen, we have developed and continue to refine specific approaches to spice things up: we focus on the most critical areas of a product, we time-box the activity, we put teams into the right mindset by placing them in an imaginary situation where they attack their own product, and we emphasise the importance of team ownership and understanding. In line with this, we view threat modelling not as something done by an outside expert but as an activity where security experts moderate the discussion and seek to guide teams towards a self-sufficient and self-directed process.

More than helping teams make secure architectural decisions, threat modelling, as a central security technique, allows collaboration on structural solutions to security problems:

It gets people on the same page

First and foremost, threat modelling is a way of ensuring shared understanding through a common language. It gets everyone on the same page by providing concrete conceptual tools for understanding key security concerns. The threat model and the conversations before, during, and after an exercise can bridge boundaries within the team, with other product teams, and with the security team – encouraging knowledge sharing.

It enables risk-based design decisions

When applied early in the product development life-cycle, threat modelling can help to spot design-level flaws and drive informed design decisions. In general, it is cheaper to spot and fix problems during the design phase than to address them once they are out in production. Threat modelling also goes beyond static lists of functional security requirements. By emphasising risks that play a role in a given context, controls can be selected that reduce the impact and likelihood of specific incidents.

At Adyen, we are flexible, not dogmatic: we adopt existing approaches where useful and adapt them to our context. The methods we use and any changes we make depend on the scope of the product that is analysed. We may apply specific techniques to complement ‘generic’ software-centric threat modelling, such as when using sequence diagrams to analyse protocols.

Our flavour of threat modelling is a layering of spices on top of classic battle-tested recipes:

We prioritise analysis through multiple angles

Threat modelling is an open-ended activity. Because of this, it is important to time-box it. With a limited amount of analysis time, we have to direct our attention towards the most important aspects and hotspots. There are different ways to ensure that the most relevant issues are highlighted and prioritised:

• We ask teams to look for and identify the most important data flows, to look at external interfaces in various forms, and to identify the most critical trust boundaries that are (or should be) in place.

• We work top-down, performing a breadth-first search through relevant components, zooming in to those that are deemed most relevant – i.e. we work from low to high fidelity.

• We use assumptions as a way of defining our focus area and for recording the dependencies on other teams, including the things to check with them.

Our approach, although flexible, emphasises data flows, as this is how attackers tend to influence and gain control over a system.

We put development teams in the right mindset

Our philosophy is that system builders generally know (the design of) their systems better than the security team. They can provide valuable insights into what areas can be improved during a product’s development life-cycle and they have ideas about what could go wrong. Our product security experts focus on moderating the sessions, helping engineers to delve for relevant threats by putting them in the right mindset and by prompting them to explore unhappy paths. Where needed, they can also provide subject-matter expertise.

One way to put the development team in the right mindset is to ask them how they would attack their own product if they were to leave the organisation on bad terms. We have found this to be a very effective way of getting engineers to highlight critical areas for further exploration, although the team might need to be reminded to also consider accidents involving authorised individuals.

Additionally, we have found that it is important to tell the team to assume that controls are missing when eliciting threats. Considering the system without countermeasures in place encourages a defence-in-depth approach. It also prevents blocking the threat elicitation process: like in a brainstorming session, we try to prevent early judgement of threats and keep this activity for later.

There are several general challenges when it comes to rolling out threat modelling. The overarching challenge is getting sufficient interest and buy-in from teams, which plays a bigger role in some industries than in others. More specific challenges include:

• Nurturing sufficient security domain knowledge in developers.

• Avoiding the pitfall of doing detailed analysis over timely implementation of mitigating measures.

• Aligning threat modelling with and linking it to other activities in the security development life-cycle.

• Interfacing threat modelling with the rest of the organisation.

• Keeping threat models in sync with changes to an environment with continuous product development.

An underlying aspect to reflect on is the role that contextual factors play in making a threat modelling programme successful, particularly factors relating to societal and company culture. An effective threat modelling exercise requires an open and honest discussion: we have found that our Adyen Formula helps to encourage and enable cross-cultural teams to have productive discussions. A complementary technique is keeping data-flow diagrams front and centre during threat elicitation, focusing the team’s attention.

In summary, while implementing a threat modelling programme has its challenges, threat modelling has proven to be a useful approach for getting everyone on the same page and enabling the building of confidence in products. Note that those launching or evolving a threat modelling effort have many potential sources of inspiration, both historical and contemporary, ranging from the academic to the practical.