Skip to main content

Threat Modelling

 

Threat modelling is a procedure for optimizing application, system or business process security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent or mitigate the effects of threats to the system.

Threat modeling helps to identify the security requirements of a system or process -- anything that is mission-critical, processing sensitive or made up of valuable data. It is a systematic and structured process that aims to identify potential threats and vulnerabilities to reduce the risk to IT resources. It also helps IT managers understand the impact of threats, quantify their severity and implement controls.

In terms of software security, threat modelling is the most important part of software design and development. It is impossible to build applications and systems that comply with corporate security policies and privacy and regulatory requirements without evaluating and mitigating threats.

IT-based threat modelling gained traction in the 1990s with the development of threat and attacker profiles. Microsoft introduced its STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege) threat modelling methodology in 1999. There are now many other approaches. They all involve deconstructing the elements of an application or system to identify the assets to be protected and the possible threats to be mitigated. A threat modelling methodology is a way to break down a complex process into smaller tasks making it easy to spot weaknesses.

Why is threat modelling important?

Any application or system must be designed to withstand attacks. Yet, establishing the security requirements needed to achieve this can be complex. Attackers think and act differently from developers and users.

Threat modelling is a proactive method of uncovering threats not usually considered or found through code reviews and other types of audits. It enables a project team to determine which security controls an application needs to set effective countermeasures against potential threats, and how to resolve problems early on. This approach leads to a far more secure applications, and by prioritizing anticipated threats, resources are used effectively.

Threat models are a vital part of a functional security development process. When threat modelling is part of the DevOps process developers can build security into a project during development and maintenance phases. This prevents common omissions such as failing to validate input, weak authentication, inadequate error handling and failing to encrypt data.

How does the threat modelling process work?

There are several different threat modelling frameworks and methodologies. However, the key steps are similar in most of these processes. They include:

  1. Form a team. This team should include all stakeholders, including business owners, developers, network architects, security experts and C-level execs. A diverse team will generate a more holistic threat model.
  2. Establish the scope. Define and describe what the model covers. For example, is it focused on an application, a network or the application and the infrastructure it runs on? Create an inventory of all components and data included and map them to architecture and data flow diagrams. Each data type must be classified.
  3. Determine likely threats. For all components that are threat targets, determine where threats exist. This what-if exercise builds broad, technical and unexpected threat scenarios, including threat or attack trees to identify possible vulnerabilities or weaknesses that could lead to compromise or failure. Threat modeling tools can help automate and streamline this step.
  4. Rank each threat. Determine the level of risk each threat poses and rank them to prioritize risk mitigation A simple but effective approach is to multiply the damage potential of a threat by the likelihood of it occurring.
  5. Implement mitigations. Decide how to mitigate each threat or reduce the risk to an acceptable level. The choices are to avoid risk, transfer it, reduce it or accept it.
  6. Document results. Document all findings and actions, so future changes to the application, threat landscape and operating environment can be quickly assessed and the threat model updated.

Threat modelling best practices

There are several steps to take to ensure an effective approach to threat modelling. Some of them include:

  • Start early. Threat modelling can be done at any time during a project, but earlier is better as the findings can help ensure the design is secure. It is also quicker and cheaper to add security controls early in the build process.
  • Get a lot of input. Soliciting input from a variety of stakeholders helps identify the widest range of potential adversaries, motives, threats, and where the most vulnerable components reside.
  • Use a variety of tools. There are many tools available, including some unusual approaches. For instance, the University of Washington's Security Cards are a brainstorming tool that helps discover less common or novel attacks and how best to respond to them.
  • Understand risk tolerance. Business owners in particular must fully understand and communicate their risk-tolerance levels so the correct approaches to threat mitigation can be chosen to ensure business goals are met.
  • Educate everyone. Train everyone involved in the different aspects of threat modelling, so their inputs can be maximized. As always with security, threat modelling is an iterative development.

Threat modelling methodologies and frameworks

Early modelling methodologies used data flow diagrams to visualize of how data moves through an application or system. However, they were too limited for modern applications that are deployed in highly interconnected environments with multiple users and devices connecting to them.

Process flow diagrams are now commonly used. They show an application or system from the perspective of user interactions and how potential attackers may try to move through the application. This makes it easier to spot and prioritize potential threats.

Attack trees are also used to visualize attacks on a system, the tree root being the goal of an attack, with the leaves being ways an attack might achieve that goal. Attack trees can be built for individual components of an application or to evaluate a specific type of attack.

Many threat modelling methodologies and frameworks have been developed. Attack-centric ones focus on the types of possible attacks, and asset-centric ones focus on the assets that need to be protected. The most common ones use the following approaches:

  • Damage, Reproducibility, Exploitability, affected users, Discoverability (DREAD) is a quantitative risk analysis that rates, compares and prioritizes a cyberthreat's severity.
  • National Institute of Standards and Technology's Guide to Data-Centric System Threat Modelling focuses on protecting particular data types within systems. It models aspects of attack and defense for selected data.
  • Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) provides an asset- and risk-based strategic assessment that is customizable for specific security objectives and risk management It was developed by Carnegie Mellon University for the Department of Defense.
  • Process for Attack Simulation and Threat Analysis (PASTA) is a seven-step, attack-centric process designed to correlate technical requirements with business objectives, considering business impact analysis and compliance requirements.
  • STRIDE is part of the Microsoft Security Development Lifecycle. It identifies system entities, events and the boundaries and then applies a set of known threats. Using it, security teams can identify potential threats.
  • Trike is an open source, risk-centric methodology that ensures each asset's assigned risk level is OK with all interested parties.
  • Visual, Agile, and Simple Threat (VAST) is based on ThreatModeler, an automated threat modelling tool designed to integrate into an Agile software development environment and provide actionable outputs for developers and security teams.

Threat modelling tools

Threat modelling is not straightforward. There is an endless number of possible threats. Even with a small project, it makes sense to use a threat modelling tool to reduce the time and cost involved.

Threat modelling tools reduce the complexity of the process, making it structured and repeatable. That reduces the number of resources needed to create a threat model from scratch and maintain it over time. A good threat modelling tool lets users visualize, design, plan for and predict all sorts of potential threats. The key features tools should have included:

  • ease of input for both system information and security rules;
  • threat intelligence feed to ensure the latest identified threats are considered;
  • threat dashboard with suggested mitigation strategies;
  • mitigation dashboard that integrates with an issue tracker like Jira; and
  • reports for compliance and stakeholders.

Some commonly used threat modelling tools include:

CAIRIS. An open-source platform that uses intelligence about potential threats to measure the attack surface and validate designs for known security problems and potential GDPR compliance issues.

IriusRisk. A diagram-centric threat modelling tool with adaptive questionnaires that guide the user through the technical architecture, planned feature and security context of the application.

Microsoft Threat Modelling Tool. This free resource is designed for users who are not security experts. It provides guidance on creating and analyzing threat models as part of the Microsoft's Security Development Lifecycle. It uses of standard notation to illustrate system components, data flows and security areas, making it easy to identify classes of threats based on the structure of the software being designed.

OWASP Threat Dragon. This open-source tool runs as a web or a desktop application. It records possible threats, determines mitigation approaches and shows users threat model components and threat surfaces.

SD Elements. This Security Compass tool collects and classifies system information based on vulnerabilities providing audit-ready reports.

Threagile. This is an open-source integrated development environment tool that incorporates threat modelling at the application codebase. It can run using the command-line, as a Docker container or as a REST server.

ThreatModeler. Community, cloud security and application security editions automate threat modeling. They identify, predict and define threats, including prebuilt architecture templates to speed up integration.

The takeaway

Whichever tool is used, the threat modeling process should be repeated whenever the application, IT infrastructure or threat environment changes. That keeps the threat model current, as new threats emerge.

Analyzing threats involves time and effort. It is not a checklist exercise, but it is better to find a vulnerability and fix it before hackers discover it, and threat modeling methodology is the best way to achieve this.

Comments

Popular posts from this blog

Understanding the Evolution: AI, ML, Deep Learning, and Gen AI

In the ever-evolving landscape of artificial intelligence (AI) and machine learning (ML), one of the most intriguing advancements is the emergence of General AI (Gen AI). To grasp its significance, it's essential to first distinguish between these interconnected but distinct technologies. AI, ML, and Deep Learning: The Building Blocks Artificial Intelligence refers to the simulation of human intelligence in machines that are programmed to think like humans and mimic their actions. Machine Learning, a subset of AI, empowers machines to learn from data and improve over time without explicit programming. Deep Learning, a specialized subset of ML, involves neural networks with many layers (hence "deep"), capable of learning intricate patterns from vast amounts of data. Enter General AI (Gen AI): Unraveling the Next Frontier Unlike traditional AI systems that excel in specific tasks (narrow AI), General AI aims to replicate human cognitive abilities across various domains. I...

Normalization of Database

Database Normalisation is a technique of organizing the data in the database. Normalization is a systematic approach of decomposing tables to eliminate data redundancy and undesirable characteristics like Insertion, Update and Deletion Anamolies. It is a multi-step process that puts data into tabular form by removing duplicated data from the relation tables. Normalization is used for mainly two purpose, Eliminating reduntant(useless) data. Ensuring data dependencies make sense i.e data is logically stored. Problem Without Normalization Without Normalization, it becomes difficult to handle and update the database, without facing data loss. Insertion, Updation and Deletion Anamolies are very frequent if Database is not Normalized. To understand these anomalies let us take an example of  Student  table. S_id S_Name S_Address Subject_opted 401 Adam Noida Bio 402 Alex Panipat Maths 403 Stuart Jammu Maths 404 Adam Noida Physics Updation Anamoly :  To upda...

How to deal with a toxic working environment

Handling a toxic working environment can be challenging, but there are steps you can take to address the situation and improve your experience at work: Recognize the Signs : Identify the specific behaviors or situations that contribute to the toxicity in your workplace. This could include bullying, harassment, micromanagement, negativity, or lack of support from management. Maintain Boundaries : Set boundaries to protect your mental and emotional well-being. This may involve limiting interactions with toxic individuals, avoiding gossip or negative conversations, and prioritizing self-care outside of work. Seek Support : Reach out to trusted colleagues, friends, or family members for support and advice. Sharing your experiences with others can help you feel less isolated and provide perspective on the situation. Document Incidents : Keep a record of any incidents or behaviors that contribute to the toxic environment, including dates, times, and specific details. This documentation may b...