Light & agile approach to threat modeling
A comprehensive introduction to Who-What-How Threat Modeling methodology.
Light & agile approach to threat modeling
In the current dynamic business world, where the only certainty is change, organizations must adapt quickly to new challenges and threats.
In such a context, “Light” Threat Modeling methodologies become invaluable. “Light” approaches offer the flexibility and speed needed to respond effectively to unforeseen circumstances. They allow organizations to remain competitive and ensure operational continuity. By introducing methodologies that are simple to implement and produce immediate results, companies can better manage risk to support their strategies and goals.
Pros of “Light” Threat Modeling methodology
The “Light” methodology allows to:
- quickly implement Threat Modeling into existing processes, minimizing time and resources required to apply it;
- focus on the most important risks, rather than wasting time on less important issues;
- have simpler understanding and communication within teams and with stakeholders. This facilitates collaboration and ensures everyone is up to date on potential risks and mitigation strategies;
- rapidly identify risks, which supports decision-making at all levels of project management. At the same time, this is key to maintaining project dynamics and direction.
Introducing light threat modeling methodologies can bring significant benefits to organizations and projects, especially in rapidly changing environments. Focusing on speed, flexibility and efficiency can improve risk management and overall project performance and success.
How is Threat Modeling used?
Threat modeling is most often used for:
- an already existing system,
- when the team starts sprint planning (Scrum, Agile),
- when new system components are designed,
- when a new project is created.
In either case, we rarely have the comfort to spend much time on TM. The focus these days is on agility and delivering results quickly. Therefore, the TM method itself should be agile and fast and aligned strongly with how the organization works.
A good example is Scrum. According to the Scrum Guide, Refinement should take a maximum of 10% of the time of the entire sprint. If we assume that a sprint lasts 2 weeks, or 80 working hours, we should reserve 8 hours for Backlog Refinement. Of course, this depends on organization and its work culture, but this is the time that we propose to use for performing threat modeling.
Why Threat Modeling is important
First, stories created within the business requirements under discussion are enriched with more information – and this is where risks and threats come in too.
Secondly, threats can be consulted with a security team, which has a direct impact on estimating workload and setting priorities.
DREAD methodology & STRIDE methodology
Methodologies such as DREAD and STRIDE require skills that can be difficult for a development team to achieve: advanced knowledge of security, risk management and technologies used in a project. The evaluation criteria in DREAD can be vague or overly general, while in STRIDE the identification of risk categories can complicate tasks prioritization. This, in turn, can significantly impact time-consuming analysis and understanding of potential risks in the context of business requirements.
The basics of Threat Modeling
Each threat modeling session is different, but to work effectively and use the methodology, it is necessary to bring them to a common denominator. Thus, the analysis method proposed here is based on the following basics:
- Time: it is relative and depends on the participants’ knowledge level and a subject of the analysis.
- Team: we have described ways to organize an effective threat modeling session in a separate article, I encourage you to read: How to prepare an effective Threat Modeling session.
- Scope: to keep the time limit, making a real impact on productivity, we focus on a specific area of a system, such as a minor change, a new functionality, a new module or a specific area. We don’t delve into implementation details, leaving them for later verification. It is important to maintain the set level of generality. For example, when discussing the security of an organization or application, we don’t go into detail about specific API methods.
- Resources: if you don’t have resources in the form of up-to-date documentation or diagrams describing data flows (DFDs) in an application, the first step would be to explore the area domain under discussion. You need to ensure that all TM participants have the same knowledge and are on the same page.
Who-What-How Threat Modeling methodology
Who?
In this step, we identify who might be a potential attacker. This is a key element in understanding threats an organization may face. Understanding who could be a potential attacker allows us to better tailor defense strategies and prepare for different attack scenarios.
Example:
Potential attackers could be cybercriminals seeking to steal data for financial gain, competitors trying to gain sensitive information about technology or market strategy, and dissatisfied employees who may try to cause damage out of revenge or profit.
What?
What can go wrong? In this aspect of the methodology, we focus on identifying attackers’ targets. The target may be data theft, service disruption, blackmail, industrial espionage or other malicious activities. Understanding these targets allows us to better understand threats an organization may face, and to assess which assets are most vulnerable and what the consequences of an attack may be.
Example:
Company X, which processes medical data, may be the target of an attack aimed at stealing sensitive patient data. Such an attack could result in financial and legal losses and a loss of trust from customers and business partners. In addition, attackers may use the stolen data for further criminal activities, such as insurance fraud.
How?
How can they technically achieve it? This is where you analyze the methods and attack paths that attackers can use to achieve their goals. Investigating potential system vulnerabilities, security gaps and possible attack techniques, such as social engineering, software attacks or exploiting hardware vulnerabilities, is key to developing effective defense mechanisms and incident response strategies.
Example:
Attackers may try to gain access to company’s systems through social engineering, such as impersonating an employee and tricking people into providing information. They may also use software attack techniques such as SQL injection, XSS (cross-site scripting) or malware to take control of company’s systems. In addition, exploiting hardware vulnerabilities, such as attacks on firmware, can allow attackers to take control of devices.
That’s why we call it the “Who-What-How” methodology.
Who-What-How methodology as a comprehensive Threat Modeling tool
By analyzing each of these elements in detail – identifying potential attackers (Who), understanding their goals (What) and examining methods they can use to achieve those goals (How), the methodology provides a comprehensive threat modeling tool. It allows for an in-depth understanding and prediction of potential attacks, which is crucial for effective risk management and organizations protection. It is because of its focused structure based on three fundamentals that we call this methodology “Who-What-How.”
It is invaluable in identifying, analyzing and preparing for various threats, enabling organizations to minimize risk and respond more effectively to potential attacks.
Our specialists, as experts in information security, support organizations at every stage of the “Who-What-How” methodology.
Threat Modeling session outcomes
If you invite us to help you with Threat Modeling, our main task will be to support the entire process. Depending on your needs, we can help you with positioning TM within current processes and methodologies in which you work and tailoring our activities to fit perfectly with your existing resources and competencies.
We can also support your first Threat Modeling session right from the way you conduct it to active participation as security experts. You decide what kind of support you need. Our support can finish with the end of the session or expand with a report where we summarize it and describe threats and ways to mitigate them more broadly. Such a report may include:
- diagram of the discussed system area,
- documentation of the session held,
- notes,
- description of risks,
- risk assessments with information on how they were calculated,
- recommendations for mitigating the risks,
- a summary of the session with our comments on the next steps.
Fast Threat Modeling for agile development
The proposed Threat Modeling methodology allows you to quickly (compared to other methods) identify the most important threats and attack methods to protect against. It also helps to make an agile transition to selecting application defense methods and testing them on a model. All of this makes the described Threat Modeling method perfect for organizations with agile development, or in situations when there is not enough time on the very precise security analysis that other Threat Modeling methods offer.
Want to implement Threat Modeling?
At Securing, we can help your team conduct both standard and the “Who-What-How” Threat Modeling. We not only demonstrate how we perform Threat Modeling but also teach your team how to use it independently during other stages of development.
If you are interested in the “Who-What-How” Threat Modeling methodology, fill out our contact form or book a call with our IT security specialist.
