NEW VIDEO: Security Weekly - How to protect AWS metadata services (used in Capital One breach). Watch now!

Managing Your Multi-Cloud Network

So you’re moving to the cloud! As a network or security operations professional, it’s your job to make certain the move goes smoothly. Therefore, before making any large-scale changes, you need to establish a sound network security model that allows for a successful migration.

The first thing you’ll need to do in this process is determine the connectivity model needed between your existing on-premises environment and the cloud provider(s) you’ve chosen. Today, there are numerous options for this. In most cloud provider environments you can establish a point-to-point IPSec tunnel between your gateway and a termination point, you can broker your connection through a telecommunications provider “hub” (using MPLS or Software-Defined WAN technologies), or you can purchase a direct link to the provider using a leased line service like Amazon’s DirectConnect or Microsoft’s ExpressRoute.

Next, you’ll need to evaluate your options for controlling traffic to and from the cloud, as well as within it. Again, there are numerous options to choose from, depending on your requirements. You can:

  • Use traditional Next Generation Firewalls (NGFWs) ported to a virtual appliance model;
  • Leverage cloud-native access controls like Security Groups (AWS) and Network Security Groups (“NSGs” in Microsoft Azure); and
  • Implement granular microsegmentation using third-party tools to achieve a zero trust model of access management.

Today, options for network security in the public cloud are plentiful, and a mature organization will likely have several different technologies in place to create a defense-in-depth network security architecture.

Setting up a single-cloud environment

In a single-cloud environment, traditional network management tools might suffice for some elements of this strategy. Incorporating firewall management and analysis tools to monitor and assess cloud-native access controls may be a good idea if you work in a large organization that manages a diverse array of cloud accounts and network segments. Peering relationships between network zones can also be established and monitored fairly readily.

However, even in a single-cloud environment there are numerous potential limitations to this approach including:

  • Downtime concerns: If your cloud provider experiences a major issue like an outage or a breach, it could lead to a single point of failure that takes down network access and resources.
  • Security and privacy: In any single-cloud choice you’ll need an encryption strategy and to review the provider’s internal controls for adherence to basic tenets of information security and privacy.
  • Vulnerability to attacks: If a cloud provider is exposed to vulnerabilities, it may cause a ripple effect on the organizations hosted there, potentially resulting in a data breach of the tenants’ environments.

Other issues with a single-cloud model might include finite control and flexibility in design, a limited number of resources at your disposal, and additional platform dependencies to manage. These issues, among others, are driving organizations to adopt a multi-cloud architecture that takes advantage of several different providers simultaneously.

Stay on the cutting edge. Subscribe to our blog.

Network security in a multi-cloud environment

What happens to your networking strategy when you move to a multi-cloud environment? The short answer is: almost everything, especially if you have been relying on traditional network tools. From a networking perspective, to ensure applications and services can communicate as intended and do so securely, the tools and process for managing a multi-cloud environment need to be cloud-ready. The cloud-native controls included in providers’ offerings may seem like the easiest solution.

Cloud-native controls are great baselines, but from a security perspective they may fall short of your desired state or prove difficult or unwieldy to manage and monitor. Not to mention, if your multi-cloud strategy includes various providers and you’re reliant on cloud-native networking controls like Security Groups or Network Security Groups, you’ll end up dealing with disparate sets of controls that don’t necessarily translate across environments. This can become a debilitating concern and leads some organizations back toward a single-cloud deployment, which is not always the right choice. 

In a multi-cloud model, it’s best to implement the same types of access controls in different provider environments. Doing so significantly reduces complexity and provides uniform visibility and manageability across environments.

To start planning for a multi-cloud network deployment, consider the following: 

  • Who is going to design and build each cloud provider network environment? In most organizations, a single team is responsible for all cloud architecture. However, in highly diverse organizations that are spread out geographically or by business unit, there may be distinct teams building each cloud.
  • Who will be responsible for each cloud network’s administration? Similar to the point above, will a single team or multiple teams manage the ongoing environment once the cloud infrastructure is in place?
  • What will deployment processes be for each cloud? Ideally, a single deployment model for all infrastructure will be created using a unified pipeline and tools.
  • What network security controls are available in each cloud environment? While there are some similarities between many of the leading IaaS provider controls, each offers unique services and capabilities, too. For example, Amazon Web Services offers simple stateful Security Groups and stateless, single direction Network Access Control Lists to control traffic between subnets and to/from instance workloads. Microsoft Azure, on the other hand, offers more traditional numbered firewall rule sets with their Network Security Groups.
  • Are the risk profiles different for one cloud environment vs. another? For example, Amazon Security Groups start off in a “default deny” configuration, whereas Microsoft Network Security Groups allow some traffic to communicate within a subnet and the Azure environment.
  • Does the security team have the necessary skills to manage different cloud environments, and do they understand the layering of network controls in each environment?

All of these areas need consideration, of course, but one of the most critical components of a successful multi-cloud deployment is centralization.

Centralized control for your multi-cloud model

With a multi-cloud network architecture, network and security teams are potentially facing a fragmented set of security access controls and monitoring tools that could be difficult to manage if designed and implemented uniquely in each provider environment. As such, some cloud operations teams look to multi-cloud brokers to help with centralizing and integrating all cloud management. However, enterprise network and security teams can also select a single third-party platform that can integrate across all environments. Doing so allows for centralized control of network security policy and access management regardless of the underlying cloud infrastructure.

For public cloud in particular, a more advanced strategy for implementing strong, centralized network security is zero trust microsegmentation. If you have a large presence in Amazon Web Services, Microsoft Azure, or Google Cloud Platform, for example, you are likely already using basic microsegmentation technologies:

  1. In AWS, this is implemented via Security Groups
  2. In Azure, this is implemented with Network Security Groups (NSGs)
  3. In GCP, this is implemented with Compute Engine firewall rules

The above microsegmentation tools are cloud-native and often facilitate access controls and isolation for virtual machine instances and other assets you’ve deployed in the particular cloud service environment you’re using. These tools are perfectly fine for simple use cases, but they have several limitations that should be considered. First, these are explicit to each cloud provider and could lead to more dependence on the provider than you want. Additionally, these methods of implementing microsegmentation only work in the public cloud and won’t be applicable to any on-premises assets you have in a hybrid cloud network architecture; ideally, you can make use of a single microsegmentation platform that works across all the environments you operate in. Finally, these cloud-specific controls may not scale well into hundreds and thousands of distinct assets with unique rules and policies that have to be juggled across numerous environments, and providers often have hard limits on the number of rules and access control groups you can create.

In short, provider-based controls have their place but should be considered a starting point or augmentation technique to a more central and capable network control platform. 

The need for network visibility

Aside from cloud-native network controls, one of the most critical needs for network and security teams building workloads in multiple cloud environments is enhanced visibility and insight into workload behavior and applications. It’s this visibility that largely forms the basis of a true zero trust model of microsegmentation. No cloud-specific tools provide this level of introspection and dynamic policy evaluation today, meaning that third-party tools will be needed to 1) accurately map out what types of application traffic are being seen and 2) apply a centralized policy to workloads communicating across multi-cloud and hybrid environments. For dynamic, mobile workloads, operations teams need a much more granular and nuanced access control model than simple layer 3 and 4 firewall rules — application behavior and workload alignment and affinity are vastly more important in the modern multi-cloud network.

Choosing your cloud security strategy wisely

To be sure, security teams have more options available for implementing a defense-in-depth network control architecture in multiple clouds (as well as on-premises environments) than ever before. However, not every tool or strategy is necessary to run an effective security program. Instead, security and networking teams should focus on:

  • Centralization: Tools that can capably be implemented centrally for policy creation and overall management. The easier to manage operationally, the more successful the network design will be.
  • Multi-layered microsegmentation: Traditional firewalls still have their place for enabling network connectivity between on-premises and cloud environments and may provide intrusion prevention and other necessary controls. However, they’re not enough to prevent malicious east-west traffic. Instead, security teams should implement a multi-layered microsegmentation approach that works uniformly across all operating environments.
  • Visibility: For large cloud deployments, a base implementation of some cloud provider-native controls may prove valuable, but a multi-cloud design with numerous assets will benefit from deeper application visibility that is enforced similarly in all cloud environments. This will result in centralized monitoring and reporting across environments, as well.
Dave Shackleford, Principal Consultant

Written by Dave Shackleford, Principal Consultant

Dave Shackleford is the owner and principal consultant of Voodoo Security and a SANS analyst, senior instructor, and course author. He has consulted with hundreds of organizations in the areas of security, regulatory compliance, and network architecture and engineering, and is a VMware vExpert with extensive experience designing and configuring secure virtualized infrastructures. He has previously worked as CSO for Configuresoft, CTO for the Center for Internet Security, and as a security architect, analyst, and manager for several Fortune 500 companies. Dave is the author of the Sybex book Virtualization Security: Protecting Virtualized Environments, as well as the coauthor of Hands-On Information Security from Course Technology. Recently Dave coauthored the first published course on virtualization security for the SANS Institute. Dave currently serves on the board of directors at the SANS Technology Institute and helps lead the Atlanta chapter of the Cloud Security Alliance. Dave earned his MBA from Georgia State University.