How to Create a Threat Model for Cloud Infrastructure Security

Our Motto is: Threat Modeling: The sooner the better, but never too late. — OWASP

The practice of creating a threat model can help teams proactively understand and develop a strategy for managing the possible vulnerabilities their organization faces, instead of waiting until after an incident occurs. OWASP defines threat modeling as “a procedure for optimizing security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system.”

Cloud Native Now

SecOps teams can benefit from creating a threat model for cloud infrastructure, and defining an approach to operationalizing, hardening, and automating security throughout the software development lifecycle. While it’s best to build security into the design of your systems at the outset, remember the motto: “Threat Modeling: The sooner the better, but never too late.”

Let’s walk through how to get started.

Step 1: Get the Right Team in Place

A threat modeling exercise should involve a cross-disciplinary team, with a security team member serving as the lead. The security team, application developers, site reliability engineers, the ops team, and business owners might all be potential candidates for participating in the process.

Leveraging the expertise of multiple groups involved in the software development, testing, and delivery process will lead to a more holistic view of what you’re working on, what could go wrong, and how to reduce risk over the long run.

Step 2: Model Your System

Once your team is assembled, it’s time to figure out what the boundaries of the system are — is it a single micro service? Is it your web front end? Be careful not to make the system boundary too big — as you start to widen the boundary, it gets harder to model.

OWASP recommends looking at the following factors:

  • The trust boundaries to and within the system
  • The actors who interact within and outside of the trust boundaries
  • Information flows within and to and from the trust boundaries
  • Information persistence within and out of trust boundaries
  • Potential threats and vulnerabilities to these trust boundaries
  • Threat agents that can exploit these vulnerabilities
  • The impact of exploitation of a vulnerability by a threat agent

Step 3: Consider Risk Mitigations

Now that you have a list of assumptions about your system, is there anything you can mitigate off the bat? Are there things that enforce system boundaries that, if not configured correctly, could affect your threat model?

For example, take a particularly close look at your cloud infrastructure control plane to start. In a recent study, Threat Stack found that 73% of companies have at least one critical security misconfiguration — maybe your security groups are wide open. “Critical” is defined as configuration lapses that enable an attacker to gain access directly to private services or the AWS console, or that could be used to mask criminal activity from monitoring technologies. The volume of high-profile breaches happening via open infrastructure ports is evidence that misconfigurations are continuing to negatively impact organizations.

Once your team has figured out what your system threat model is and has then refined this list to distinguish what’s most important and applicable to your business — it’s time to create a remediation plan.

Step 4: Make a Plan and Assign “Risk Owners”

The first step in creating a remediation plan is to rank the severity of each threat (see an example ranking methodology in our recent risk assessment blog post). From there, assign a team member to address these threats in order of severity, starting with the most severe. Having “risk owners” ensures that there’s accountability for addressing the threats your team has uncovered.

In as many cases as possible, try to operationalize or automate security into a process to prevent vulnerabilities from recurring in the future and to ensure that you’re using a repeatable, consistent approach across your organization to risk reduction and mitigation rather than in-the-moment, ad hoc tactics. Threat Stack, for example, has automated processes such as role-based access control and public key authentication to keep systems secure without sacrificing the efficiency of the team.

Continuously Monitor Your Cloud Infrastructure

The process of threat modeling is never truly “done.” It’s crucial to continuously monitor your cloud infrastructure and to assess new and existing risks on a regular basis. With increasingly sophisticated attacks to infrastructure security appearing daily, an up-to-date threat model can ensure that your organization’s security posture is as robust as possible.

To find out how the Threat Stack Cloud Security Platform® can help your team continuously monitor and address infrastructure security threats, sign up for a demo today, and to get a clear insight into the current maturity of your organization’s security, complete our Cloud SecOps Maturity Assessment.

*** This is a Security Bloggers Network syndicated blog from Blog – Threat Stack authored by Pat Cable. Read the original post at:

Cloud Capabilities Poll