Threat Modeling: 5 simple steps to a secure system

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.