You receive a notification informing you that your company or client has been subject to a security breach as the result of a cyber-attack. Sadly, a scenario that's not too farfetched. Now consider being a Product Owner and discovering later that day that the attack occurred through a weakness exploited within one of the products that you're responsible for. With the average cost of a data breach estimated to be USD 3.86 million in 2020 *1, this is a nightmare situation that you and your team will never want to face.
In this article we’ll look at a practice that you as a Product Owner can apply regardless of the processes, frameworks, or the cyber security maturity at your company.
You may find yourself in an organisation that has guidelines in place for ensuring best practices are followed when developing software. Both Microsoft and the National Institute of Standards and Technology have published thorough frameworks for secure software development:
- Microsoft - Security Development Lifecycle (SDL) *2
- NIST - Secure Software Development Framework (SSDF) *3
These include guidelines for:
- Preparing the Organization
- Protecting the Software
- Producing Secured Software
- Responding to Vulnerabilities
Whilst the practical implementation and stewardship of these frameworks are outside the scope or control of a Product Owner responsible for software development, we can take a closer look at a technique that is referenced in both frameworks, and that can be incorporated into your team’s way of working.
Threat modelling is repeatable method to help you understand all the potential threats and risks to your product. This technique is often used by security experts to help answer the question "what can go wrong in the system we're working on?"
The goal of threat modelling is to identify all the potential vulnerabilities of a system, assess the impact of those vulnerabilities, and then prioritize them based on their severity. Using the STRIDE model *4, which was originally from Microsoft, each identified threat is categorized into the following:
Threat | Desired property | Violation consequence |
Spoofing | Authenticity | A situation in which a person or program successfully identifies as another by falsifying data, to gain an illegitimate advantage |
Tampering | Integrity | Software with an unauthorized modification that alters the computer program code and behaviour |
Repudiation | Non-repudiability | Authoring information is changed by a malicious user to log wrong data, meaning data stored on log files can be considered invalid or misleading |
Information disclosure | Confidentiality | A situation where sensitive, protected, or confidential data is copied, transmitted, viewed, stolen, altered, or used by an individual unauthorized to do so |
Denial of service | Availability | When a machine or network resource is unavailable to its intended users by flooding the targeted machine or resource with superfluous requests in an attempt to overload systems and prevent some or all legitimate requests from being fulfilled |
Elevation of privilege | Authorization | When an application with more privileges than intended by the application developer or system administrator can perform unauthorized actions |
When to perform threat modelling:
Threat modelling can be performed as soon as the architecture has been agreed upon and the main components or functions are known.
Consideration needs to be given to whether the threat model should be revisited at the beginning of each sprint based on the implications of the stories being developed.
Who should be involved:
Depending on the software implementation, then any of following roles could be key to holding a successful threat modelling workshop:
- Architects
- Developers
- Product Owner
- Key product stakeholders
- Security experts
- Network experts
- Hardware experts
- Cloud experts
One tip here is to agree on the scope of the analysis beforehand, knowing the boundaries of the model will help you invite the correct stakeholders.
How should you perform threat modelling:
Look to decompose your system into its constitute components using modelling techniques like data flow diagramming, the various UML diagrams, or something like the SIPOC method. By doing this you can simply and quickly depict the system graphically in order to establish the following:
data flows | From where to where does data flow the model |
data stores | Where is data stored within the model |
processes | Where is data changed within the model |
interactions | Where potential attackers can interact with the model |
trust boundaries | Where data changes its level of trust, e.g., any place where data is passed between two processes |
For each item found analyse its susceptibility to the STRIDE threats.
Just like performing risk analysis, look at the impact and likelihood of each vulnerability to determine the seriousness of it. Even here we have the mnemonic DREAD as a tool for risk assessment modelling:
Damage | how bad would an attack be? |
Reproducibility | how easy is it to reproduce the attack? |
Exploitability | how much work is it to launch the attack? |
Affected users | how many people will be impacted? |
Discoverability | how easy is it to discover the threat? |
Once ranked, any potential vulnerabilities can begin to be mitigated. Some of the corrective actions may lead to backlog items within your team. Other vulnerabilities discovered may create new security requirements that feed back into the guidelines and standards within your organisation. Whilst others may lead to changes in the workflow of a process, or even physical changes with the working environment.
Hopefully this technique can save you from that unwanted notification informing you that your product is the weak link in the security chain.