Overview:
This document defines the structured methodology of Application Threat Modeling used in organizations that identify, enumerate and prioritize mitigations for the security vulnerabilities related to the application.
It will be useful for the organization to document known security risks to an application and define countermeasures to address them. This process is inspected at a system from a potential attacker’s perspective and resists as a defender’s perspective.
Including threat modeling as a crucial component in Secure SDLC (Software Development Life Cycle) will increase application security from initial to release.
Threat Modeling methodology consists of different steps and procedure that we will discuss each one later in this article. Before let’s know what is Thread Modeling and why is so much important?
What is Threat Modeling?
Threat Modeling is a systematic step-by-step procedure to identify security threats, requirements, vulnerabilities, then measure the severity of impact and finally prioritize remediation methods to prevent or mitigate the effects.
This technique can be practiced in a broad range of things that includes applications, networks, systems, devices, and business processes.
Generally, organizations implement threat modeling to the application during the design phase but can occur in different phases also depending upon the requirements. This will help developers to discover vulnerabilities and apply security measures in their design, code and configuration methods.
Why Thread Modeling Needed?
By identifying and measuring threats and vulnerabilities based on a firm understanding of the architecture and implementation of our infrastructure and applications, we can address threats with appropriate countermeasures in a logical procedure, starting with threats that represent the greatest threats and protect IT resources.
Thread Modeling Steps:
Several methodologies and frameworks are utilized in Thread Modeling such as STRIDE, PASTA, DREAD, Trike, LINDDUN, etc. However, most of the key steps are similar in these methodologies.
Below are the six major steps included in Thread Modeling Process:
6. Mitigations
1. Identify Assets:
Identify the valuable assets, trust boundaries, security controls that are essential targets for the attackers and that must be protected. An asset can be both physical and abstract. The physical asset could be confidential data such as customer database, list of clients and Abstract Asset might be the reputation of the organization.
Asset should be documented in this step with a unique ID, name, description and assigned trust boundaries, that are required to provide the level of access at the entry point to external entities.
2. Architecture Overview:
In this step, document the architecture of the application in simple diagrams and tables that includes trust boundaries, subsystems and data flow. The objective of this step is to identify the functionality of the application, creating high-level architecture & configuration and identification of the technologies used.
- It involves creating cases to understand and identify the functionality of the application such as how and what the application does, how it accesses assets. Simultaneously it will help us how it can be misused and work on mitigations.
- Then, compose an architecture diagram consisting of the structure and configuration of the application and its subsystems as well as its physical deployment features.
- Later, identify the different technologies such as framework, servers, modules, software components, third party libraries, mobile interfaces, cloud technologies, API intergrations and containers used for the application. This will support us for any specific technology related threats later in the process and also will help in determining the best prevention techniques for it.
3. Decompose Application:
In this step, decompose the architecture of the application to an extensive level including network and infrastructure design to identify vulnerabilities in the design, implementation and deployment configuration of the application. The goal for this step is to Identify the scope of common areas of vulnerabilities in the application that includes entry points, trust boundaries, and data flow.
- The entry points in the application which also assist as entry points for the attacker to execute malicious activity. For each entry point, identify what kind of authorization and authentication is layered to it, what type of data is allowed and what kind of malicious data can be injected to bypass it. Entry points should be documented with ID, Name, Description and Trust Boundaries.
- Identify trust boundaries of the application that represents the access privileges that will grant to external entities. These trust boundaries are cross referenced with each of the concrete assets and entry points. Analyze the trust boundaries from a code perspective and for each subsystem, consider whether the upstream data flow or user input is trusted, and if not, consider how the data flows and input can be authenticated and authorized. Trust boundaries should be documented with ID, Name and Description.
- Analyze the data flow between each individual trust boundaries and consider that the data is malicious and perform validation to it. It can be understood better by building a Data flow diagram (DFD) which is a visual representation of the data flows, data stores. It will be helpful for the identification of affected components at critical points and flow of control when the application processes data.
4. Identify Threats:
In this step, identity the threats that affect the system and compromise the assets both from the attacker and defensive perspective. Conduct this identification involving application architects, security professionals, developers, testers, and system administrators.
During this step, perform the following tasks:
- Identify network threats
- Identify host threats
- Identify application threats
Perform this step in different categories such as authentication, authorization, data stored or in transit, logging, data validating, configuration management, etc. It will help in determining weaknesses of security controls, how existing preventive measures could be bypassed or where the absence of such security exists.
5. Document Threats:
In this step, document each threat with a set of attributes that defined the security condition of the application or system. By documenting findings and their impacts will be helpful in future changes to the application such as threat landscape and operating environment can be rapidly assessed and the thread model updated.
Rate the threats from the perspective of risk factors. Identify the level of risk for each threat that can be determined by how much damage that caused to an asset or system. Based on this, rate the threats as high, medium and low risks and prioritize risk mitigation strategy.
The rating process is calculated with consideration of the probability of the threat against damage that could result should an attack occur. It might turn out that certain threats do not permit any action when we compare the risk posed by the threat with the resulting mitigation costs.
- High Priority – Immediate action required
- Medium Priority – Follow the normal life cycle
- Low Priority – May be added to the road map but not necessary
6. Mitigations:
In this step, risk mitigation strategy steps should be involved for each threat and analyze the impact on business risk. Prioritize to remediate the high impact vulnerabilities. Follow up with the asset/action owner teams regarding remediation actions in order to keep track of their implementation status. Involve all relevant stake holders to fix the threat and then validate the threat remediation.
Found this article interesting? Follow DefenseLead on Twitter, Facebook and LinkedIn to read more exclusive content.