Cloud Border Visibility

Maintaining network visibility is one of the biggest concerns in moving to the cloud. Fortunately, many traditional tools and techniques still work in a cloud environment. Network visibility is a broad topic. However, in this post, we will discuss maintaining network visibility at your cloud border.

Virtual Private Clouds

Amazon Web Services (AWS) and Microsoft Azure offer the capability of segmenting your infrastructure services into a private “virtual” network. In AWS this is called a Virtual Private Cloud (VPC), while in Azure it’s called a Virtual Network (VNet). In each platform, the capabilities are virtually identical.

Private Networks (as we’ll refer to them) allow you to segment your assets into a “virtual network.” These Private Networks allow you to create subnets, access control lists (ACL), route tables, and more. The Private Network itself can also have its own private IP space (RFC 1918) and a VPN gateway. This allows for – among other things – large hybrid cloud configurations.

At the border of your Private Network, you can place a simple cloud-provided Network Address Translation (NAT) gateway instance and route your Internet traffic to and from your network. To summarize, VPCs give the network engineer the appearance of a traditional network infrastructure.

Border Visibility

The problem with this configuration is in how access is controlled and reported at the border of the Private Network. Both AWS and Azure offer quick solutions to route traffic in and out of the network. These solutions act like stateful firewalls, simply brokering access to your network based on simple ACL rules.

AWS and Azure both have the ability to log Private Network firewall events. Using VPC Flow Logs (AWS) and Azure Diagnostics, it’s possible to pull firewall logs, as well as other security and operational metrics in to an existing log collection platform. However, there are a few capabilities still missing in this configuration.

First, the Cloud Service Providers’ gateway solutions (or simple public IPs, in the case of Azure) don’t provide the ability to inspect ingress or egress traffic using modern technologies. Unfortunately, promiscuous packet capture doesn’t work within these cloud environments. Therefore, activities such as layer-7 inspection (e.g. Next-Generation Firewall), network intrusion detection/prevention (IDS/IPS), and user behavior analytics are not possible unless you’re in-line with the communications channel.

Additionally, Cloud Service Providers’ NAT gateway solutions are proprietary and don’t fit in with the usual on-premises firewall solutions. For example, if your organization uses Palo Alto firewalls and manages them with Panorama, the cloud firewall device would not be able to be managed in the same interface. This makes configuration management and control more difficult for both the security ops and compliance teams.

In short, native Cloud Service Provider gateway solutions aren’t cut out for modern enterprise deployments. However, we routinely see these virtual gateways deployed in enterprise configurations.

Closing the Gap

Fortunately, there are other options available. Vendors like Palo Alto, Fortinet, Sophos, and CheckPoint have released their own virtual Unified Threat Management (UTM) appliances. The first step in closing this gap is – of course – using one of these enterprise appliances. If possible, you should choose one that matches your on-premise firewalls to help with management continuity.

But that’s not the end of the story.

Deploying a virtual UTM appliance is easy. Unfortunately, properly configuring the Private network is a step that many skip. Each Private network subnet (in both AWS and Azure) will need to be properly routed through this new UTM. Complicating this further, subnets in both AWS and Azure are all locally routable by default. That means, without configuring overriding those default routes between subnets, your new UTM can’t segment your networks. In AWS, that’s rather easy; but in Azure, this requires some PowerShell work. The effects of not configuring your routes properly can range from not working to evading the UTM; not something we want after all this work.

In summary, the subnets within the Private Networks must still be isolated from one another with ACLs or NSGs, and route tables must specifically route traffic through the UTM. In a future post we’ll go over specifically how to properly configure a VPC in AWS and a VNet in Azure using a UTM appliance.


The native cloud infrastructure solutions do not provide the expected level of visibility needed for enterprise analysis. Furthermore, achieving that level of visibility is not as straightforward as we would like it to be. It’s important that security and network engineers take their time to architect the infrastructure, create (and analyze!) threat models, and to thoroughly test the cloud infrastructure.

About GuidePoint Security

GuidePoint Security LLC provides customized, innovative and valuable information security solutions and proven cyber security expertise that enable commercial and federal organizations to successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Headquartered in Herndon, Virginia, GuidePoint Security is a small business, and classification can be found with the System for Award Management (SAM). Learn more at: