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.

Trials and Tribulations – A Practical Look at the Challenges of Azure Security Groups and Flow Logs

Cloud Security Groups are the firewalls of the cloud. They are built-in and provide basic access control functionality as part of the shared responsibility model. However, Cloud Security Groups do not provide the same protection or functionality that enterprises have come to expect with on-premises deployments. While Next-Generation firewalls protect and segment applications on premises’ perimeter (mostly), AWS, Azure, and GCP do not mirror this in the cloud. Segmenting applications using Cloud Security Groups is done in a restricted manner, supporting only layer 4 traffic, ports and IPs. This means that to benefit from application-aware security capabilities with your cloud applications you will need an additional set of controls which is not available with the built-in functionality of Cloud Security Groups.

The basic function that Cloud Security Groups should provide is network separation, so they can be best compared to what VLANs provides on premises, Access Control Lists on switches and endpoint FWs. Unfortunately, like VLANs, ACLs and endpoint FWs, Cloud Security Groups come with similar ailments and limitations. This makes using them complex, expensive and ultimately ineffective for modern networks that are hybrid and require adequate segmentation. To create application aware policies, and micro-segment an application, you need to visualize application dependencies, which Cloud Security Groups do not support. Furthermore, if your application dependencies cross regions within the same cloud provider or between clouds and on premises, application security groups are ineffective by design. We will touch on this topic in upcoming posts.

In today’s post we will focus on a specific scenario and use case that is common to most organizations, discussing Cloud Security Groups and flow logs limitations within a specific vNet, and illustrating what Guardicore’s value is in this scenario.

Experiment: Simulate a SWIFT Application Migration to Azure

Let’s look at the details from an experiment performed by one of our customers during a simulation of a SWIFT application migration to Azure.

Our customer used a subscription in Azure, in the Southern region of Brazil. Within the subscription, there is a Virtual Network (vNet). The vNet includes a Subnet 10.0.2.0/24 with various application servers that serve different roles.

This customer attempted to simulate the migration of their SWIFT application to Azure given the subscription above. General segmentation rules for their migrated SWIFT application were set using both NSGs (Network Security Groups) & ASGs (Application Security Groups). These were used to administrate and control network traffic within the virtual network (vNet) and specifically to segment this application.

Let’s review the difference:

  • An NSG is the Azure resource that is used to enforce and control the network traffic. NSGs control access by permitting or denying network traffic. All traffic entering or leaving your Azure network can be processed via an NSG.
  • An ASG is an object reference within a Network Security Group. ASGs are used within an NSG to apply a network security rule to a specific workload or group of VMs. An ASG is a “network object,” and explicit IP addresses are added to this object. This provides the capability to group VMs into associated groups or workloads.

The lab setup:
The cloud setup in this experiment included a single vNet, with a single Subnet, which has its own Network Security Group (NSG) assigned.

ASGs

  • Notice that they are all contained within the same Resource Group, and belong to the Location of the vNet (Brazil South).

NSGs:

The following NSG rules were in place for the simulated migrated SWIFT Application:

  • Load Balancers to Web Servers, over specific ports, allow.
  • Web Servers to Databases, over specific ports, allow.
  • Deny all else between SWIFT servers.

The problem:

A SWIFT application team member in charge of the simulation project called the cloud security team telling them a critical backup operation had stopped working on the migrated application, and he suspects the connection is blocked. The cloud network team, at this point, had to verify the root cause of the problem, partially through process of elimination, out of several possible options:

  1. The application team member was wrong, it’s not a policy issue but a configuration issue within the application.
  2. The ASGs are misconfigured while NSGs are configured correctly.
  3. The ASGs are configured correctly but the NSGs are misconfigured or missing a rule.

The cloud team began the process of elimination. They used Azure flow logs to try to detect the possible blocked connections. The following is an example of such a log:

Using the Microsoft Azure Log Analytics platform, the cloud team sifted through the data, with no success. They were searching for a blocked connection that could potentially be the backup process. The blocked connection was non-detectable. The cloud team members therefore dismissed the issue as a misconfiguration in the application.

The SWIFT team member insisted it was not an application issue and several days passed with no solution, all while the SWIFT backup operation kept failing. In a live environment, this stalemate would have been a catastrophe, with team members likely working around the clock to find the blocked connection, or prove misconfiguration in the application itself. In many cases an incident like this would lead to removing the security policy for the sake of business continuity as millions of dollars are at stake daily.

After many debates and an escalation of the incident, it was decided- based on the Protect team’s recommendation- to leverage Guardicore Centra in the Azure cloud environment to help with the investigation and migration simulation project.

Using Guardicore Centra, the team used Reveal to filter for all failed connections related to the SWIFT application. This immediately revealed an attempted failed connection, between the SWIFT load balancer and the SWIFT databases. The connection failed due to missing allow security groups. There was no NSG in place to allow SWIFT LBs to talk to SWIFT DBs in the policy.

The filters in Reveal

 

Discovering the process

Guardicore was able to provide visibility down to the process level for further context and identification of the failed backup process.

Application Context is a Necessity

The reason the flow logs were inadequate to detect the connection was that IPs were constantly changing as the application scaled up and down and the migration simulation project moved forward. Throughout this, the teams had no context of when the backup operation was supposed to occur or what servers initiated these attempted connections, therefore the search came up empty handed. They were searching for what they thought would reveal the failed connections. As flow logs are limited to IPs and ports, they were unable to search based on application context.

The cloud team decided to use Guardicore Centra to manage the migration and segmentation of the SWIFT application simulation for ease of management and ease of maintenance. Additionally, they added process and user context to the rules for more granular security and testing. Guardicore Centra enabled comparing the on-premises application deployment with the cloud setup to make sure all configurations were in place.

The team then went on to use Guardicore Centra to simulate the SWIFT policy over real SWIFT traffic. Making sure they are not blocking additional critical services, and will not inadvertently block these in the future.

 

Guardicore Centra provided the cloud security team with:

  • Visibility and speed to detect the relevant blocked flows
  • Process and user context to identify the failed operation as the backup operation
  • Ability to receive real-time alerts on any policy violation
  • Applying process level rules & user level rules required for the critical SWIFT Application
  • Simulation and testing capabilities to simulate the policies over real application traffic before blocking

All of these features are not available in Azure. These limitations cause serious implications, such as the backup operation failure and no ability to adequately investigate and resolve the issue.

Furthermore, as part of general environment hygiene, our customer attempted to add several rules to govern the whole vNet, blocking Telnet and insecure FTP. For Telnet, our customer could add a block rule in Azure on port 23; For FTP, an issue was raised. FTP can communicate over high range ports that many other applications will need to use, how could it be blocked? Using Guardicore, a simple block rule over the ftpd process was put in place with no port restriction, immediately blocking any insecure ftp communication at process level regardless of the ports used.

Visibility is key to any successful application migration project. Understanding your application dependencies is a critical step, enabling setting up the application successfully in the cloud. Guardicore Centra provides rich context for each connection, powerful filtering capabilities, flexible timeframes and more. We collect all the flows, show successful, failed, and blocked connections, and store historical data, not just short windows of it, to be able to support many use cases. These include troubleshooting, forensics, compliance and of course, segmentation. This enables us to help our customers migrate to the cloud 30x faster and achieve their segmentation and application migration goals across any infrastructure.

Securing a Hybrid Data Center – Strategies and Best Practices

Today’s data centers exist in a hybrid reality. They often include on-premises infrastructure such as Bare Metal or Virtual Machines, as well as both Public and Private cloud. At the same time, most businesses have legacy systems that they need to support. Even as you embrace cutting-edge infrastructure like containers and microservices, your legacy systems aren’t going anywhere, and it’s probably not even on your near future road-map to replace them. As a result, your security strategy needs to be suitable across a hybrid ecosystem, which is not as simple as it sounds.

The Top Issues with Securing a Hybrid Data Center

Many businesses attempt to use traditional security tools to manage a hybrid data center, and quickly run into problems.

Here are the most common problems that companies encounter when traditional tools are used to secure a modern, hybrid data center:

  • Keeping up with the pace of change: Business moves fast, and traditional security tools such as legacy firewalls, ACLs, VLANs and cloud security groups are ineffectual. This is because these solutions are made for one specific underlying infrastructure. VLANs will work well for on premises – but fall short when it comes to cloud and container infrastructure. Cloud security groups work for the cloud, but won’t support additional cloud providers or on premises. If you want to migrate, security will seriously affect the speed and flexibility of your move, slowing down the whole process – and probably negating the reasons you chose cloud to begin with.
  • Management overhead: Incorporating different solutions for different infrastructure is nothing short of a headache. You’ll need to hire more staff, including experts in each area. A cross-platform security strategy that incorporates everyone’s field of expertise is costly, complex, and prone to bottlenecks because of the traditional ‘too many cooks’ issue.
  • No visibility: Your business will also need to think about compliance. This could involve an entirely different solution and staff member dedicated to compliance and visibility. Without granular insight into your entire ecosystem, it’s impossible to pass an audit. VLANs for example offer no visibility into application dependencies, a major requirement for audit-compliance. When businesses use VLANs, compliance therefore becomes an additional headache.
  • Insufficient control: Today’s security solutions need Layer 7 control, with granularity that can look at user identity, FQDN (fully qualified domain names), command lines and more. Existing solutions rely on IPs and ports, which are insufficient to say the least.
    Take cloud security groups for example, which for many has become the standard technology for segmenting applications, the same way as they would on-premises. However, on the cloud this solution stops at Layer 4 traffic, ports and IPs. For application-aware security on AWS, you will need to add another set of controls. In a dynamic data center, security needs to be decoupled from the IPs themselves, allowing for migration of machines. Smart security uses an abstraction level, enabling the policy to follow the workload, rather than the IP.
  • Lack of automation: In a live hybrid cloud data center, automation is essential. Without automation as standard, for example using VLANs, changes can take weeks or even months. Manually implementing rules can result in the downtime of critical systems, as well as multiple lengthy changes in IPs, configurations of routers, and more.

Hybrid Data Center Security Strategies that Meet These Issues Head-On

The first essential item on your checklist should be infrastructure-agnostic security. Centralized management means one policy approach across everything, from modern and legacy technology on-premises to both public and private cloud. Distributed enforcement decouples the security from the IP or any underlying infrastructure – allowing policy to follow the workload, however it moves or changes. Security policy becomes an enabler of migration and change, automatically moving with the assets themselves.

The most effective hybrid cloud solutions will be software-based, able to integrate with any other existing software solution, including ansible, chef, puppet, SCCM, and more. This will also make deployment fast and seamless, with implementation taking hours rather than days. At Guardicore, our customers often express surprise when we request three hours to install our solution for a POC, as competitors have asked for three days!

The ease of use should continue after the initial deployment. An automated, readable visualization of your entire ecosystem makes issues like compliance entirely straightforward, and provides an intuitive and knowledgeable map that is the foundation to policy creation. Coupling this with a flexible labeling system means that any stakeholder can view the map of your infrastructure, and immediately understand what they are looking at.

These factors allow you to implement micro-segmentation in a highly effective way, with granular control down to the process level. In comparison to traditional security tools, Guardicore can secure and micro-segment an application in just weeks, while for one customer it had taken 9 months to do the same task using VLANs.

What Makes Guardicore Unique When it Comes to Hybrid Data Center Security Strategies?

For Guardicore, it all starts with the map. We collect all the flows, rather than just a sample, and allow you to access all your securely stored historical data rather than only snap-shotting small windows in time. This allows us to support more use cases for our customers, from making compliance simple to troubleshooting a slowdown or forensic investigation into a breach. We also use contextual analysis on all application dependencies and traffic, using orchestration data, as well as the process, user, FQDN and command line of all traffic. We can enable results, whatever use case you’re looking to meet.

Guardicore is also known for our flexibility, providing a grouping and labeling process that lets you see your data center the way you talk about it, using your own labels rather than pre-defined ones superimposed on you by a vendor, and Key:Value formats instead of tags. This makes it much easier to create the right policies for your environment, and use the map to see a hierarchical view of your entire business structure, with context that makes sense to you. Taking this a step further into policy creation, your rules methodology can be a composite of whitelisting and blacklisting, giving less risk of inflexibility and complexity in your data center, and even allowing security rules that are not connected to segmentation use cases. In contrast, competitors use white-list only approaches with fixed labels and tiers.

Fast & Simple Segmentation with Guardicore

Your hybrid data center security strategies should enable speed and flexibility, not stand in your way. First, ensure that your solution supports any environment. Next, gain as much visibility as possible, including context. Use this to glean all data in an intuitive way, without gaps, before creating flexible policies that focus on your key objectives – regardless of the underlying infrastructure.

Interested in learning more about implementing a hybrid cloud center security solution?

Download our white paper

What Makes a Business Successful? Celebrating the Culture of Guardicore

Culture is what takes good businesses and makes them successful organizations. Of course you need to have great technology, which we have. We also pride ourselves on addressing a clear need for our customers, which has given us the financial stability to expand. Once you have this foundation, your culture is what is going to add the special spark and engage your team. With it, your business becomes a well-oiled machine, and without it – even a great product with a strong market fit can fail.

One important part of managing growth and global expansion for Guardicore is to keep our finger on the pulse of the organization. For us, this means making sure that the strong and unique culture that we created when we were a small company starting out, remains an integral part of our organization, even as we expand. Not only does this keep our employees happy, it also speaks to our customers, making more businesses want to choose us as their security partner, creating relationships that resonate more than the competition.

We recently ran a global internal survey of our staff, asking for anonymous feedback. Our intention was to highlight the areas in which we’re doing well, and to better understand how we can improve, both as an organization and as an employer. As a part of this survey, we looked at both satisfaction and engagement.

Satisfaction vs Engagement: What’s the Difference?

For us, satisfaction means how happy our employees are at Guardicore. This could include the work environment, how interesting each employee finds their work, , their compensation, and more. An employee’s level of engagement derives from their level of satisfaction, and this refers to how connected our staff feel to Guardicore. How much will they go the extra mile for the company and for its customers? The level of engagement is heavily reliant on the culture.

The results from the survey were extremely high, which showed us that our staff know that we’re on their side, looking to take their feedback into consideration. The results helped us to see that our staff have a high level of satisfaction at work, and gave us some fantastic guidance on where we can support them further by making improvements. However, the level of engagement our employees experience was even higher. It was clear from the results that our team feel incredibly engaged.

As I believe that engagement levels are connected intrinsically to culture, identifying this culture is very important. As we grow and expand, what is the unique make-up of our culture which we need to hold on to and how can we do this?

Culture is Where the Magic Happens

If I were to summarize the Guardicore culture in four words, I would say Fun, Straightforward, Caring, and Smart. This is our ethos, but it is not written on posters. It is most strongly represented by our people. When we’re hiring new people, we look for candidates who check these boxes, people who you can learn from, but who you also love spending time with. People who are trustworthy and straightforward, and who care about their work and the people who they see every day. If candidates walk into an interview and they are fantastic at what they do professionally, but don’t seem to care, or don’t have a spark of fun – they aren’t likely to be the right choice for the position.

Cultivating this Culture at Guardicore

The level of engagement we achieve is a lot about how we support our employees in connecting with one another. Of course, we organize team bonding days, corporate events and at-work initiatives, such as volunteering day. As well as this though, we’ve seen that get-togethers are organized externally, and led by the employees themselves.

As our staff love spending time together, they arrange activities outside of working hours. We have a soccer team that was put together by our staff, a band – Layer 7, and spontaneous board game evenings that employees arrange and initiate. Our teams make plans to go out after work for drinks, or get together on the weekends for beach days and outings. We’ve found that when you recruit like-minded people, and bring together individuals who don’t just work together, but have the potential to form friendships too, the effects on engagement, productivity and success are clear to see.

Understanding the Effect of Engagement

This work culture is the magic ingredient that creates engagement in our staff. Because we’re building friendships, and not just co-working relationships, we have found that our staff is a lot more willing to go above and beyond for one another. This isn’t connected to a financial reward, or the promise of any incentives. It truly comes from a place of caring, and liking one another.

This has a powerful effect on our customers, who have a better experience working with us because we’re a cohesive team filled with people who really care. It also affects the employees themselves, because this company-wide culture means that no one is ‘just another member of staff.’ From the toast when we take on a new customer, to the long tables in the dining room where everyone eats together regardless of department or job title, the inclusive nature of Guardicore means that we’re always working with friends.

Company culture is often a product of the people who work there. The original team at Guardicore, who created the company and have been here since the very first weeks and months of the organization, are smart, fun, straightforward and caring. They hired more of the same type of people, and it’s grown from there and continues to be built around this personality. We are now 160 people strong, building the organization with these core principles at heart. The challenge we have is to keep this culture as we grow.

Does it sound like the Guardicore magic culture would be a great fit for you?

Take a look at
our open positions
and get in touch if you see something that sparks your interest!

The Risk of Legacy Systems in a Modern-Day Hybrid Data Center

If you’re still heavily reliant on legacy infrastructure, you’re not alone. In many industries, legacy servers are an integral part of ‘business as usual’ and are far too complex or expensive to replace or remove.

Examples include Oracle databases that run on Solaris servers, applications using Linux RHEL4, or industry-specific legacy technology. Think about legacy AIX machines that often manage the processing of transactions for financial institutions, or end of life operating systems such as Windows XP that are frequently used as end devices for healthcare enterprises. While businesses do attempt to modernize these applications and infrastructure, it can take years of planning to achieve execution, and even then might never be fully successful.

When Legacy Isn’t Secured – The Whole Data Center is at Risk

When you think about the potential risk of legacy infrastructure, you may go straight to the legacy workloads, but that’s just the start. Think about an unpatched device that is running Windows XP. If this is exploited, an attacker can gain access directly to your data center. Security updates like this recent warning about a remote code execution vulnerability in Windows Server 2003 and Windows XP should show us how close this danger could be.

Gaining access to just one unpatched device, especially when it is a legacy machine, is relatively simple. From this point, lateral movement can allow an attacker to move deeper inside the network. Today’s data centers are increasingly complex and have an intricate mix of technologies, not just two binary categories of legacy and modern, but future-focused and hybrid such as public and private clouds and containers. When a data center takes advantage of this kind of dynamic and complex infrastructure, the risk grows exponentially. Traffic patterns are harder to visualize and therefore control, and attackers are able to move undetected around your network.

Digital Transformation Makes Legacy More Problematic

The threat that legacy servers pose is not as simple as it was before digital transformation. Modernization of the data center has increased the complexity of any enterprise, and attackers have more vectors than ever before to gain a foothold into your data centers and make their way to critical applications of digital crown jewels.

Historically, an on-premises application might have been used by only a few other applications, probably also on premises. Today however, it’s likely that it will be used by cloud-based applications too, without any improvements to its security. By introducing legacy systems to more and more applications and environments, the risk of unpatched or insecure legacy systems is growing all the time. This is exacerbated by every new innovation, communication or advance in technology.

Blocking these communications isn’t actually an option in these scenarios, and digital transformation makes these connections necessary regardless. However, you can’t embrace the latest innovation without securing business-critical elements of your data center. How can you rapidly deploy new applications in a modern data center without putting your enterprise at risk?

Quantifying the Risk

Many organizations think they understand their infrastructure, but don’t actually have an accurate or real-time visualization of their IT ecosystem. Organizational or ‘tribal’ knowledge about legacy systems may be incorrect, incomplete or lost, and it’s almost impossible to obtain manual visibility over a modern dynamic data center. Without an accurate map of your entire network, you simply can’t quantify what the risks are if an attack was to occur.

Once you’ve obtained visibility, here’s what you need to know:

  1. The servers and endpoints that are running legacy systems.
  2. The business applications and environments where the associated workloads belong.
  3. The ways in which the workloads interact with other environments and applications. Think about what processes they use and what goals they are trying to achieve.

Once you have this information, you then know which workloads are presenting the most risk, the business processes that are most likely to come under attack, and the routes that a hacker could use to get from the easy target of a legacy server, across clouds and data centers to a critical prized asset. We often see customers surprised by the ‘open doors’ that could lead attackers directly from an insecure legacy machine to sensitive customer data, or digital crown jewels.

Once you’ve got full visibility, you can start building a list of what to change, which systems to migrate to new environments, and which policy you could use to protect the most valuable assets in your data center. With smart segmentation in place, legacy machines do not have to be a risky element of your infrastructure.

Micro-segmentation is a Powerful Tool Against Lateral Movement

Using micro-segmentation effectively reduces risk in a hybrid data center environment. Specific, granular security policy can be enforced, which works across all infrastructure – from legacy servers to clouds and containers. This policy limits an attacker’s ability to move laterally inside the data center, stopping movement across workloads, applications, and environments.

If you’ve been using VLANs up until now, you’ll know how ineffective they are when it comes to protecting legacy systems. VLANs usually place all legacy systems into one segment, which means just one breach puts them all in the line of fire. VLANs rely on firewall rules that are difficult to maintain and do not leverage sufficient automation. This often results in organizations accepting loose policy that leaves it open to risk. Without visibility, security teams are unable to enforce tight policy and flows, not only among the legacy systems themselves, but also between the legacy systems and the rest of a modern infrastructure.

One Solution – Across all Infrastructure

Many organizations make the mistake of forgetting about legacy systems when they think about their entire IT ecosystem. However, as legacy servers can be the most vulnerable, it’s essential that your micro-segmentation solution works here, too. Covering all infrastructure types is a must-have for any company when choosing a micro-segmentation vendor that works with modern data centers. Even the enterprises who are looking to modernize or replace their legacy systems may be years away from achieving this, and security is more important than ever in the meantime.

Say Goodbye to the Legacy Challenge

Legacy infrastructure is becoming harder to manage. The servers and systems are business critical, but it’s only becoming harder to secure and maintain them in a modern hybrid data center. Not only this, but the risk, and the attack surface are increasing with every new cloud-based technology and every new application you take on.

Visibility is the first important step. Security teams can use an accurate map of their entire network to identify legacy servers and their interdependencies and communications, and then control the risks using tight micro-segmentation technology.

Guardicore Centra can cover legacy infrastructure alongside any other platform, removing the issue of gaps or blind spots for your network. Without fear of losing control over your existing legacy servers, your enterprise can create a micro-segmentation policy that’s future-focused, with support for where you’ve come from and built for today’s hybrid data center.

Interested in learning more about implementing a hybrid cloud center security solution?

Download our white paper

From On-Prem to Cloud: The Complete AWS Security Checklist

Cloud computing has redefined how organizations handle “business as usual.” In the past, organizations were responsible for deploying, maintaining, and securing all of their own systems. However, doing this properly requires resources, and some organizations simply don’t have the necessary in-house talent to accomplish it. With the cloud, it’s now possible to rent resources from a cloud service providers (CSPs) and offload the maintenance and some of the security workload to them.

Just as the cloud is different from an on-premises deployment, security in the cloud can differ from traditional best practices as well. Below, we provide an AWS auditing security checklist that includes the most crucial steps for implementing network security best practices within a cloud environment.

AWS Security Step-by-Step

  • Get the Whole Picture

    Before you can secure the cloud, you need to know what’s in the cloud. Cloud computing is designed to be easy to use, which means that even non-technical employees can create accounts and upload sensitive data to it. Amazon does what it can to help, but poorly secured cloud storage is still a major cause of data breaches. Before your security team can secure your organization’s footprint in the cloud, they first need to do the research necessary to find any unauthorized (and potentially insecure) cloud accounts containing company data.

  • Define an AWS Audit Security Checklist

    After you have an understanding of the scope of your organization’s cloud security deployments, it’s time to apply an AWS audit checklist to them. The purpose of this checklist is to ensure that every deployment containing your organization’s sensitive data meets the minimum standards for a secure cloud deployment. There are a variety of resources available for development of your organization’s AWS audit checklist. Amazon has provided a security checklist for cloud computing, and our piece on AWS Security Best Practices provides the information that you need for a solid foundation in cloud security. Use these resources to define a baseline for a secure AWS and then apply it to all cloud resources in your organization.

  • Improve Visibility

    A CSP’s “as a Service” offerings sacrifice visibility for convenience. When using a cloud service, you lose visibility into and control over the underlying infrastructure, a situation that is very different from an on-premises deployment. Your applications may be deployed over multiple cloud instances and on servers in different sites and even different regions, making it more difficult to define clear security boundaries. Guardicore Centra’s built-in dashboard can be a major asset when trying to understand the scope and layout of your cloud resources. The tool automatically discovers applications on your cloud deployment and maps the data flows between them. This data is then presented in an intuitive user interface, making it easy to understand applications that you have running in the cloud and how they interact with one another.

  • Manage Your Attack Surface

    Once you have a solid understanding of your cloud deployment, the next step is working to secure it. The concept of network segmentation to minimize the impact of a breach is nothing new, but many organizations are at a loss on how to do it in the cloud.While securing all of your application’s traffic within a particular cloud infrastructure (like AWS) or securing traffic between applications and external networks is a good start, it’s simply not enough. In the cloud, it’s necessary to implement micro-segmentation, defining policies at the application level. By defining which applications are allowed to interact and the types of interactions that are permitted, it’s possible to provide the level of security necessary for applications operating in the cloud.In an attempt to ensure the security of their applications, many organizations go too far in defining security policies. In fact, according to Gartner, 70% of segmentation projects originally suffer from over-segmentation. With Guardicore Centra, the burden of defining effective policy rules no longer rests on the members of the security team. Centra’s micro-segmentation solution provides automatic policy recommendations that can be effectively applied on any cloud infrastructure, streamlining your organization’s security policy for AWS and all other cloud deployments.

  • Empower Security Through Visualization

    The success of Security Information and Event Management (SIEM) solutions demonstrates the effectiveness and importance of collating security data into an easy-to-use format for the security team. Many data breaches are enabled by a lack of understanding of the protected system or an inability to effectively analyze and cross-reference alert data.Humans operate most effectively when dealing with visual data, and Centra is designed to provide your security team with the information that they need to secure your cloud deployment. Centra’s threat detection and response technology uses dynamic detection, reputation analysis, and policy-based detection to draw analysts’ attention to where it is needed most. The Guardicore incident response dashboard aggregates all necessary details regarding the attack, empowering defenders to respond rapidly and minimize the organizational impact of an attack.

Applying the AWS Security Checklist

Protecting your organization’s sensitive data and intellectual property requires going beyond the minimum when securing your organization’s cloud deployment. Built for the cloud, Guardicore Centra is designed to provide your organization with the tools it needs to secure your AWS deployment.

To find out more, contact us today or sign up for a demo of the Centra Security Platform and see its impact on your cloud security for yourself.

Thoughts on the Capital One Attack

The ink on the Equifax settlement papers is hardly dry, and another huge data breach, this time at Capital One, is sending shock waves across North America.

The company has disclosed that in March of this year, a former systems engineer, Paige Thompson, exploited a configuration vulnerability (associated with a firewall or WAF) and was able to execute a series of commands on the bank’s servers that were hosted on AWS. About 106 million customers have had their data exposed, including names, incomes, dates of birth, and even social security numbers and bank account credentials. Some of the data was encrypted, some was tokenzied but there’s been a large amount of damage to customers, as well as to the bank’s reputation and the entire security ecosystem.

Our customers, partners and even employees have asked us to comment about the Capital One data breach. Guardicore is an Advanced Technology Partner for AWS with security competency. There are only a small number of companies with such certification and thus I’d like to think that our thoughts do matter.

First – there are a couple of positive things related to this breach:

  1. Once notified, Capital One acted very quickly. It means that they have the right procedures, processes and people.
  2. Responsible disclosure programs provide real value. This is important and many organizations should follow suit.

While not a lot of information is available, based on the content that has been published thus far, we have some additional thoughts:

Could this Data Breach Have Been Avoided?

Reading the many articles on this subject everyone is trying to figure out the same thing. How did this happen, and what could have been done to keep Capital One’s customer data more secure?

What Does a ‘Configuration Vulnerability’ Mean on AWS?

When it comes to managing security in a cloud or a hybrid-cloud environment, organizations often experience issues with maintaining good visibility and control over applications and traffic. The first step is understanding what your role is in a partnership with any cloud vendor. Being part of a shared-responsibility model in AWS means recognizing that Amazon gives you what it calls “full ownership and control” over how you store and secure your content and data. While AWS is responsible for infrastructure, having freedom over your content means you need to take charge when it comes to securing applications and data.

Looking at this data breach specifically, an AWS representative has said “AWS was not compromised in any way and functioned as designed. The perpetrator gained access through misconfiguration of the web application and not the underlying cloud-based infrastructure.”

Thompson gained access by leveraging a configuration error or vulnerability which affected a web firewall guarding a web application. By passing what seems to have been a thin (maybe even single) layer of defense, she was then able to make some kind of lateral movement across the network and then to the S3 bucket where the sensitive data was being stored.

Cloud Native Security Controls are Just Your First Layer of Defense

Can we learn anything from this incomplete information? I do think that the answer is “yes”: Cloud-native security controls provide a good start, but this alone is not enough : Best practice is to add an extra layer of detection and prevention, adding application-aware security to the cloud, just as you would expect on-premises. Defense-in-depth as a concept is not going away even in the cloud. The controls and defenses that the Cloud Service Provider includes should be seen as an add-on or part of the basic hygiene requirements.

I would argue that the built-in Cloud API for Policy Enforcement is Insufficient: SecDevOps need more effective ways to identify and block malicious or suspicious traffic than cloud APIs can achieve. When we were designing Guardicore Centra, we decided to try to develop independent capabilities whenever possible, even if it meant that we had to spend more time and put more into our development. The result is a better security solution that is independent of the infrastructure and is not limited to what a 3rd party supplier/vendor or partner provides.

Guardicore Centra is used as an added security platform for AWS as well as the other clouds. We know from our customers that acting on the facts listed below have protected them on multiple occasions.

  • Guardicore is an Advanced Technology Partner for AWS: Guardicore is the only vendor that specializes in micro-segmentation with this certification from AWS, and Guardicore Centra is fully integrated with AWS. Users can see native-cloud information and AWS-specific data alongside all information about their hybrid ecosystem. When creating policy, this can be visualized and enforced on flows and down to the process level, layer 7.
  • Micro-Segmentation Fills the Gaps of Built-in Cloud Segmentation: Many companies might rely on native cloud segmentation through cloud-vendor tools, but it would have been insufficient to stop the kind of lateral movement the attacker used to harvest these credentials in the Capital One breach. In contrast, solutions like Centra that are deployed on top of the cloud’s infrastructure and are independent are not limited. Specifically for Centra, the product enables companies to set policies at the process level itself.
  • Cloud API for Policy Enforcement is Insufficient: SecDevOps need more effective ways to block malicious or suspicious traffic than cloud APIs can achieve. In contrast, Guardicore Centra can block unwanted traffic with dynamic application policies that monitor and enforce on east-west traffic as well as north-south. As smart labeling and grouping can pull in information such as EC2 tags, users obtain a highly visible and configurable expression of their data centers, both for mapping and policy enforcement.
  • Breach Detection in Minutes, not Months: The Capital One breach was discovered on July 19th 2019, but the attack occurred in late March this year. This is a gap of almost four months from breach to detection. Many businesses struggle with visibility on the cloud, but Guardicore Centra’s foundational map is created with equal insight into all environments. Breach detection occurs in real-time, with visibility down to Layer 7. Security incidents or policy violations can be sent immediately to AWS security hub, automated, or escalated internally for mitigation.

Capital One Bank are well known for good security practices. Their contributions to the security and open source communities are tremendous. This highlights how easily even a business with a strong security posture can fall victim to this kind of vulnerability. As more enterprises move to hybrid-cloud realities, visibility and control get more difficult to achieve.

Guardicore micro-segmentation is built for this challenge, achieving full visibility on the cloud, and creating single granular policies that follow the workload, working seamlessly across a heterogeneous environment.

Want to find out more about how to secure your AWS instances?

Read these Best Practices

Moving Zero Trust from a Concept to a Reality

Most people understand the reasoning and the reality behind a zero trust model. While historically, a network perimeter was considered sufficient to keep attacks at bay, today this is not the case. Zero trust security means that no one is trusted by default from inside or outside the network, and verification is required from everyone trying to gain access to resources on the network. This added layer of security has been shown to be much more useful and capable in preventing breaches.

But how organizations can move from a concept or idea into implementation? Using the same tools that are developed with 15-20 year old technologies is not adequate.

There is a growing demand for IT resources that can be accessed in a location-agnostic way, and cloud services are being used more widely than ever. These facts, on top of businesses embracing broader use of distributed application architectures, mean that both the traditional firewall and the Next Generation are no longer effective for risk reduction.
The other factor to consider is that new malware and attack vectors are being discovered every day, and businesses have no idea where the next threat might come from. It’s more important than ever to use micro-segmentation and micro-perimeters to limit the fallout of a cyber attack.

How does applying the best practices of zero trust combat these issues?

Simply put, implementing the zero trust model creates and enforces small segments of control around sensitive data and applications, increasing your data security overall. Businesses can use zero trust to monitor all network traffic for malicious activity or unauthorized access, limiting the risk of lateral movement through escalating user privileges and improving breach detection and incident response. As Forrester Research, who originally introduced the concept, explain, with zero trust, network policy can be managed from one central console through automation.

The Guardicore principles of zero trust

At Guardicore, we support IT teams in implementing zero trust with the support of our four high level principles. Together, they create an environment where you are best-placed to glean the benefits of zero trust.

  • A least privilege access strategy: Access permissions are only assigned based on a well-defined need. ‘Never trust- always verify’. This doesn’t stop at users alone. We also include applications, and even the data itself, with continuous review of the need for access. Group permissions can help make this seamless, and then individual assets or elements can be removed from each group as necessary.
  • Secure access to all resources: This is true no matter the location or its user. Our authentication level is the same both inside and outside of the local area network, for example services from the LAN will not be available via VPN.
  • Access control at all levels: Both the network itself and each resource or application need multi-factor authentication.
  • Audit everything: Rather than simply collecting data, we review all the logs that are manually collected, using automation to generate alerts where necessary. These bots perform multiple actions, such as our ‘nightwatch bot’ that generates phone calls to the right member of staff in the case of an emergency.

However, knowing these best principles and understanding the benefits behind zero trust is not the same as being able to implement securely and with the right amount of flexibility and control.

Many companies fall at the first hurdle, unsure how to gain full visibility of their ecosystem. Without this, it is impossible to define policy clearly, set up the correct alerts so that business can run as usual, or stay on top of costs. If your business does not have the right guidance or skill-sets, the zero trust model becomes a ‘nice to have’ in theory but not something that can be achieved in practice.

It all starts with the map

With a zero trust model that starts with deep visibility, you can automatically identify all resources across all environments, at both the application and network level. At this point, you can work out what you need to enforce, turning to technology once you know what you’re looking to build as a strategy for your business. Other solutions will start with their capabilities, using these to suggest enforcement, which is the opposite of what you need, and can leave gaps where you need policy the most.

It’s important to ensure that you have a method in place for classification so that stakeholders can understand what they are looking at on your map. We bring in data from third-party orchestration, using automation to create a highly accessible map that is simple to visualize across both technical and business teams. With a context-rich map, you can generate intelligence on malicious activity even at the application layer, and tightly enforce policy without worrying about the impact on business as usual.

With these best practices in mind, and a map as your foundation – your business can achieve the goals of zero trust, enforcing control around sensitive data and apps, finding malicious activity in network traffic, and centrally managing network policy with automation.

Want to better understand how to implement segmentation for securing modern data centers to work towards a zero trust model?

Download our white paper

Guardicore’s Insights from Security Field Day 2019

We had such a great time speaking at Security Field Day recently, presenting the changes to our product since our last visit, and hearing from delegates about what issues concern them in micro-segmentation technology.

The last time we were at Field Day was four years ago, and our product was in an entirely different place. The technology and vision have evolved since then. Of course, we’re still learning as we innovate, with the help of our customers who continually come up with new use cases and challenges to meet.

For those who missed our talk, here’s a look at some of what we discussed, and a brief recap of a few interesting and challenging questions that came up on the day.

Simplicity and Visibility First

At Guardicore, we know that ease of use is the foundation to widespread adoption of a new technology for any business. When we get into discussions with each enterprise, customer, or team, we see clearly that they have their own issues or road map to address. As there is no such thing as the ultimate or only use case for micro-segmentation, we can start with the customer in mind. Our product can support any flavor, any need. Just as examples, some of the most popular use cases include separation of environments such as Dev/Prod, ring fencing critical assets, micro-segmenting digital crown jewels, compliance or least privilege and more general IT hygiene like vulnerable port protocols.

To make these use cases into reality, organizations need deep visibility to understand what’s going on in the data center from a human lens. It’s important to have flexible labeling so that you can physically see your data center with the same language that you use to speak about it. We also enhance this by allowing users to see a particular view based on their need or their role within the company. A compliance officer would have a different use for the map than the CTO, or a developer in DevSecOps for example. In addition, organizations need to enforce both blacklist and whitelist policy models for intuitive threat prevention and response. Our customers benefit from our cutting edge visibility tool, Reveal, which is completely customizable and checks all of these boxes. They also benefit from our flexible policy models that include both whitelisting and blacklisting.

To learn more about how our mapping and visibility happen, and how this helps to enforce policy with our uniquely flexible policy model as well and show quick value, watch our full presentation, below.

Addressing Questions and Challenges

With only one hour for presenting our product, there were a lot of questions that we couldn’t get to answer. Maybe next time! Here are three of the topics we wanted to address further.

Q. How does being agent-based affect your solution?

One of the questions raised during the session was surrounding the fact that Guardicore micro-segmentation is an agent-based solution, as the benefits are clear, but people often want to know what the agent’s impact is on the workload.

The first thing we always tell customers who ask this question is that our solution is tried and tested. It is already deployed in some of the world’s biggest data centers such as Santander and Openlink, and works with a negligible impact on performance. Our agent footprint is very small, less than 0.1% CPU and takes up 185MB on Linux and 800MB on windows. Our resources are also configurable, allowing you to tailor the agent to what you need. At the same time, we support the largest amount of operating systems as compared to other vendors.

If the agent is still not suitable, you can use our L4 collectors, which sit at the hypervisor level or switch level, and give you full visibility, and use our virtual appliance for enforcement, as we touched upon during the talk. As experts in segmentation, we can talk you through your cybersecurity use cases, and discuss which approach works best, and where.

Q. Which breach detection capabilities are included?

Complementary controls are an important element of our solution, because they contribute to the ease of use and simplicity. One tool for multiple use cases offers a powerful competitive edge. Here are three of the tools we include:

  • Reputation Analysis: We can identify granular threats, including suspicious domain names, IP addresses, and even file hashes in traffic flows.
  • Dynamic Deception: The latest in incident response, this technique tricks attackers, diverting them to a honeypot environment where Labs can learn from their behavior.
  • File Integrity Monitoring: A prerequisite for many compliance regulations, this change-detection mechanism will immediately alert to any unauthorized changes to files.

Q. How do you respond to a known threat?

Flexible policy models allow us to respond quickly and intuitively when it comes to breach detection and incident response. Some vendors have a whitelist only model, which impedes their ability to take immediate action and is not enough in a hybrid fast-paced data center. In contrast, we can immediately block a known threat or undesired ports by adding it to the blacklist. One example might be blocking Telnet across the whole environment, or blocking FTP at the process level. This helps us show real value from day one. Composite models can allow complex rules like the real-world example we used at the presentation, SSH is only allowed in Production environment if it comes from Jumpboxes. With Guardicore, this takes 2 simple rules, while with a whitelist model it would take thousands.

Security Field Day 2019 staff

Until Next Time!

We loved presenting at Field Day, and want to thank all the delegates for their time and their interesting questions! If you want to talk more about any of the topics raised in the presentation, reach out to me via LinkedIn.

In the meantime, learn more about securing a hybrid modern data center which works across legacy infrastructure as well as containers and clouds.

Download our white paper

Rethinking Segmentation for Better Security

Cloud services and their related security challenges will continue to grow

One of the biggest shifts in the enterprise computing industry in the past decade is the migration to the cloud. As more and more organizations discover the benefits of moving their data centers to private and public cloud environments, this trend is expected to continue dominating the enterprise landscape. Gartner projects cloud services will grow exponentially from 2019 through 2022, with Infrastructure-as-a-Service (IaaS) being the fastest growing segment of the market, already showing an increase of 27.5% in 2019 compared to 2018.

So what’s the big challenge?

The added agility of cloud infrastructure comes with a trade-off, in the form of increased complexity of cyber security. Traditional security tools were designed for on premise servers and endpoints, focusing on perimeter defense to block the attacks at the entry point. But the dynamic nature of hybrid cloud services meant that perimeter defense became insufficient. When the perimeter itself is constantly shifting, as data and workloads move back and forth among public and private clouds and on premise data centers, the attack surfaces became much larger and required network segmentation to control lateral movement within the perimeter.

From the early days of clouds, segmentation became a popular concept. Traditionally, businesses were looking to divide the network into segments and enforce some sort of access control between the segments. In practice, the way it worked was that relevant servers were put into a dedicated VLAN and routed through a firewall. The higher level of segmentation meant smaller segment size, which reduced the attack surface and limited the impact of any potential breach.

Then – the rules of the game changed! Moving from one static cloud to dynamic, hybrid cloud-based data centers

Simple segmentation by firewalls used to work in the past, when the networks were comprised of relatively large static segments. However, the “rules of the game” have changed significantly in recent years. Dynamic data centers and hybrid cloud adoption have created problems that cannot be solved with legacy firewalls, and yet achieving segmentation is now more vital than ever before. The cadence of change to the infrastructure and application services is very high, accentuating the need for granular segments with an understanding of their dependencies and impacting their security policy.

Take, for example, the 2017 Equifax breach. The US House of Representatives report on this incident pointed directly to the lack of internal segmentation as one of the key gaps that allowed the breach impact to be so big, affecting 143 million consumers.

Regulation is another driver of segmentation. One of Guardicore’s customers, a global investment bank, needed to comply with a new regulation of SWIFT – which requires all SWIFT servers to be put into a separate segment and whitelist all connection allowed in and out of this segment. Using traditional methods, it took the bank 10 months and a costly labor-intensive process to complete this change, spurring them on to find smarter segmentation methods moving forward.

The examples above demonstrate how although segmentation is a known and well understood security measure, in practice organizations struggle to implement it properly in a cost-effective way.

Adapt easily to these changes and start micro-segmentation

To deal with these challenges, micro-segmentation was born. Micro-segmentation takes enterprise security to a new level and is a step further than existing network segmentation and application segmentation methods, adding visibility and policy granularity. It typically works by establishing security policies around individual or groups of applications, regardless of where they reside in the hybrid data center. These policies dictate which applications can and cannot communicate with each other.

Micro-segmentation includes the ability to fully visualize the environment and define security policies with Layer 7 process-level precision, making it highly effective at preventing lateral movement in a hybrid cloud environment.

Take the first step in preparing your enterprise for a better data security

Want to learn more? Listen to Guardicore’s CTO and Co-founder, Ariel Zeitlin, as he walks through the challenges and the solutions to better secure your data in his latest interview with the CIO Talk Network. In this podcast, Ariel discusses the new approaches to implementing segmentation, the key aspects you need to consider when comparing different vendors and technologies, and what comes ahead of the curve for security leaders in this space.

 

Want to learn more about how to first think through, then properly implement micro-segmentation? Read our white paper on operationalizing your segmentation project.

Read More