Threat Modelling in the Development Pipeline
In software and systems development, the incorporation of security measures from the outset of a project is an imperative. The notion of ‘secure by design’ is achieved through a multitude of processes and methodologies, of which threat modelling is a crucial part.
I recently took part in a threat modelling hackathon, it was a great collaboration experience and also enlightening to see how we look at and identify threats differently. After brainstorming on threats across the spectrum it was using a method which was tried and tested with development teams ‘in the wild’ which allowed us to create a structured approach, which I will talk about, so first off….
What is Threat Modelling?
Threat modelling is a structured approach that involves identifying, understanding, and addressing potential threats in the design phase. It enables developers, architects and anyone involved in the design of software and systems to predict and mitigate potential vulnerabilities before they become a risk to the system.
Threat modelling can, at times, be an arduous task. It requires a meticulous understanding of systems and potential threats, often involving intricate diagrams and dense technical discussions.
However, it doesn’t always have to be this way. When working with 40+ development teams on a project in London, Elevation of Privileges (EoP), a card game designed by Adam Shostack was introduced as a way to really engage teams on security when walking through proposed system designs. It worked really well and broke a lot of barriers between security and development teams. Elevation of privileges brought a unique, engaging, and fun approach to threat modelling, it made it more accessible and appealing to all members of the development and security teams. Gamification of security. Its main objective is to help developers, architects, and security professionals identify potential threats to a system in a structured and enjoyable way.
While it is a card game you can play in person, you can also easily download and run an open source version of the game online, enabling remote development teams to also be involved. I won’t go into detail on how to play the game here, there are many websites and videos on making the best of Elevation of Privileges with teams.
So why threat modelling?
The Role of Threat Modelling in the Development Pipeline
Incorporating threat modelling into the development pipeline can have profound benefits. It enables an organisation to:
- Identify threats early: Threat modelling in the design phase allows teams to discover and address vulnerabilities before development begins. This approach can significantly reduce both the cost and the impact of vulnerabilities found later in the development process or post-deployment.
- Inform design decisions: By understanding the potential threats to a system, teams can make informed decisions about the system’s architecture and design.
- Improve communication: Threat modelling provides a common language for teams to discuss security issues, enabling better collaboration between security experts and developers.
- Drive secure coding practices: Understanding the threats a system may face can guide developers to write more secure code, enhancing the overall security posture of the application.
- Upskill the team on Security: Not everyone has the same level of knowledge on vulnerabilities or understanding of what is possible. Threat modelling with a team educates the whole team and often see team members suddenly realise another element is vulnerable from what has just been described by another member of the team.
A Framework for Threat Modelling
As the Elevation of Privileges game focuses on STRIDE, it is also one framework I have experience with and if you are not familiar it is a great way to begin with your teams. STRIDE is an acronym representing six categories of security threats: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Originally developed by Microsoft, STRIDE helps to bring focus on particular threat areas that teams can concentrate on without being overwhelmed. When threat modelling we will often begin with Spoofing as an area to focus on before exploring other the other categories. It is the ice breaker for many teams, how can I pretend to be something or someone to gain access in this design. Once everyone is stuck with ideas, we move onto the next. So what do the categories mean, let’s look at the focus areas of STRIDE:
Spoofing Spoofing involves pretending to be something or someone else to gain unauthorized access to systems or data. In the context of software, it often refers to faking one’s identity to bypass authentication mechanisms. Tampering
Tampering refers to unauthorised modification of code, data, or system configurations. This could involve changing data in transit or altering an application’s code to change its functionality. Repudiation
Repudiation refers to an entity’s ability to deny an action without proof of the contrary. In terms of security, it involves the ability of a user (legitimate or malicious) to deny a performed action, such as initiating a transaction or changing a configuration setting. Information Disclosure
Information Disclosure involves the exposure of information to individuals who are not supposed to have access to it. This can occur through various means such as unencrypted communication, insecure storage of sensitive data, or exploitation of software vulnerabilities. Denial of Service
Denial of Service (DoS) is an attack aimed at making a system unavailable to its intended users. This can be achieved by overwhelming the system with traffic or exploiting a vulnerability to cause a system crash.
Elevation of Privilege Elevation of Privilege (EoP), the same name as the card game I mentioned previously, involves gaining elevated access to resources that are normally protected from an application or user. This can allow a user to perform actions they are not authorized to do, such as accessing sensitive data or performing administrative tasks.
Making Threat Modelling a Success
So how can you make threat modelling a success in your teams:
Train the team: The team should be trained to understand different threats, vulnerabilities, and the methodologies used to identify them. As a development team walking through the OWASP Top 10 with the team and explaining the attack vectors is really helpful. Break it down into brownbag lunch and learn sessions, get development teams involved so education is not all led by security teams. Also Elevation of Privileges is great way to do this by example and often security can help to lead in this area with helping to explain concepts.
Create a culture of security: A security-conscious culture should be nurtured within the organisation. This involves making security an integral part of the development process rather than an afterthought.
Use the right tools: Numerous tools and methodologies can aid in threat modelling, including Microsoft’s Threat Modeling Tool, OWASP Threat Dragon, and methodologies like PASTA (Process for Attack Simulation and Threat Analysis) and STRIDE.
This is just some ideas on implementing threat modelling with your teams.
The beauty of threat modelling lies in its ability to be both a technical and collaborative process. With methodologies like STRIDE, teams can focus on specific threat areas and address them systematically. However, it is the element of collaboration, the coming together of minds, that truly drives the success of this process. The Elevation of Privileges card game epitomises this aspect, transforming the potentially arduous task of threat modelling into an engaging, team-oriented, and even fun activity.
Incorporating threat modelling into the development pipeline is not just about enhancing the security of a system. It is about fostering a culture of security within the organisation, improving communication among team members, informing better design decisions, and driving secure coding practices. It is also an excellent opportunity for upskilling the team, enhancing their understanding of vulnerabilities and potential threats.
In the grand scheme of things, threat modelling, in its many forms and methodologies, is a testament to the proactive, forward-thinking mindset needed in today’s digital landscape. Whether it’s through playing a card game or using a complex tool, the ultimate goal is to create software and systems that are not just functional, efficient, and user-friendly, but also secure by design. After all, in our increasingly interconnected world, security is not a luxury, but a necessity.
Where do we start, if you haven’t really put together a complete threat model for a system a good way to learn is to join one the Threat Modelling Connect community. Regular hackathons are run which allows you to work with teams across the globe and pull together a comprehensive threat model. I really enjoyed the Spring 2023 event and the winning teams threat model was really insightful and diversity of the models created showed that at the moment there is no standard of how the output is expected to look.
It would be remise not to mention where all of my threat modelling curiosity stemmed from, Adam Shostack, who I mentioned earlier is for me and many cybersecurity professionals the guiding light and mentor on how threat modelling is done well. Adam has a number of books available to help you and your teams get started, and if you like StarWars you are in for a real treat with his latest book ‘Threats: What Every Engineer Should Learn from Star Wars’.
Threats: What every Engineer Should Learn from Star Wars