Threat hunting is an effective way to identify threat vectors that can cause disruption in your environment by exploiting vulnerabilities and misconfigurations. With the Digital first approach taken by most of the business, there is always a rush to launch new services online quickly. Traditional approaches of conducting risk assessments / security assessment at the end of the development lifecycle or just before launching a service leaves potential threat vector unmitigated.
Threat modeling is an effective exercise which can be incorporated as part of the software development lifecycle or the dev ops process to identify all the potential threats associated vulnerabilities, attack patterns and mitigation earlier. The critical, high, and medium risk threats can then be prioritized to be fixed either by way of design / architecture change, code level fixes, securing the configuration at infrastructure level or enhancing the internal processes.
A typical threat modeling exercise follows the following approach:
Information Gathering
- Get a complete understanding of the application underlying infrastructure and business objectives that are being achieved.
- Review the application design and understand the flow, touchpoints with other internal and external applications.
- Review the use cases defined.
Threat Profiling
- Based on the High Level and Low-Level Design create a component level diagram highlighting all the possible execution paths and information flows in a program
- Identify underlying assets, security controls, trust zones, and threat agents.
- Define internal trusted boundaries. These can be the different security zones that have been designed.
- Identify the information elements and their classification as per organizations information classification policy.
- Identify all possible attacker’s threat agents that could exist within the Target of Evaluation.
Risk Analysis
There are two common approaches used for risk analysis.
Risk Rating for the identified Threats can be performed using the STRIDE approach.
| Type | Definition | |
| Spoofing | Threat action aimed to illegally access and use another user’s credentials, such as username and password | |
| Tampering | Threat action aimed to maliciously change/modify persistent data, such as persistent data in a database, and the alteration of data in transit between two computers over an open network, such as the Internet | |
| Repudiation | Threat action aimed to perform illegal operation in a system that lacks the ability to trace the prohibited operations. | |
| Information disclosure | Threat action to read a file that they were not granted access to, or to read data in transit | |
| Denial of service | Threats aimed to deny access to valid users such as by making a web server temporarily unavailable or unusable. | |
| Elevation of privilege | Threat aimed to gain privileged access to resources for gaining unauthorized access to information or to compromise a system. |
Risk Rating of the associated vulnerabilities / attacks can be performed using the DREAD approach.
The DREAD formula is divided into 5 main categories:
- Damage – how bad would an attack be?
- Reproducibility – how easy it is 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 it is to discover the threat?
The identified vulnerabilities are rated for each of the above parameters on a scale of 0 to 5. 0 having low risk and 5 being the highest. The final risk score can be arrived at using the following formula:
Risk Value = (Damage + Affected users) x (Reproducibility + Exploitability + Discoverability)
Alternatively, an organization can use its internal risk rating methodology to define the risk rating for the vulnerabilities or can align the DREAD risk score to its internal risk rating definition.
Controls Definition
- Review what existing controls can be mapped to reduce / mitigate the risk for the identified vulnerabilities.
- Define additional controls to further reduce / mitigate the risk from the identified vulnerabilities.
- Controls could be Design level changes, code level fixes needed, change in the configuration at system level or process changes.
- Once the controls are accepted by all the stakeholders, ensure that these controls become part of the development lifecycle and all the stake holders are aware of what controls need to be implemented.
Validate
- Validation of the controls can be done at different stages.
- Design changes need to be validated before the final design is signed off for development and implementation.
- Code level fixes can be validated at the development phase before the code is moved to UAT.
- Other controls can be validated at UAT / Preproduction tests and assessments.
- Final checks can be done before moving the application to production.
Performing threat modeling periodically and incorporating it as a standard practice ensures that there is an improvement in overall maturity in the way applications are built / enhanced. It also leads to more effective utilization of resources and ensure a security first approach / culture is built.
By Yogesh Bhatia, Senior VP at Aujas Cybersecurity
Yogesh Bhatia is Senior VP at Aujas Cybersecurity, a specialized global cybersecurity firm that focuses on providing consulting and advisory services.