Threat Modeling

CSP can threat model your cloud environment for better visibility and reducing risk

Identify, predict and define threats across the entire attack surface to make proactive security decisions and minimize overall risk.

Quick Contact

Threat Modeling

Threat Modeling is a software design analysis process that looks for security weaknesses or vulnerability in software, hardware, networks, architecture, business processes, and business automation from an adversarial perspective. Adversaries have limits on their time, money, technical abilities, means, motives and opportunity. And finally, not every attack on a business has a consequence. Threat modeling looks for this ‘trifecta’ (the logical “and” conditions) where the attacker, the vulnerability and the consequences impact the business and then works with business leadership to establish the correct security controls for the business risk appetite for every single ‘trifecta’ that is identified.








The cyber security team then communicates these requirements to development and test, and then begins working with development and test to automate those security controls requirements to ensure they never get out of development and into production.  This is a continuous process as the business does not stand still but is in a state of constant adaptation.

Subsequent activities including application and network penetration testing, code reviews to ensure that the issues identified during threat modeling have not found their way into production. It is very important that this be done by third parties, as we want independent verification to verify that nothing has been inadvertently overlooked. Because that independent verification will not have the benefit of a threat model, that independent verification has no context regarding what they have identified. If you have a threat model you can now quickly verify the context of what was found and if it has already been identified and if it has a consequence to the business, and in doing so – application and network penetration testing become much more valuable exercises as they identify inadvertently overlooked risks, and confirm the value of what the security team is providing the business.


Threat modeling is a highly misunderstood critical process, often thought to be part of the development process which is true, but it is only half the story, it is also a critical cyber security business management tool. Let me start by examining some common friction points:

  • Security budgets, and expertise are universally stressed
  • The way a business delivers value to its customers is unique

Due to these 3 facts, where and what the business uses those security dollars is absolutely critical when security is a business requirement because we can not afford to protect everything. In fact this is true even on a nation state level.

Threat modeling in the process & procedure by which we identify the critical business processes that deliver utility to the customer, and protecting that process to ensure that it can not be disrupted by the inherent risks in that process. It is worth noting that these risks come in two flavors, those that are caused by humans to the business process either intentionally or by error, and protecting humans from the automation when they malfunction. The first is commonly known as security, and the later is quality or safety and they are two sides of the same coin.

This also allows management and the cyber security team to apply security controls with precision to the business unique value proposition. This is in sharp contrast with typical security controls which create a type of technical debt, where the security control is costing the business a fixed cost over time in order to maintain the security of a depreciating asset. This happens because security is time based, as most utility depreciates over time. This is a very common issue and often creates additional risks as people really quickly learn to ignore the legacy controls allowing them to become vectors attackers can use to gain unauthorized access to the business.

Threat modeling is also for developers, whom informed by a macro picture of the system are able to make better tactical decisions about when they need to worry about the security of the business process they are developing. In this way the developer doesn’t spend time and money on process that require less intervention and does not fail to apply interventions when they are required.

And finally, if you have heard of DevSecOps, DevOps, or CI/CD then threat modeling will additionally allow your security team to build an immune system specific to the businesses value delivery process by automating those security checks so they happen prior to deployments ensuring that security issues are addressed at the least expensive point in development rather than after the deployment when it is often very expensive, and sometimes impossible to correct.

Conceptually, the threat model process is a simple one. However, in practice it is more complicated as it is a collaborative work with the client. Additionally, because it is an ongoing process, the business really must own this process. So, while we keep it simple as simple as possible for our clients it will take time and repetition to get a solid threat model that accurately depicts your organization’s environment and/or system being threat modeled.

  • We define the scope and depth of analysis (Target of Evaluation)
    • This is often difficult to do, but a good starting point is defining scope by what a single development team works on. This is just a starting point, however, and you will need to work with the stakeholders to determine a reasonable scope.
    • We define either known attackers, or develop attacker persona that represent the ‘capabilities of the attacker’ that the business is concerned about.
  • Gain understanding of what is being threat modeled
    • Interview of all stakeholders of the system/software being threat modeled
    • Decompose and model the software/systems (control flow diagram)
  • Model the attack possibilities (most fun for us)
    • Identify the assets, security controls, attacker personas, and threat agents
    • Juxtapose the attack possibilities and software/system models
  • Threat Model Interpretation
    • Produce all attacks and scenarios discovered in the previous phase
  • Produce a traceability matrix for reporting the attacks
    • Propose mitigations
  • System Threat Models
    • Hollisctic view of application/system security posture
    • Considers both the application and infrastructure (on prim or cloud
    • Build roadmap for additional security activities
  • Protocol/API Threat Models – nothing rests here!
    • Analysis of message structure and component interaction
    • Message order or flow
    • Documentation validation of APIs

Quick Contact