Limitations of Azure Security Groups: Policy Creation Across Multiple vNets

In our previous post, we discussed the limitations of Cloud Security Groups and flow logs within a specific vNet. In today’s post, we will focus on another specific scenario and use case that is common to most organizations, discussing Cloud Security Group limitations across multiple regions and vNets. We will then deep dive into Guardicore’s value in this scenario.

In a recent analysis, Gartner mentions the inherent incompatibility between existing monitoring tools and the cloud providers’ native monitoring platforms and data handling solutions. Gartner explains that an organization’s own monitoring strategies must evolve to accommodate these differences.

As the infrastructure monitoring feature sets offered by cloud providers’ native tools are continuing to evolve and mature, Gartner comments that “Gaps still exist between the capabilities of these tools and the monitoring requirements of many production applications… Remediation mechanisms can still require significant development and integration efforts, or the introduction of a third-party tool or service.”

To understand the challenges faced when using native monitoring tools, in this post I’ll again share details from an experiment that was performed by one of our customers. The customer created a simulation of multiple applications running in Azure, and created security policies between these applications.

The lab setup

Let’s look at the simulation environment. There are multiple Azure subscriptions, and within each subscription, there is a Virtual Network (VNet). In this case, SubscriptionA is the Production environment based in the Brazil region, and SubscriptionB is the Development environment, based in West Europe. Each has its own vNet. Both VNets are peered together.

ASGs:
The team created 3 Application Security Groups (ASGs). Note that the locations correspond to the locations used for the Virtual Networks (VNets).

The customer wanted to test the following scenario:
Block all communication from the CMS application over port 80, unless CMS communicates over this port with the SWIFT and Billing applications.

However, CMS application servers reside in the West Europe region, and the Swift and Billing application servers reside in the Brazil South region.

In this scenario, with 2 Virtual Networks (vNets), our customer wanted to know, will an Application Security Group (ASG) that exists in one Virtual Network (VNet), be available for reference in the opposite Virtual Network’s (vNet’s) Network Security Group (NSG)? Would it be possible to create a rule with an ASG for the CMS App servers to the SWIFT & Billing applications even though they are in separate vNets?

The limitations and constraints of using Azure Security Groups were immediately clear

The team attempted to add a new inbound security rule from the CMS servers’ ASG to the SWIFT servers’ ASG. As you can see from the screenshot, the only Application Security Group (ASG) that appears in the list of options, is the local one, CMS servers ASGs.

Let’s explore what happened above. According to the documentation provided by Azure:
Each subscription in Azure is assigned to a specific, single, region.
Multiple subscriptions cannot share the same vNet.
NSGs can only be applied within a vNet.

Thus each region must contain a single vNet, and each region will have its own specific NSGs in place. The team attempted a few options to troubleshoot this issue using Security Groups.

First, they attempted to use ASGs to resolve this and create policies cross regions. However, the customer came up against the following Azure rule.
All network interfaces assigned to an ASG have to exist in the same vNet. You cannot add network interfaces from different vNets to the same application security group.
If your application spans cross regions or vNets, you cannot create a single ASG to include all servers within this application. A similar rule applies when application dependencies cross regions. ASGs therefore couldn’t solve the problem with policy creation.

Next, the customer tried combining two ASGs from different vNets to achieve this policy. Again, Azure rules made this impossible, as you can see below.
If you specify an application security group as the source and destination in a security rule, the network interfaces in both application security groups must exist in the same virtual network. For example, if AsgLogic contained network interfaces from VNet1, and AsgDb contained network interfaces from VNet2, you could not assign AsgLogic as the source and AsgDb as the destination in a rule. All network interfaces for both the source and destination application security groups need to exist in the same virtual network.

Simply put, according to Azure documentation, it is not possible to create an NSG containing two ASGs from different vNets.

Thus if your application spans multiple vNets, using a single ASG for all application components is not an option, nor is combining two ASGs in an NSG. You’ll see the same problem when application dependencies cross regions, like in the case of our CMS, SWIFT and billing applications above.

Bottom line: It is not possible to create NSG rules, using ASGs for cross-region and vNet traffic.

Introducing Guardicore to the Simulation

The team had an entirely different experience when using Guardicore Centra to enforce the required policy settings.

The team had already been using Guardicore Centra for visibility to explore the network. In fact, this visibility had helped the team realize they needed to permit the CMS application to communicate with SWIFT over port 8080 in the first place. The team was therefore immediately able to view the real traffic between both regions/vNets and within each region/vNet, visualizing the connections between the CMS application in West Europe and the SWIFT and Billing application in the Brazil region.

With Guardicore, policies are created based on labels, and are therefore decoupled from the underlying infrastructure, supporting seamless migration of policies alongside workloads, wherever they may go in the future. As the customer planned to test migrating the CMS application to AWS, policies were created based on the environments and applications, not based on the infrastructure or the underlying “Cloud” context.

A critical layer added to Guardicore Centra’s visibility is labeling and grouping. This context enables deep comprehension of application dependencies. While Centra provides a standard hierarchy that many customers follow, our labeling approach is highly customizable. Flexible grouping enables you to see your data center in the context of how you as a business speak about your data center.

Labeling decouples the IP address from the segmentation process and enables application migration between environments, seamlessly, without the need to change the policies in place. With this functionality, the lab team were able to put the required policies into place.

 

One of the most impactful things we can do to make Guardicore’s visualization relevant to your organization quickly, is integrate with any existing sources of metadata, such as data center or cloud orchestration tools or configuration management databases. In the case above, all labels were received automatically from the existing Azure orchestration tags.

As Guardicore does not rely on the underlying infrastructure to enforce policies, such as Security Groups or endpoint firewalls, policies are completely decoupled from the underlying infrastructure. This enables the creation of a single policy across the whole environment, and covers those use cases that are cross environment, too. In the case of Azure, it allowed our customer to simulate policies that cross vNet and Region, while doing so seamlessly from a single pane of glass.

Guardicore Now Available in the Microsoft Azure Marketplace

Microsoft Azure customers worldwide now gain access to the Guardicore Centra security platform to take advantage of the scalability, reliability, and agility of Azure to drive application development and shape business strategies

Boston, Mass. and Tel Aviv, Israel – October 8, 2019 – Guardicore, a leader in internal data center and cloud security, today announced the availability of its Guardicore Centra security platform in the Microsoft Azure Marketplace, an online store providing applications and services for use on Azure. Guardicore customers can now take advantage of the scalability, high availability, and security of Azure, with streamlined deployment and management.

Guardicore Centra helps accelerate security migration from an on-premises data center to Azure. Additionally, it supports hybrid clouds and can protect legacy applications for those customers that prefer to keep such applications in their traditional data centers while migrating other applications to Azure. The Guardicore Centra security platform is also among the first cloud and data center micro-segmentation solutions in the market to achieve Microsoft IP Co-Sell status. This designation recognizes that Guardicore has demonstrated proven technology and deep expertise that helps customers achieve their cloud security goals.

“By implementing Guardicore Centra, combined with the range of powerful tools from Microsoft Azure, customers are able to gain the highest level of visibility and implement micro-segmentation for enhanced security. And they can do it faster and more effectively than traditional firewall technology with our simple-to-deploy overlay that can go to the cloud, stay on-premise, or do both at the same time,” said Pavel Gurvich, CEO and cofounder, Guardicore. “Achieving this status demonstrates our commitment to the Microsoft partner ecosystem and our ability to deliver innovative solutions that help forward-thinking enterprise customers to secure their business-critical applications and data quickly, reduce the cost and burden of compliance, and secure cloud adoption.”

Sajan Parihar, Senior Director, Microsoft Azure Platform at Microsoft Corp said, “We’re pleased to welcome Guardicore and the Guardicore Centra security platform to the Microsoft Azure Marketplace, which gives our partners great exposure to cloud customers around the globe. Azure Marketplace offers world-class quality experiences from global trusted partners with solutions tested to work seamlessly with Azure.”

The Azure Marketplace is an online market for buying and selling cloud solutions certified to run on Azure. The Azure Marketplace helps connect companies seeking innovative, cloud-based solutions with partners who have developed solutions that are ready to use.

About Guardicore

Guardicore is a data center and cloud security company that protects your organization’s core assets using flexible, quickly deployed, and easy to understand micro-segmentation controls. Our solutions provide a simpler, faster way to guarantee persistent and consistent security — for any application, in any IT environment. For more information, visit www.guardicore.com.