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.

Summary

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: www.guidepointsecurity.com.

Going to RSA? Start it Off Right.

Come meet GuidePoint Security, CloudPassage, Co3Systems and Kaspersky at the GuidePoint Security Social Hour.

When:  Monday, February 24, 2014 from 6:00 PM to 8:00 PM (PST)

Where: John Colins
138 Minna St
San Francisco, CA 94105

GuidePoint Security works with these partners to help organizations use the following solutions to address today’s most challenging information security risks.

CloudPassage addresses the number one inhibitor to cloud adoption – security. They provide server security products purpose-built for dynamic public and hybrid cloud hosting environments.

Kaspersky is one of the fastest growing IT security vendors in the world. Firmly positioned as one of the top four leading vendors of security solutions for endpoint users.

Co3 Systems is an Incident Response Management platform. From privacy breaches, to malware outbreaks, to system intrusions, to Distributed Denial-of-Service (DDoS) attacks – they automate incident response management.

GuidePoint Security uses their expertise to lead security innovation by helping clients recognize threats, understand solutions, and mitigate risks throughout their IT environment by determining which solutions fit their clients’ needs. GuidePoint Security offers the people, processes, technologies and oversight that deliver results to your organization.

Make sure to visit the GuidePoint Security Social Hour and talk to the experts and discuss the latest and greatest risks, trends and technologies in information security.

For additional information about the GuidePoint Security Social Hour, visit http://gpsec.me/1bRwdNH and for more information about the RSA Conference, visit http://gpsec.me/1gdWsQS.

About GuidePoint Security

GuidePoint Security provides customized, innovative and valuable information security solutions that enable commercial and federal organizations to more successfully achieve their security and business goals. By embracing new technologies, GuidePoint Security helps our clients recognize the threats, understand the solutions, and mitigate the risks present in their evolving IT environments. Learn more at www.guidepointsecurity.com.

Egress Controls in Amazon’s AWS Virtual Private Cloud (VPC)

I recently had an in-depth conversation with a client discussing security best practices in Amazon’s Web Services (AWS) Infrastructure-as-a-Service (IaaS). Specifically, the client was interested in applying egress controls to their web, application, and database tiers. Given the sensitivity of the data contained within their AWS application, my client’s largest concern was limiting a potential breach to prevent a successful attacker from exfiltrating their application’s data.

Before diving into my recommendations, it’s important to understand two key security controls provided by AWS. Those who’ve worked with AWS EC2 instances should be familiar with Security Groups. For those of you who aren’t, Security Groups equate to firewall rules that are applied to a specific (or group of) EC2 instances. What some of you may not know is that Security Groups actually perform stateful inspection (this is important to those of you with PCI implications). When your application is architected directly in EC2 (not within a Virtual Private Cloud or VPC), Security Groups can only be applied to inbound traffic. Obviously, this doesn’t help with my client’s objective of implementing egress controls.

AWS Security Group Inbound Rules

The second security control provided by AWS is Network Access Control Lists or Network ACLs. Network ACLs differ from Security Groups in that they are only available within VPCs and are generally intended to be applied to networks rather than individual EC2 instances within a VPC. For example, with Network ACLs it is common that you would say that only 1433/tcp (MS SQL) is allowed from your public subnet to your private network. While utilizing a /32 netmask will allow you to implement Network ACLs for specific hosts, you should note that Network ACLs are NOT stateful (again, remember Security Groups are). This requires you to implement matching inbound and outbound Network ACL rules.

AWS Network ACLs

So back to egress controls. Regardless of your application’s architecture within AWS (just EC2 instances or utilizing a VPC), you can apply egress controls directly on your EC2 instances (on the OS itself). However, this often increases the overhead of the EC2 instances to levels unacceptable to development teams. So what other options do we have? A lesser-known feature of VPCs is the ability to apply outbound rules to your Security Groups. For example, you can say that your MS SQL server is not allowed to communicate directly with the Internet, but is only allowed access to 80/tcp and 443/tcp for Windows Updates through a NAT server in your public subnet. Such a setup accomplishes the goal of implementing egress controls on your EC2 instances while not increasing their overhead.

AWS Security Group Outbound Rules

After explaining the enhanced security features of an AWS VPC, my client made a case to his development team in support of re-architecting the application inside of a VPC. Fortunately for my client, the security team was engaged during the design phase of their organization’s AWS application and implementing such a change was a lot less painful than re-designing an existing application. That isn’t to say that such a redesign can’t be successfully performed on an established application, but we all know it’s a lot easier to do earlier in the game.

To recap what we’ve discussed…

  • Security Groups are analogous to firewall rules and can be applied to specific EC2 instances (or groups of instances)
  • Security Groups provide stateful inspection
  • Standard EC2 instances (those not part of a VPC) allow only inbound Security Group rules
  • Network ACLs can only be applied to entire networks (subnets)
  • Network ACLs do NOT provide stateful inspection
  • Network ACLs are only available within VPCs
  • VPCs enable outbound rules to be added to Security Groups and can be applied directly to individual or groups of EC2 instances that are part of a VPC
  • Inbound and outbound Security Groups do NOT add overhead to the EC2 instances they are applied to

Hopefully you found this information helpful and it results in your further investigation into VPCs when looking at how to apply egress controls to your AWS applications.