russia is waging a genocidal war in Ukraine. Please help Ukraine defend itself before russia has a chance to invade other countries.
Software, AI Innovation, and Entrepreneurial Success | Threat modelling game plan in cybersecurity approach

Threat modelling game plan in cybersecurity approach

Slava-Agafonov Apr 05, 2022
Facebook Twitter Google + LinkedIn Pinterest Email Share...

If you're doing your first threat model or haven't done one in a while and are asked to make one, you may wonder where and how to start.  This page attempts to give a few tips on what makes a threat model good. Having a good threat model sets the foundation for a productive threat model review meeting. Threat modelling involves identifying potential (or real) vulnerabilities, and then putting countermeasures and controls in place so that those vulnerabilities are not exploited. There are several different approaches we can use when engaging in threat modelling. First, we can look at it from the attacker’s perspective, seeking to understand their goals and abilities, then reverse engineer protective measures. Second, we could look at things from an architecture perspective, digging into our web servers, email servers, routers, and switches. With this approach, we would identify weaknesses and then create defensive measures. Threat modelling is a practice to perform designing and assessing the potential threats to a system in scope, evaluating the eventual risks both from a technical perspective and from the point of view of the business, and identifying what can be done to make those risks acceptable. 

What is threat modelling?

Threat modelling is analyzing representations of a system to highlight concerns about security and privacy characteristics. Threat Modeling is still perceived as an activity separated from the Business. This hampers its ability to impact the decision process and limits the perceived value. This separation is also both caused by and causes an objective difficulty to communicate security risks to the Business. Caused, because most frequently than not we, as security experts are not able to communicate with the Business in a way that would be easily understandable and would allow making decisions. And cause, because this separation makes it harder to understand what is needed to evolve our language in a way that would make communication with the Business more effective.

Threat modelling

At the highest levels, when we threat model, we ask four key questions:

  1. What are we working on?
  2. What can go wrong?
  3. What are we going to do about it?
  4. Did we do a good enough job?

Why threat model?

When you perform threat modelling, you begin to recognize what can go wrong in a system. It also allows you to pinpoint design and implementation issues that require mitigation, whether it is early in or throughout the lifetime of the system. The output of the threat model, which is known as threats, informs decisions that you might make in subsequent design, development, testing, and post-deployment phases.

Who should the threat model be?

You. Everyone. Anyone who is concerned about the privacy, safety, and security of their system.

How should I use the Threat Modeling Manifesto?

Use the Manifesto as a guide to develop or refine a methodology that best fits your needs. We believe that following the guidance in the Manifesto will result in more effective and more productive threat modelling. In turn, this will help you to successfully develop more secure applications, systems, and organizations and protect them from threats to your data and services. The Manifesto contains ideas, but is not a how-to, and is methodology-agnostic.

The Threat Modeling Manifesto follows a similar format to that of the Agile Manifesto by identifying the two following guidelines:

  • Values: A value in threat modelling is something that has relative worth, merit, or importance. That is, while there is value in the items on the right, we value the items on the left more.
  • Principles: A principle describes the fundamental truths of threat modelling. There are three types of principles: (i) fundamental, primary, or general truths that enable successful threat modelling, (ii) patterns that are highly recommended, and (iii) anti-patterns that should be avoided.

  1. Have separate diagrams to describe different flows and logical components of the service Breaking a large threat model diagram down into smaller diagrams.  Smaller diagrams describe different flows and logical components that help with managing future updates (to the diagram) and abstracting away complexities. It makes it easier to follow and present the service during the threat model review meeting.    
  2. Include brief high-level descriptions to set context Sometimes it is difficult to understand the context and purpose of a specific part of the service by looking at its components and interactions. Having a brief description to set the context helps with brainstorming potential threats and risks.​
  3. ​Specify the trust boundaries for your service Trust boundaries can be on a network-level, machine-level, or domain-level, to name a few. They define divisions where the level of trust changes due to differing environmental conditions and settings. There may be security and/or privacy risks associated with data crossing trust boundaries.​
  4. Descriptive components and interactions be as descriptive (but also as concise) as possible when describing components and interactions within the service as it helps with setting context. Attributes can be set on components and data flow directions to add metadata. This metadata is used to render icons (e.g., a key to indicate an HTTPS connection) as a means, alternative to text, to convey information, and can also be used to auto-generate threats.​

Anti-patterns of threat modelling process We have seen some good implementations of threat modelling, but many more have been affected by problems. This has allowed identifying some common anti-patterns. 1. Forcing tools to do what they were not intended for. We need to know what characteristics to look for depending on the maturity of the overall solution. Experts use different features than novices. 2. Trying to achieve perfection. Analysis tends to focus on completeness rather than knowing how much is “good enough.” 3. Using cut and paste rather than thinking about the assumptions that went into a previous threat model. 4. Adopting a rigid threat modelling process for all projects without discriminating on scope or relevance. 5. Focusing on a diagram-based language. In the end, it is a tool; if it works for you, go for it. Otherwise use something else. Infrastructure teams, for example, might find tables work better (a list of objects that can relate to properties). 6. Thinking of threat modelling only as a technical activity and ignoring risk, use/ misuse cases, and abuse cases. 7. Thinking of a threat modelling diagram as the final goal. In fact, it is just a starting point. 8. Neglecting a feedback loop to update the threat model. The model should be living and maintained. 9. Neglecting to factor in business risk priorities during threat analysis. 10. Inability to identify a consistent risk definition to allow for comparisons between different systems. 11. Lack of diversity in POVs. By not involving a broad group of stakeholders, there is a reliance on personal bias and assumptions about components or libraries based on previous experience. 12. Reliance only on a checklist approach rather than combining with appropriate analysis. 13. Blind acceptance of unknown system components without taking the time to conduct an in-depth study of the gaps. 14. Focusing on development practices and pitfalls instead of limiting the scope to design. 15. Being fully dependent on abstract knowledge bases and knowledge bases. In fact, they do not provide business context and remain at an abstract level. 16. Focus on the parts instead of the whole or vice versa. 17. Making everything a high priority for fear of having mitigations dismissed as unnecessary. 18. Blindly adopting best practice security guidance as mitigations without linking to threats. 

Threat Modeling has a lot of potentials. We can see an increase in interest in this practice, lately. But Threat Modeling as it is nowadays has also important gaps that need to be addressed. The risk is to get into a Peak of Inflated Expectations, which would be followed very soon by a Trough of Disillusionment. 

  • Explore fundamental properties and mechanisms for securing data and system functionality
  • Understand the relationship between security, privacy, and safety
  • Identify key characteristics for assessing system security
  • Get an in-depth review of popular and specialized techniques for modelling and analyzing your systems
  • View the future of threat modelling and Agile development methodologies, including DevOps automation
  • Find answers to frequently asked questions, including how to avoid common threat modelling pitfalls

Values

We have come to value:

  • A culture of finding and fixing design issues over checkbox compliance.
  • People and collaboration over processes, methodologies, and tools.
  • A journey of understanding over a security or privacy snapshot.
  • Doing threat modelling over talking about it.
  • Continuous refinement over a single delivery.

Principles

We follow these principles:

  • The best use of threat modelling is to improve the security and privacy of a system through early and frequent analysis.
  • Threat modelling must align with an organization’s development practices and follow design changes in iterations that are each scoped to manageable portions of the system.
  • The outcomes of threat modelling are meaningful when they are of value to stakeholders.
  • Dialogue is key to establishing the common understandings that lead to value, while documents record those understandings, and enable measurement.

What information to include?

  • ​​Components

    All components that interact, or are involved within your service should be included in your Threat Model diagram.  ​This includes components like storage resources, virtual machines, etc.  

  • ​Data Flow Directions

    Specify the interactions and exchange of information between components, including the direction of data flow. 

  • ​Trust boundaries

    ​When data flows intersect a particular boundary (network, machine boundary, domains, etc.), a trust boundary will need to be specified. This can be represented as a line, dividing the ends of a data flow, or a self-contained "box" containing the relevant components and interactions.

1. Define the Scope:

  • Clearly define the scope of the threat modeling exercise, including the system, application, or process being analyzed, as well as the objectives and constraints.

2. Identify Assets:

  • Identify the assets that need to be protected, such as data, intellectual property, infrastructure, and personnel.

3. Create a System Overview:

  • Develop an understanding of the system architecture, including components, data flows, trust boundaries, and dependencies.

4. Identify Threats:

  • Brainstorm potential threats and attack vectors that could exploit vulnerabilities in the system. Consider various threat categories, including external attackers, insiders, and environmental threats.

5. Assess Risks:

  • Evaluate the likelihood and potential impact of each identified threat. Consider factors such as the value of the asset, the capabilities of the attacker, and the effectiveness of existing security controls.

6. Prioritize Threats:

  • Prioritize threats based on their severity, likelihood, and potential impact on the organization. Focus on addressing high-priority threats that pose the greatest risk.

7. Mitigation Strategies:

  • Develop mitigation strategies to address identified threats. This may involve implementing security controls, such as encryption, access controls, intrusion detection systems, and security monitoring.

8. Validate Assumptions:

  • Validate assumptions and hypotheses through testing, validation, and peer review. Use techniques such as penetration testing, vulnerability scanning, and code review to identify potential weaknesses and validate the effectiveness of mitigation strategies.

9. Document Findings:

  • Document the findings of the threat modeling exercise, including identified threats, risk assessments, mitigation strategies, and any recommendations for improvement.

10. Incorporate into Development Lifecycle:

  • Integrate threat modeling into the software development lifecycle to ensure that security considerations are addressed early and throughout the development process. This may involve incorporating threat modeling into design reviews, code reviews, and testing activities.

11. Review and Update Regularly:

  • Regularly review and update the threat model to account for changes in the system, technology landscape, and threat landscape. Threat modeling should be an ongoing process rather than a one-time activity.

12. Continuous Improvement:

  • Continuously improve the threat modeling process based on lessons learned, feedback, and emerging best practices. Encourage collaboration and knowledge sharing among team members to enhance the effectiveness of threat modeling efforts.

By following this game plan, organizations can systematically identify, prioritize, and mitigate potential threats, thereby enhancing the security posture of their systems and applications. Threat modeling serves as a proactive approach to cybersecurity, helping organizations anticipate and address security risks before they can be exploited by adversaries.

Conclusion

Threat modelling is one of the most essential--and most misunderstood--parts of the development lifecycle. Whether you're a security practitioner or a member of a development team, this book will help you gain a better understanding of how you can apply core threat modelling concepts to your practice to protect your systems against threats. Next Steps 1. Determine your current state: Assess prior threat models, understand the business objectives, and assess the level required for the practice, all these will help us determine the maturity level of your practice. Obtaining the maturity level will help us ask the right audit questions and obtain the required outcome. 2. Determine the right future state for you: Select the right tools and integrations based on costing and feasibility with current tools, and optimise effectiveness with current processes. Emphasis should be on optimizing the quality of threat modelling. You don’t need to implement the highest level of maturity, focus on what makes the most sense. 3. Implement the roadmap: Prioritize the activities to achieve quick wins and then gradually expand into elements for your future state. Look for additional opportunities to further increase and contextualize your threat modelling practice by onboarding other services surrounding the tools described in this document.

Resources

 

Comments are closed