Securing Hybrid Cloud Infrastructure: Modern Threat Modeling Techniques That Actually Work

From cloud shared responsibility to attack path visualization, how should you adapt your security practice for multi-cloud and on-premise environments

For content on these topics check out my book on Application Security and Threat Modeling

Infrastructure has changed drastically in the decades since I started working in technology. We went from hosting value and services in on-site, connected infrastructure to hosting them in “the cloud”. This change in technology required us to evolve our thinking in how we define and maintain the security perimeter. In the cloud paradigm, the hard-lines of a perimeter on a network diagram had disintegrated and gave way to sets of interlocking blocks of infrastructure and services. But the cloud has been with us for quite a long time (at least in technology years) at this point. The technology has matured and organizations have an expanding menu of services and service providers to choose from. And while there was a massive push in the early days of cloud migration to go “cloud native”, most organizations today still straddle a hybrid deployment with cloud services, 3^rd party SaaS, and on-prem infrastructure.

With the hybrid adoption of cloud, the security complexity has risen. Supply chain and third-party risks have gone through the roof as new services from CSPs come online and are adopted typically before the security team is aware of them. And while there have been plenty of leaps in security tooling made available in this hybrid environment our threat models have become more complex. So, the question has become: How have we adapted our threat models to account for these varied deployment models?

When Data Centers Meet Cloud Services

One of my favorite memories from an early threat model I did was the phrase ‘car-crushing robots’ that were mixed in with human workers in a certain location. This greatly increased the risk, not just to the system, but the workers who were standing or sitting next to these robots. It was one of the early parts of my cybersecurity career, so it was one of those moments where my mindset shifted to look beyond the basic threats posed by things like SQL Injection or DDoS attacks and I began to understand the interconnected aspects of a total system and its infrastructure. Even when part of that infrastructure was a robot.

Evaluating the security of our current hybrid infrastructure environments running today requires us to consider that each component represents a potential attack vector. Servers may be vulnerable to exploitation through unpatched software, network equipment might be susceptible to adversary-in-the-middle attacks, and cloud services introduce shared responsibility models that require a clear delineation of security boundaries. And while the individual services and infrastructure that are in operation can be a source of security gaps, so can the integration points between them. Some of the most critical ones to consider are:

VPN Tunnels and Direct Connect Links where organizations establish site-to-site VPN tunnels or dedicated connections like AWS Direct Connect or Azure ExpressRoute to bridge their on-premise data centers with cloud environments, essentially creating a persistent highway between two security domains.

Identity federation between on-premise Active Directory and cloud identity providers like Azure AD, AWS IAM Identity Center, or Okta creates another critical integration point. When you federate identities, you’re essentially trusting tokens and assertions passed between systems. If an attacker compromises the identity provider or the implementation, they can potentially gain access to federated cloud services.

Hybrid Database Replication and Data Synchronization allow organizations to replicate data between on-premise databases and cloud-based data warehouses or analytics platforms. These replication mechanisms may be using native database replication, ETL pipelines, or data synchronization services and create persistent data flows between environments.

API Gateways and Microservices include a kaleidoscope of microservices distributed across on-premise and cloud environments, communicating through API gateways. An on-premise application might call cloud-based services for payment processing, while cloud applications might reach back to on-premise systems of record. Each API call crosses a trust boundary and requires authentication, but these authentication mechanisms can become security weak points.

While there are plenty of other interactions (For more examples, check out Chapter 5 of the Threat Modeling Best Practices), it should be clear that these interconnected and varied deployments can expand an attack surface. And perhaps more critically, this hybrid deployment means that instead of looking across the parking lot to see your organization’s data center, we instead review infrastructure in code and configuration on a screen.

Are we still Digitally Transforming?

Yes, digital transformation is still a thing. While you probably don’t hear the phrase as much as perhaps ten years ago, organizations today are pursuing initiatives that fundamentally reshape how they architect and deploy infrastructure. These initiatives go well beyond simple “lift and shift” migrations to a cloud environment. They’re building multi-cloud application architectures that span AWS, Azure, and Google Cloud to leverage best-of-breed services, deploying Kubernetes clusters across on-premise data centers and public clouds for consistent container orchestration, and pushing compute to the edge through CDNs and regional deployments for low-latency user experiences. AI/ML workflows are split between environments where models are trained in GPU-optimized cloud instances with vast datasets, then deployed to on-premise or at the edge for real-time inference. Security operations themselves are becoming hybrid, with cloud-based SIEM platforms ingesting logs from on-premise firewalls, cloud VPCs, and endpoint systems across both environments to provide unified visibility.

These aren’t static architectures that get designed once and left alone. Organizations continuously evolve their hybrid infrastructure as new cloud services become available, business requirements change, and technology teams gain confidence with cloud platforms.

Where does that leave us with our threat models? A threat model that accurately reflects the infrastructure today might be outdated in six months (or even 6 weeks) as new integration points are added, workloads migrate between environments, or development teams adopt new cloud services.

Understanding Where Your Security Obligations Begin

Whether you’re building a new threat model, or revisiting a current one, understanding where your security responsibility begins and your service provider’s ends. For CSPs, this is known as the shared responsibility model where a clear definition of what security, governance, and operational duties are managed by the CSP versus what the customer manages.

For example, in a financial services start-up, a basic customer portal might be deployed to AWS. In this case AWS would be responsible for securing the foundation of that deployment. The physical data centers, global network, power, cooling, hardware, and the virtualization layer that runs EC2 and RDS. AWS ensures that the hypervisor is patched, the storage systems are encrypted, and the global backbone is resilient and monitored. This is the “security of the cloud.”

The startup, however, is responsible for everything built on top of that foundation. They must harden the EC2 instance, configure the OS firewall, patch the web server, and ensure that the application code does not contain vulnerabilities such as SQL injection or insecure deserialization. They must design IAM roles with least privilege, rotate credentials, and enforce MFA for administrative access. They must configure RDS security groups, manage database users, and ensure that customer data is encrypted using the appropriate keys. This is the “security in the cloud.”

Threat Modeling Best Practices – Chapter 5

The good news is that there are security frameworks and best practices that can be used to manage the security concerns that exist in these deployments. NIST, ISO, and CSA all have guidance on securing cloud environments, but the CSPs themselves offer up best practices. For instance, AWS has the Well Architected Framework that encompasses several pillars including the Security Pillar that security practitioner should use to adapt their threat modeling methodology to incorporate cloud-specific (and possibly CSP specific) threat vectors. For each asset identified in your threat model, map it to the relevant cloud security pillars from your chosen CSP.

Visualizing How Attackers Move Through Your Environment

I’ve covered attack path analysis previously. However, here I want to show how attack paths can be utilized to “double-click” on threats found in a threat model. This is especially helpful in rapidly changing models that are updated at the pace of a cloud deployment. Keep in mind that attack paths do not replace threat modeling, but where threat modeling tells you “what can go wrong” the attack path tells you “how an attacker could actually do it”. Attack paths are typically used to pinpoint security controls through addressing specific vulnerabilities that appear in multiple attack paths or ones that target critical data or workflows. This type of approach can help align security resources more judiciously, rather than simply addressing vulnerabilities based on isolated severity ratings.

An attack path is conceptually simple: a visual representation of the steps an attacker can take through your system. However, creating effective attack path models requires the right tools and approach. For larger enterprises with complex environments, commercial tools can automatically model attack scenarios and integrate directly with your infrastructure. Some specialized tools focus narrowly on specific services like Active Directory or Entra ID. If your organization has the budget for these enterprise solutions, they’ll handle much of the heavy lifting for identifying and visualizing attack paths.

For those of us working with more constrained resources, simpler options work perfectly well. A basic drawing tool can work for creating a basic diagram. Don’t judge, but I’m perfectly fine using PowerPoint or other “blank canvas” style tools for this purpose. But there is something better. The Mitre’s Attack Flow Builder can be run in a browser or locally using Docker and it allows security practitioners to identify individual attack techniques, arrange them in logical sequences, define relationships between actions, and generate visual representations that make attack chains understandable to both technical and non-technical audiences.

Example using Attack Flow Builder

Let me walk you through a practical example using Attack Flow Builder to model an attack on a hybrid cloud environment where an organization runs workloads across on-prem infrastructure and AWS. This scenario illustrates how attackers can exploit integration points between environments to move from compromised employee credentials to sensitive data in cloud storage.

Start by initializing Attack Flow Builder with your metadata and context. Give your flow a descriptive name like “Hybrid Cloud Credential Compromise to Data Exfiltration” and add a clear description of what you’re modeling. This foundational information helps others understand the scope and purpose of your attack path when they review it later.

The attack begins with initial access. In this case, credential stuffing against the organization’s SSO portal. Create an action node in Attack Flow Builder and map it to MITRE ATT&CK technique T1110.004 (Credential Stuffing). Your description should capture the specifics: an attacker uses credentials leaked from a third-party breach to authenticate against the company’s federated identity provider. The compromised employee account has legitimate access to both on-premise systems and federated cloud services through Azure AD integration.

From there, the attacker establishes persistence by creating a new service principal in the cloud environment. This becomes your second action node, mapped to technique T1136.003 (Create Account: Cloud Account). The attacker uses their authenticated session to create a service principal with API access, generating long-lived credentials that persist even if the original compromised account’s password is changed. Connect your initial access action to this persistence action with an arrow to show the logical progression.

Next, model the privilege escalation stage. The attacker discovers that the service principal has been granted overly permissive IAM roles. Specifically, permissions to list and read from S3 buckets. Create an action for this discovery phase using technique T1069.003 (Permission Groups Discovery: Cloud Groups). The attacker enumerates accessible cloud resources and identifies S3 buckets containing customer data that were supposed to be restricted but have misconfigured bucket policies allowing broad access.

Finally, show the data exfiltration. Using the service principal credentials, the attacker accesses S3 buckets and downloads sensitive customer information to an external cloud storage service they control. Create an asset object for “Customer Data” and connect it to your exfiltration action mapped to technique T1537 (Transfer Data to Cloud Account). This visually represents how data moves from your organization’s cloud infrastructure to attacker-controlled resources, all using legitimate AWS APIs that blend in with normal cloud activity.

Throughout this process, Attack Flow Builder’s validation pane helps ensure you’ve captured all required information. The tool supports multiple export formats: save as *.afb for future editing, export as *.png for documentation and presentations, or publish as *.json for machine processing and integration with other security tools.

For a more detailed walkthrough of using Mitre Attack Flow Builder check out Threat Modeling Best Practices – Chapter 5

Remember that attack paths work best when integrated into your broader threat model as a targeted validation and prioritization tool rather than a comprehensive security analysis method. Use them to test your most critical threat scenarios and validate whether your security controls actually prevent the attack chains that pose the most risk to your organization.

The Path Forward

Cloud and hybrid infrastructure isn’t static. It’s a shifting sand of new services, additional integration points, and changing workloads between environments. What starts as a simple cloud migration for cost savings transforms into a complex multi-cloud architecture where development teams spin up serverless functions, data pipelines span multiple cloud providers, and on-premise systems integrate with cloud-based analytics platforms. A threat model that accurately captured your infrastructure six months ago might be outdated today This continuous evolution means threat modeling can’t be a one-time exercise where you document your architecture, identify some threats, and call it a day. Your threat modeling practice needs to move as quickly as your infrastructure, regularly reassessing integration points, validating that security controls still apply to new deployment patterns, and ensuring that the assumptions you made about trust boundaries remain valid as your environment changes.

This is where attack path analysis becomes particularly valuable for cloud and hybrid environments by visualizing the specific steps an attacker might take to compromise your systems. From initial access through credential theft, lateral movement, and ultimately reaching critical assets, you can test whether your security controls actually prevent the attack chains that pose the most risk to your organization. Attack paths help you move beyond theoretical threat lists and abstract security principles to concrete scenarios. These visualizations make attack chains understandable to both technical teams implementing controls and business stakeholders making risk decisions. Lastly, when integrated into your broader threat modeling methodology, attack paths provide a targeted validation tool that helps you prioritize remediation efforts based on which vulnerabilities appear in multiple attack chains and which controls, if improved, would disrupt the most critical threats to your hybrid infrastructure.

Threat modeling is still one of the most powerful tools in a security teams arsenal. When used at the right time, with the right resources, and the right tools, it can help create a system design that is secure from the start.

For content on these topics check out my book on Application Security and Threat Modeling