There are a variety of ways to model threats. The ideal method for your requirements will be based on the kind of threat that you’re trying to predict and your objectives. Some of these approaches are perfect. Some are abstract while others concentrate on risks, people or privacy concerns.
These methods are able to be combined to give an even more comprehensive and complete overview of the possible risks that could be threatening the security of your IT assets. The following article we’ll give a summary of five methods.
Is threat modeling a threat?
Threat modeling was originally an engineering task, and was limited to large-scale projects, in an agile environment.
In the last decade the activity has grown to the point that it’s now an integral part of the security controls needed to ensure compliance with the 2022 edition of the ISO 27002 cybersecurity standard.
This fairly simple task places security at the start of projects, and where modifications are the least costly. This is the initial brick that forms the basis of security through design.
What are the reasons why threat modeling is important?
The objective is to make use of an easy analysis to identify the structural areas in which information security is at risk in the architecture or in systems for instance, in applications that are in development.
For deployments that are new this analysis provides assurance that there aren’t any hurdles in the application of security measures, like the reliance on unsecure systems or protocols that are not secure, such as weak authentication.
Historically the threat modeling process has primarily been focused on development of applications. However, it’s feasible to expand the analysis to accessibility issues including scaling deployments (e.g. redundancy) as well as authentication, upgrades , and cross-border transfer of data problems. A system-wide approach could be easily modelled on architectural models for applications.
When should you begin to start threat modeling?
In accordance with best practices, all security standards must be identified beforehand to verify the design or architecture.
This analysis will be used to determine if the design is in line with general criteria, and also to evaluate the choices made in technology in this design/architecture stage.
This security procedure can be executed at all stages of the design. It is however recommended to perform this procedure prior to testing the design or design or the. It is less costly to make any changes that are required. Additionally, you can conduct partial or intermediate modeling to pinpoint security issues as soon as possible and to cut down on the cost of designing.
What are the resources needed?
There are a few human resources needed However, they may be difficult to obtain depending on the specific business environment.
In the first place, it is crucial to have at minimum one person who comprehends the structure that needs to be examined (the infrastructure, software and so on.) as well as the implementation.
Depending on the method and the tool used, it is necessary/indispensable to have someone who is familiar with cybersecurity attacks and is able to translate them, in a defensive context, into protection measures.
The person responsible for the component being studied (application infrastructure, application, etc.) and typically the person who is responsible for the evolution of the component (e.g. SCRUM master) should incorporate the results into continuing evolutions.
The risk manager must be present at meetings to determine the technical risks so they are better assessed.
For more extensive analyses it is essential to be represented by a legal professional who is familiar with the requirements of law in the country concerned.
Within the setting for ISO 27001 certifications, the ISMS manager should have a clear understanding of the process and oversee the activities (e.g. scheduling, reporting, the collection of deliverables, monitoring modifications) to ensure that the process is in line with the requirements of the standard.
Certain existing threat modeling techniques
There are many ways of delineating risks, all of which have pros and drawbacks. The method used will depend on the goal as well as the experience of the business and the methods that are already in place.
A brief description and outline of the most effective methods are listed below.
Method of threat modeling no. 1 STREADS
Prior to that, the method of reference included the STRIDE Method.
Spoofing,
Tampering,
Repudiation,
Information disclosure,
Denial of service
The elevation of privilege
The possible scenarios in any of these categories which form the acronym should be determined for each of these categories. To make a complete list of attack scenarios it is best to make use of the knowledge basis (see this section).
These are the attacks techniques employed to compromise information security.
The method is well-known and continues to be used since it is simple to learn. But, Microsoft no longer supports this method and is now a fan of the method known as DREAD.
Method for modeling threats does not work. 2. DO NOT
As before, the terms which make up the new acronym
Risk of damage
Reproducibility,
Exploitability,
Users affected,
Discoverability.
While it is easier for anyone to grasp but the scoring system for every one of the categories can be dependent on interpretation. It is also essential to account for the final D (Discoverability) that is a method of promoting security through obscurity. This practice is strongly discouraged because it gives a false impression of security.
This approach isn’t easy to implement due to these biases
D represents an impact. There is no bias here.
R: This number is often the same throughout the beginning. This does not permit the diverse threats to be classified.
E. Ease of Operation. No bias .
A: It’s hard to determine the significance of each user group in relation to each other. Security should also be considered in the context of the whole, as vulnerability can be found only infrequently be affecting a particular group of people (with the possibility of excluding system administrators)
D: Increases security through the illusion of obscurity, which is known as the definition of a “false partner.”
This study therefore focuses on operability and impacts as these are the most common values employed to assess risks, however the approach isn’t very useful in identifying risks and vulnerabilities.
Threat modeling method number. 3 Method 3: Quantitative threat modeling
The technique focuses on determining the vulnerability’s severity using CVSS scores. The threat is identified attacking trees whose base is each of the categories used in the method STRIDE (as previously mentioned).
But attack trees could take a considerable amount of time to put in place and CVSS scores don’t take into consideration the company context (and any existing measures in place to minimize their impact).
This highly technical method should be considered for small, highly critical developments/architecture where vulnerabilities could have strong impacts, regardless of the environment.
Threat modeling method, no. 4: LINDDUN
Acronyms are used to describe: can be used to refer to:
Linkability,
Identifiability,
Non-repudiation,
Detectability,
Information disclosure,
Unawareness,
Non-compliance
This method can be helpful to determine if there are any contradictions with this regulation. EU 2016/679 GDPR regulations and conformity with the main notions in “privacy through the design” in addition to “privacy through default” which are defined in this regulation.
It is, however, difficult to determine the severity of a vulnerability using these criteria. This approach is to be used for compatibility analysis in relation to privacy laws as opposed to searching for technical weaknesses.
Method of threat modeling no. 5 PASTA
This approach employs a sensible process that blends the goals of business and technical risk.
However, this approach isn’t widely utilized and takes a considerable amount of time to set up. It is nonetheless complete and is compatible with other business functions (e.g. IT operations, risk assessment).
Which method of threat modeling do you recommend for your company?
The method chosen is dependent on the objectives of discovery along with the integration work in the overall project (such as the integration of risk analysis using PASTA). PASTA method or the need for compliance using LINDDUN).
While it is not the most recent Although it is not the most current, although it’s not the most recent, STRIDE method is simple to grasp and provides useful results. In situations where the threat modeling process is brand new and new, the STRIDE method produces specific results that assure the viability of this approach for project management, although it is possible that in the future alternative methods could be employed.
In situations where the process is already in place it is possible to implement a more integrated strategy like PASTA threat modeling might be recommended for instance, in conjunction with the department responsible for risk management.
Although these tests do not require any tools and a basic piece of paper is sufficient, there are some tools that could assist with the strategies mentioned in the previous paragraphs. These tools typically provide an easy-to-read visual representation as well as details of the weaknesses and dangers that people are able to read.
Automated tools
There are numerous tools to choose from. Two of them that work with open source or free software:
IsiusRisk platform
The MTMT (“Microsoft Threat Modeling Tool”). Threats are added to threats that are already in place in accordance with knowledge bases.
Manual tools
Manual approaches, on contrary, need compliance with a base of knowledge and/or individuals with experience in threat modeling. This often justifies the need for an external service to find the right people with the required expertise.
The open-source tools include:
OWASP Threat Dragon
Diagramming by hand (in workshop) Whiteboard method If needed, using tools such as Microsoft VISIO
A knowledge base of threats and attacks
Possible attacks on each system can be identified by using the MITRE ATT&CK knowledge base (attack.mitre.org/matrices/enterprise/).
There are also CAPEC taxonomies (capec.mitre.org/data/index.html) and CWE (cwe.mitre.org/data/index.html) that are more technical and product-oriented. It is useful to conduct detailed threat analysis on one or more critical systems that don’t change frequently. In the majority of systems, this could be slightly labor-intensive, and not sustainable.
However, it is important to decide on the desired degree of detail to minimize the amount of time needed to finish the analysis. The decision-making process is dependent on the available resources and the importance of the element being studied (depending on whether it’s the entire infrastructure of the company or a tool used to provide the provision of services, or an instrument that is not accessible via the Internet).
Possible inputs
The following documents could be helpful in the process of analyzing:
UML diagrams
Deployment diagrams
Workshops with technical teams (especially to facilitate an action that is a posteriori)
Diagrams of data flow (DFD)
Attack trees
Previous lessons learned
Possible deliverables
The activity results in (depending on the method employed and the purpose of the task):
An inventory of dangers
Diagrams of deployment (usable to obtain certifications)
Additional flow diagrams of data
Diagrams of threat analysis
A chart of threats (to be included in SCRUMs and other measures of the project)
Complete supplements to the risk analysis
A GDPR compliance assessment
The general approach to threat modelling is that is utilized
General Modeling of Threats Approach
Threats are identified according to the methodology used in the different paradigms (vulnerability/attack concepts/privacy). The PASTA technique is far more extensive and may be too broad in many instances.
Based on the method employed depending on the method used, the impact will be primarily on the threat detection.
Examples of flow diagrams of data
These diagrams show the boundaries and flows (which could be technically-oriented, i.e., with encryption, protocols, and encryption, etc. like in 3rd diagram).
They can help tech business analysts and developers to get a better perspective of the product. This transparency is among the primary benefits of this technique.
How does threat modeling affect your GRC method?
This can be incorporated into a GRC method to assist in the implementation of security measures particularly in DevSecOps teams, as well as to enhance the risk assessment for the infrastructure and applications where they are used.
This could also be pertinent when it comes to improvement in security of the organization like the creation of the flow of personal information diagrams. These processes aren’t often modified and can be improved by this method.
Particularly, PASTA can be used to determine technical risks however, this method requires a certain level of structural maturity as well as a willingness to be involved.
