Imagine that you are working on a new e-commerce website with a team of developers. Everything appears to be going smoothly. With the release date coming closer and the marketing team ready to announce the new site to the world, everyone starts to celebrate in anticipation of a successful launch.
Then alarm bells sound! The system is now unavailable due to a ‘Distributed Denial of Service’ (DDoS) attack from an unknown source. After investigating for a few days, you identify the vulnerability as ‘Slow Read DoS’ that only attacks a portion of the website.
In spite of building an excellent website, why couldn’t your team protect it from vulnerabilities?
Designing a secure system is a complex task. In this case, the team failed to take measures to ensure system security by safeguarding it from vulnerabilities in advance.
So, how can you prevent such a scenario in future? Enter Threat Modeling.
Often systems are designed to cater to business requirements only. Threat modeling, however, is an approach that helps you identify security threats and vulnerabilities in the application during the design phase. This is important because fixing security issues detected during the testing phase are not only time consuming but costly as well.
So before we get to the threat modeling approach, let’s take another example from our e-commerce website. Assuming that threat modelling has not been performed on the existing website, a tester finds out during the penetration testing phase that an attacker/hacker is able to manipulate the order when placing a request. He is able to change the order price and shipping address.
A few common reasons why the site was open to such threats are:
- 1. Users were allowed to perform critical operations without re-authentication.
- 2. Input data validation was not carried out before processing.
- 3. Sensitive information such as system details, session identifiers or account information was disclosed in error responses.
How would you approach threat modeling to mitigate such threats in the future?
As architects, each one of us may have a different approach to threat modelling, depending on the requirement in a project or our individual experiences. Here are 5 steps to secure your system through threat modeling.
Step 1: Identify security objectives
Understand security requirements and identify possible threats in business flows to achieve objectives. You should also consider if there are any specific compliance or security-related requirements that are a part of the business objectives. For example, during auditing, sensitive information (e.g. SSN number, age etc.) should not get logged and the log file should be accessible to a specific set of users only.
Step 2: Identify assets and external dependencies
Unauthorized access to assets such as data, code, and system information are the reason why threats occur. The security architect needs to identify a list of assets to be protected from potential attackers. They must also identify external dependencies which are not part of code, but may pose a threat to the system. Consider how the application will be accessed on the production environment or the web server. Or how database communication will take place on a private or public network.
Step 3: Identify trust zones
Architects must identify a trust zone and corresponding entry-exit points. This information should be documented and used to develop data flow diagrams with privilege boundaries. This helps define the approach to user authentication, input data validation, and error handling. In the e-commerce website example we talked about earlier, the order processing system can be identified as a trust zone that will need a price validation check against the ordered item ID.
Step 4: Identify potential threats and vulnerabilities
Besides running a wide search for threats under a predefined approach like STRIDE, consider threats that would generally impact your system. Some examples could be - SQL injections, broken authentication, and session management vulnerabilities. Identify risk-prone areas like poor input validations, over privilege accounts, weak password policies, custom encryption, inadequate auditing or logging, displaying error or exception messages to end user.
Step 5: Document threat model
Threat modelling is an iterative process and documentation forms an important aspect of the team’s responsibilities. Architects can use documentation to create secure design/architecture and mitigate architecture related security threats. Developers can use documentation as security guidelines to mitigate security risks and testers to drive test cases to find vulnerabilities in the system. It helps the tester create security related test cases and validation test cases for trust zone.
Threat modelling should start with design phase and run parallel with architectural design. Moreover, it is important to remember that there is no single approach to threat modeling. To achieve optimum results, take a predefined approach such as STRIDE, DREAD and combine it with 5 steps above.