A secure architecture has become the need of the hour for almost everyone. As a result, no one needs any vulnerabilities in their clusters. But is it wise to add security after a mishap has occurred? What if we can identify potential risks at the time of development itself? This is exactly where Threat Modelling fits almost perfectly while helping organisations excel in creating more secure products.
Threat modelling is a risk-based approach to designing secure systems. It is based on identifying threats in order to develop mitigation to them. Because of cyber security risk increasing and enterprises becoming more aware of their liabilities, software development teams need effective ways to build security into software.
Benefits of Threat Modelling
The benefits of a secure environment are numerous thus making the number of benefits for threat modelling increase as well. Although these vary with respect to use cases and other factors, we can find the following listed almost in every situation:
- Helps in designing more secure products by identifying threats early in the development cycle while giving an insight to the risks
- Helps in formal security documentation and review of security architecture. As a result, provides team wide knowledge sharing.
- Enables focused security testing while in development phase only.
- Simplifies certifications and helps implement common security design and best practices because of which the application becomes more hardened.
Breaking Down Your Problems
Start from the technology
The first focus should always be technical threats rather than broader threats. Broader threats include hacker groups, bad actors, human errors, epidemics and many more. As a result, these kind of threats are uncertain and unpredictable.
Technical threats are much finer and are likely to be weakness in software, missing security controls, or something like authorisation issues. These emerge from the architecture of our systems and as a result, the data flow. Also, multiple technical threats combine to cause a broad threat.
Take Collaborative Approach
The second essential thing is to take a team based approach. Looking for cracks in a system is not an easy task, and a diverse team perspective will have wider inputs. As a result we will be having better decision making ability. No matter what is being done, there is always going to be one or more security vulnerability to find out. While knowing the architecture always helps, a large set of eyes will always have more chances of finding those vulnerabilities.
Threat modelling also has a great part for product owners. Expecting the developers to find all the vulnerabilities in a product is too much to ask them because they lack the insights of user behaviour and business context that the product owner have. They are always going to have inputs about impact of data loss on the customers and services.
One Step at a Time
The third recommendation is to start threat modelling one step at a time. As a result, each discussion within a team should be short and understandable by each member. The topics should be as thin as possible because of which the solution for the same could be provided in a recent future.
Our focus should be on building the muscle memory of the team and not looking at the whole system at once. Each session might be having little effect but as a result of all the sessions, the cumulative effects will be huge.
Introduction to STRIDE
In this section, we will be focusing on a popular strategy of doing threat modelling called STRIDE. This is a Software Centric Threat Modelling and is based on grouping threats into categories. STRIDE takes its acronyms from the following threat categories:
- Spoofing Identity
- Tampering with Data
- Repudiation
- Information Disclosure
- Denial of Service
- Elevation of Privilege
This approach helps organisations to do threat modelling without being experts while saving time and money.
Approach for STRIDE
There are four essential steps for implementing STRIDE
- Decompose the system into its relevant components
- Decompose components into elements used in Data Flow Diagram
- Analyse threats in each component
- Mitigate the threats
Mapping Threats to Elements
Each elements in a DFD is vulnerable to different types of threats. Below table maps the elements to the respective category of threats:
| Element | Spoofing | Tampering | Repudiation | Information Disclosure | Denial of Service | Elevation of Privilege |
| Data Flows | X | X | X | |||
| Data Stores | X | X | X | |||
| Processes | X | X | X | X | X | X |
| Interactors | X | X |
Mitigating Threats
The threats can be mitigated by enhancing the corresponding security properties:
| Threat | Security Properrties |
| Spoofing | Authentication |
| Tampering | Integrity |
| Repudiation | Non-repudiation |
| Information Disclosure | Confidentiality |
| Denial of Service | Availability |
| Elevation of Privilege | Authorisation |
Conclusion
We have discussed in this blog about what in particular is threat modelling. Various benefits of threat modelling were also discussed. Then, approaches of doing threat modelling within a team was discussed. Although we have discussed STRIDE as an approach, it is not the only one out there. Also there is the Microsoft TMT Tool which helps in implementing STRIDE approach while providing GUI functionalities. All of this will be discussed in later blogs.
References
