Fortifying Product Security with Threat Modelling
How can you be certain your product is protected from potential attacks, without compromising functionality or performance? Threat modelling may have the answer.
Written by Keith Batterham
As a product owner, you are responsible for delivering a product that meets the needs and expectations of your customers, while also ensuring that it is secure and reliable. Security is not just a feature that you can add on later; it is a fundamental aspect of your product that affects its quality, usability, and reputation.
However, security can also be challenging and complex, especially in today’s dynamic and evolving threat landscape. How can you be certain that your product is protected from potential attacks, without compromising functionality or performance?
One way to approach this challenge is to use threat modelling, a process that helps you identify, analyse, and mitigate the security risks associated with your product. Threat modelling is not a once-off activity; it is an ongoing practice that should be integrated into your product development lifecycle (PDLC), from the design phase to the deployment and maintenance phases.
The benefits of a structured approach
By embedding threat modelling into your PDLC, not only will you gain a deeper understanding of your product’s architecture, components, data flows, and interactions with external entities, but you’ll also be able to:
- Identify the most likely and impactful threats to your product, based on its attack surface, vulnerabilities, and trust boundaries
- Prioritise and rank the threats according to their severity, likelihood, and impact
- Determine the appropriate countermeasures and mitigation strategies to address the threats, based on your product’s requirements, constraints, and trade-offs
- Communicate and collaborate with your stakeholders, developers, testers, and security experts on the security aspects of your product.
In this way, threat modelling can help you improve your product security by:
- Preventing or reducing security incidents by proactively identifying and resolving potential weaknesses in your product before they are exploited by attackers
- Fostering a security mindset among your team members and stakeholders
- Saving time and resources by focusing your security efforts on the most critical areas of your product, rather than wasting them on irrelevant or low-priority issues
- Enhancing your customer satisfaction and trust by delivering a product that is secure by design and by default.
Taking it step by step
You might look at this and think, “But isn’t that just common sense?”. That’s exactly our aim, though – we want application and product security to be demystified and consumable. There are many different methods and tools for threat modelling, but they generally follow a similar framework:
1. Break your product down into its essential elements
This can be based on your use cases, entry points, assets, and dependencies. Wherever possible use diagrams or models to visualise and document these elements, remembering to include ‘gives’ (things you pass onto other systems) and ‘gets’ (things other systems pass to you), along with how these are trusted.
2. Determine and categorise the possible threats to your product
You can use various techniques to generate and classify threats, based on your product’s attack surface and vulnerabilities. One technique is STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege). There are specific tools you can use to do this (e.g. Threat Dragon and IriusRisk), but there is nothing wrong with starting off with standard productivity tools that allow you to create tables.
3. Prioritise and rank these threats
Ranking these threats can be done according to their risk level, which depends on their severity (how much damage they can cause), likelihood (how probable they are), and impact (how many people or systems they can affect). Don’t forget to also include the type of risk and the potential cost if this were to happen.
4. Decide how to address these threats
You can use various strategies to mitigate the threats, such as implementing security controls (e.g. encryption and authentication), applying best practices (e.g. input validation and error handling), or changing the design or architecture of your product to reduce the attack surface. You need to balance the effectiveness of the countermeasures with their cost, complexity, and impact on your product’s functionality and performance.
Get the whole team involved
If you want the best results for your threat modelling exercise, it’s essential that you involve your whole team. A recurring problem we see time and time again at Ekco is where the companies we work with regard threat modelling as just an engineering initiative. This means that important elements can be pushed into the backlog and not correctly prioritised if they lack business context.
To address this, it’s key to avoid overwhelming people with technical jargon. Rather start with questions like, “With our product, is it possible for someone or something to do X? (then describe spoofing, for example.)”. This can then be followed by:
- If the answer is yes, what could you do about it?
- If the answer is no, explain why it’s not possible.
By engaging in this kind of exercise, the wider team gets to understand how the product really works. The product owner also gets a comprehensive view of the relative security health of their product, both in terms of the organisation and its users.
A continuous process
Threat modelling by itself is not a silver bullet that can guarantee the security of your product. It is part of a continuous process that requires regular updates and reviews to keep up with the changes in your product’s features, environment, or threat landscape. However, by using this as part of your PDLC, you can significantly improve your product’s security posture and deliver value to your customers.
Want to know more about how threat modelling can boost your product security? Let’s chat
Our specialists have the answer