Where to Start? Moving from the Theory of Zero Trust to Making it Work in Practice

Going back many years, perimeter controls were traditionally adequate for protecting enterprise networks that held critical assets and data. The hypothesis was that if you had strong external perimeter controls, watching your ingress and egress should be adequate for protection. If you were a more sophisticated or larger entity, there would be additional fundamental separation points between portions of your environment. However these were still viewed and functioned as additional perimeter points, merely concentric circles of trust with the ability, more or less, to move freely about. In cases where threats occurred within your environment, you would hope to catch them as they crossed one of these rudimentary borders.

The Moment I Realized that Perimeters Aren’t Enough

This practice worked moderately well for a while. However, around fifteen years ago, security practitioners began to feel a nascent itch, a feeling that this was not enough. I personally remember working on a case, a hospital – attacked by a very early spear phishing attack that mimicked a help desk request for a password reset. Clicking on a URL in a very official looking email, staff were sent to a fakebut official looking website where these hospital professionals were prompted to reset their credentials – or so they thought. Instead, the attack began. This was before the days of the Darknet and we even caught the German hacker boasting about what he had done – sharing the phishing email and fake website on a hacker messaging board. I worked for a company that had a fantastic IPS solution and upon deploying it, we were able to quickly catch the individual’s exfils. At first, we seemed to be winning. We cut the attacker off from major portions of a botnet that resided on the cafeteria cash registers, most of the doctors machines and to my horror, even on the automated pharmacy fulfillment computers. Two weeks later, I received a call, the attacker was back,trying to get around the IPS device in new ways. While we were able to suppress the attack for the most part, I finally had to explain to the hospital IT staff that my IPS was merely at the entrances and exits of their network and that to really stop these attacks, we needed to look at all of the machines and applications that resided within their environment. We needed the ability to look at traffic before it made its way to and from the exits. This was to be the first of many realizations for me that the reliance on perimeter-based security was slowly and surely eroding.

In the years since, the concept of a perimeter has all but completely eroded. Of course, it took quite a while for the larger population to accept. This was helped along by the business and application interdependencies that bring vendors, contractors, distributors and applications through your enterprise as well as the emergence of cloud and cloud like provisioning utilized by Dev Ops. The concept of being able to have true perimeters as a main method of prevention is no longer tangible.

It was this reality that spurred the creation of Forrester’s Zero Trust model- almost a decade ago. The basic premise is that no person or device is automatically given access or trusted without verification. In theory, this is simple. In practice, however, especially in data centers that have become increasingly hybrid and complex, this can get complicated fast.

Visibility is Foundational for Zero Trust

A cornerstone of Zero Trust is to ‘assume access.’ This means that any enterprise should assume than an attacker has already breached the perimeter. This could be through stealing credentials, a phishing scam, basic hygiene issues like poor passwords, account control and patching regimen, an IoT or third-party device, a brute force attack, or literally limitless other new vectors that make up today’s dynamic data centers.

Protecting your digital crown jewels through this complex landscape is getting increasingly tough. From isolating sensitive data for compliance or customer security, to protecting the critical assets that your operation relies on to run smoothly, you need to be able to visualize, segment and enforce rules to create an air-tight path for communications through your ecosystem.

As John Kindervag, founder of Zero Trust once said, in removing “the Soft Chewy Center” and moving towards a Zero Trust environment, visibility is step one. Without having an accurate, real-time and historical map of your entire infrastructure, including on-premises and both public and private clouds, it’s impossible to be sure that you aren’t experiencing gaps or blind spots. As Forrester analyst Chase Cunningham mandates in the ZTX Ecosystem Strategic Plan, “Visibility is the key in defending any valuable asset. You can’t protect the invisible. The more visibility you have into your network across your business ecosystem, the better chance you have to quickly detect the tell-tale signs of a breach in progress and to stop it.”

What Should Enterprises Be Seeing to Enable a Zero Trust Model?

Visibility itself is a broad term. Here are some practical necessities that are the building blocks of Zero Trust, and that your map should include.

  • Automated logging and monitoring: With an automated map of your whole infrastructure that updates without the need for manual support, your business has an always-accurate visualization of your data center. When something changes unexpectedly, this is immediately visible.
  • Classification of critical assets and data: Your stakeholders need to be able to read what they can see. Labeling and classification are therefore an integral element of visibility. Flexible labeling and grouping of assets streamlines visibility, and later, policy creation.
  • Relationships and dependencies: The best illustration of the relationships and dependencies of assets, applications and flows will give insight all the way down to process level.
  • Context: This starts with historical data as well as real-time, so that enterprises can establish baselines to use for smart policy creation. Your context can be enhanced with orchestration metadata from the cloud or third-party APIs, imported automatically to give more understanding to what you’re visualizing.

Next Step… Segmentation!

Identifying all resources across all environments is just step one, but it’s an essential first step for a successful approach to establishing a Zero Trust model. Without visibility into users, their devices, workloads across all environments, applications, and data itself, moving onto segmentation is like grasping in the dark.

In contrast, with visibility at the start, it’s intuitive to sit down and identify your enterprise’s most critical assets, decide on your unique access permissions and grouping strategy for resources, and to make intelligent and dynamic modifications to policy at the speed of change.

Want to read more about visibility and Zero Trust? Get our white paper about how to move toward a Zero Trust framework faster.

Read More

Guardicore Infection Monkey for Zero Trust

Guardicore Labs provided assistance in a ransomware investigation. We analysed the decryption process of the IEncrypt ransomware and provided a safe-to-use version of the attackers’ decryptor.

Banco BASE Selects Guardicore Centra Security Platform to Protect Critical Banking Applications

Guardicore Chosen for Superior Visibility and Segmentation Policy Management to Reduce Risks

Boston, Mass. and Tel Aviv, Israel – October 22, 2019 – Guardicore, a leader in internal data center and cloud security, today announced that Banco BASE, a Mexican financial group and a leader in financing and foreign trade industries, is deploying Guardicore’s Centra Security Platform to provide advanced data center security.

“Banco BASE has built its success by providing the most innovative financial solutions, with agile and personalized service,” said Prudencio Frigolet Gómez. Director of Technology and  Operations at Banco BASE. “A big part of our commitment to our customers is ensuring the protection of their critical data and availability of services. Guardicore Centra gives our IT team deep visibility into east-west traffic for our critical banking applications and the ability to reduce risk with micro-segmentation.”  

Banco BASE is part of the Mexican Financial Group Grupo Financiero BASE. With over 32 years of experience, Banco BASE provides products for corporate and private banking, including loans, investments, digital accounts and currency exchange. 

“We are honored Banco BASE has selected Guardicore to help protect their most critical applications,” said Pavel Gurvich, co-founder and CEO of Guardicore. “Banco BASE quickly recognized that a new, software-defined approach to segmentation is essential for reducing risk and simplifying ongoing policy management for critical applications and payment systems like SWIFT.”

Guardicore’s flagship product, the Centra Security Platform, is a comprehensive data center and cloud security solution that delivers the simplest and most intuitive way to apply micro-segmentation controls to reduce the attack surface and detect and control breaches within east-west traffic. It provides deep visibility into application dependencies and flows and enforcement of network and individual process level policies to isolate and segment critical applications and infrastructure.

About Banco BASE

For nearly three decades, Banco BASE has specialized in providing companies with financial advice solutions, to help them grow and achieve their goals, through a strong services portfolio, including Foreign Currency, Hedging Instruments, Credit, Digital Accounts and Investments. We deliver very efficient financial services due to our network of offices in Mexico’s major cities from which we cover all the country; plus, we have as well a representation office in Toronto, Canada. Furthermore, we have correspondence relationships with the world’s main banks and most Mexican banks, which ensure our transparency, reliability and transaction swiftness.

Our credentials include: Rated by Standard & Poor´s, since February 2000 and by Fitch Ratings since 2006 always increasing our ratings; Approximately 2,000 FX transactions per day and a daily trading volume of USD $450 million; Members of the Association of Certified Anti-Money Laundering Specialist (ACAMS) and founders of the Monterrey-Mexico Chapter; Placed among the 500 most important companies in Mexico, and a “Super Empresa” (one of the best places to work for) by Expansion Magazine (A Time Inc. Enterprise). Our best recommendation comes from our more than 20,000 satisfied national and international customers.

For more information, visit www.bancobase.com 

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.

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.