Shieldx Elastic Cloud Security platform supports TLS 1.3

When we recently saw TLS 1.3 approved, what we really saw was the introduction of best-of-breed security capabilities end to end. This latest iteration of what was originally known as the SSL protocol addresses security shortcomings from the previous version and significantly reduces latency with abbreviated and simplified handshakes. It’s more secure and it’s faster: win/win.

As you might expect, the ShieldX Elastic Cloud Security platform can transparently proxy TLS 1.3 connections and thus customers may use the platform to secure both server and client workloads with inbound and outbound proxying. ShieldX supports all aspects of the protocol and works with popular implementations such as NGINX, Google Chrome and Mozilla Firefox.

Perfect forward secrecy

A concern for key-exchange frameworks like TLS is whether future compromises of a secret key will expose prior communications. Perfect forward secrecy (sometimes just called forward secrecy) means that your session keys will not be compromised even if the private key of the server is compromised. Forward secrecy thus protects past sessions against future revelations and this is now part of TLS: session setup now only supports key exchange modes that provide forward-secrecy. Key exchange methods that don’t provide forward secrecy (non-ephemeral Diffie-Hellman, for example) are deprecated.

While this is great, one important note is that better encryption makes inspection via an inline proxy essential to prevent encrypted threats from passing into internal infrastructure unnoticed. A previous blog entry, for instance, looked at inline proxy when defending against Petya malware variants.

Improved TLS handshakes

TLS 1.3 does things more efficiently and with greater security. All session handshakes that include sensitive data will now be in encrypted form, supporting encrypted extensions (only “client-hello” and part of “server-hello” are exchanged in clear text). For further simplification, several handshakes such as “server-key-exchange” have been deprecated.

According to one cloud proxy provider, about 60% of web connections are from first-time visitors to a site, a situation which the improved handshakes in 1.3 signficantly speed up. For the 40% of connections where the site was recently visited and the previous connection is being resumed, 1.3 supports 0-RTT (zero-round-trip) reconnection. This decreases the time required in the returning-user scenario by not waiting for certain parts of the handshake to be fully returned before proceeding.

Better key and certificate handling

Several elements of key derivation and certificate exchange have been tidied up in 1.3:

  • A new Key-Update mechanism is a more secure approach to refreshing the symmetric encryption key that doesn’t involve repeating the initial certificate exchange.
  • Packet hashes are included in key calculations, making keys more secure than ever—what was an optional extension in 1.2 is now part of the base protocol.
  • Key derivation/calculation doesn’t use packet fields that are exchanged in clear-text (TLS 1.2 and earlier protocols used to include client random and server random fields to derive keys).
  • The protocol now uses HKDF (The HMAC-based Extract-and-Expand Key Derivation Function) for key derivation. Separate secrets and key blocks are generated/used to exchange SSL handshake and SSL application data.
  • Going forward, available cipher suites have been pared down so that AEAD (authenticated encryption with associated data) ciphers like GCM and CHACHA-POLY are available and other prior options have been removed. AEAD combines both encryption and authentication into one step, rather than using a key and a separate message authentication code (MAC).
  • TLS 1.3 supports a proposed extension that allows certificates to be compressed and exchanged in a new TLS session’s handshake. Since certificates can contain a fair amount of text information, they are good candidates for compression. Reducing the certificate size reduces the number of bytes exchanged and thus reduces latency.

Need for TLS inspection

As hinted above, inline proxy inspection of network traffic becomes more important than ever with TLS 1.3. Network threats continue to evolve, especially in their ability to evade detection and penetrate enterprises. Sending malicious data across encrypted channels is perhaps the easiest way to evade detection because many organizations continue to deploy and operate their security perimeter devices without inline, decrypted packet inspection.

Even in cases where organizations deploy TLS inspection, they frequently use it in tap mode or else enable a non-proxy mode by downgrading the security capabilities of their webservers to use RSA or other non-ephemeral key exchange methods. This not only breaks forward-secrecy, it also endangers end consumers by weakening the security capability offered by the protocol. (In the interest of completeness, note that application detection and classification that works based on the TLS SNI extension will continue to work.)

In almost all cases, though, enabling TLS inspection is an important first step. Using TLS proxy inspection provided by Shieldx Elastic Cloud security platform, enterprises may further leverage our “Indicators of Pivot” feature to detect and block advanced threats and lateral movements inside their network.

Read More
ShieldX earns top marks in customer product review

ShieldX was reviewed by our customer, Larry H Miller dealership group. Some highlights:

  • For other security professions who are looking for something which is low in cost that does microsegmentation, they should look at ShieldX.
  • With Illumio, you have to install an agent on every server, and you don’t have to do that with ShieldX, because it is agentless.
  • What I like about it now is that it has a single pane of glass to view our networks and groups.

The full review is here: https://www.itcentralstation.com/product_reviews/shieldx-review-60870-by-branden-emia.


Read More
ShieldX Earns Perfect Five Star Rating

SC Media has published its February 2019 “cloud-based security management” group test which included a review of ShieldX’s Elastic Security Platform product. You can view the five star review HERE.

Some highlights:

  • With the capability to have a single pane view into any environment, along with dynamic scaling, visibility and discovery across a multi-cloud infrastructure, this product is worth adding to the top of your list.Full stack protection is offered with FireEye, APP-aware ACL, DLP, malware detection, full-flow packet capture IDS/IPS threat detection and prevention, virtual tap, URL inspection for reputation and classification/filtering, unique anomaly detection, and micro-segmentation.
  • Every workload and application in your data center will be fully mapped automatically without agents.
  • Automating infrastructure, security and applications helps ensure microservices are inserted when and where they are needed. These microservices are inserted directly into infrastructures. This allows for automated intent-based security policies.
  • Security Analytics has a unique component called Indicator of Pivot (IoP) which is based on kill chain methodology.
  • With a fast time-to-value return after a quick 30-minute installation, operational efficiency increases visibility and discovery seamless across a multi-cloud structure with a single pane view into any environment using tools you know.
  • WEAKNESSES:None that we found.



Read More
The Rubric Automated Security Policies

No matter how security focused an organization is, the cloud era has brought on a new set of issues tied to lack of visibility and control over what gets deployed and where it’s deployed. This is why having automated security controls is critical in the protection of critical information being exposed, and more importantly leaked.

Today, Tech Crunch reported a security flaw at Rubrik, a major IT security and cloud management provider that could have lead to the exfiltration of key customer data had it not been caught. The article noted that a server, which was a part of developing a new customer support system, was improperly configured, leading to the risk of data being exfiltrated. It would be easy to point the finger at Rubrik and say they are responsible, however the truth is, in a consistently changing environment such as the cloud,  it is difficult for us as humans to effectively ensure all systems are properly protected during provisioning and migration of workloads and applications.

Many people who are deployed in Azure and AWS assume they are automatically protected through native cloud security controls. This is a perfect example of how those controls are not sufficient in protecting the workloads that are being rapidly provisioned and constantly migrated due to agile development of new applications to support customer functionality and business operations.  But even with a solid level of security in place, the system could have still gone unnoticed. This is where automation becomes important.

Preventing this type or issue is exactly why ShieldX was founded.  With ShieldX you can set Application Aware ACLs to be automatically applied to servers as they are provisioned or migrated. This means ShieldX security policies would have been applied to the elastic search service and guaranteed the same access restriction no matter where it appears in the cloud environment. With ShieldX, customers get “Layered Security and Layered defense” by means of “ACLs/Micro segmentation”, and Indicator Of Pivot modeled around “Cyber Kill chain”, providing single pane of glass for security controls deployed on-premise, AWS and Azure.  With ShieldX in place, organizations like Rubrik can create automated policies that will automatically apply the appropriate security controls as the systems come online. Finally, enterprises can focus on defining the appropriate security intent and have cloud native security platform offered by ShieldX  transform that intent into actual policy and rich set of controls with automation and orchestration to increase security posture and reduce TCO .

Read More
PART III: AWS and Azure–Cloud security isn’t true security

This is part III of III.

Solve it

If individual cloud-based security isn’t the quick fix customers are seeking, what is? Well, that was a trick question of course. There is no quick fix. There IS a fix. And that is a pre-planned comprehensive stack that addresses your responsibility in cloud computing. Theses include but are not limited to segments such as the storage and exchange of customer data according to HIPAA compliance, GDPR, PCI-DATA, the SEC, and the list goes on.


When you go with a trusted multi-cloud provider like ShieldX, you replace the patchwork of features and providers with a high-visibility solution that addresses the above and more. You get your manager off of your behind when you remove those licensing and maintenance fees. Your costs go down. And instead of playing 3-D chess to avoid misconfigurations, you can breathe.


Some CISOs get started by consulting with their team, then building a map to show the missing pieces of their security apparatus and their solutions. Don’t forget to work with application owners to understand any potential threat vectors. A solid strategy will address:

  • Missing security apparatus
  • Threat vectors in application/components
  • A good security hygiene
  • Access control permissions


Regardless of what your security approach you are planning in your cloud or multi-cloud environment, please do not go with the approach of lift and shift. Understand the security implications of your presences by evaluating the difference and exchange between on-premises and cloud security. Then call us.

Read More
PART II: AWS and Azure–Cloud Security Isn’t True Security

This is a continuation of from a previous blog.

Cloud security isn’t true security.

Digital transformation, the cloud, and the increased popularity of DevOps, may have sped up your business practices and driven innovation. Unfortunately for network and security operations teams, the combination of these factors means a significant increase in the resource protection needed. Securing the above can become a complex, multi-vendor, multi-technology, and hybrid-cloud-environmental issue.


With limited resources and manual processes, it is difficult for cloud-based IT organizations to keep up with demand and document changes. While both Amazon and Azure provide too many services (Wikipedia lists these for your general Azure interest) to detail in a short security article, it suffices to say that with each cloud capability your company utilizes, the importance of securing your presence only increases. Now we’ll go into the most obvious reason security breaches are increasing on all cloud platforms: misconfiguration.


Cloud-provided security is a miss on misconfigs

With financial and time pressure only on the increase for CISOs, there’s a real temptation to “lift and shift,” or drop assets into a cloud without considering the security of their configuration and relationships to on-premises assets. Not the best idea.


We won’t mince words here: Misconfigurations are THE BIGGEST driver behind breaches today. The skyrocketing rate of poorly configured cloud infrastructure is the driver behind the major source of these breaches. According to Computing Cloud, problems arising from this one issue jumped by 424% this year, accounting for nearly 70% of compromised records over the year.


Computing Cloud’s 2018 Review notes that 86% of organizations cite data breaches and loss as the primary reason they hesitate to adopt the cloud. Unfortunately, a simple misconfiguration, even a failure to set a single option in a company’s cloud service, can create a major security risk. Take problems at Equifax, Cathay Pacific and others as an indicator of what’s to come when you leave the door open behind you.


So Retro-active!

Cloud companies are learning, but slowly, while customers are left to piece together their security after the fact. Some enterprise customers who already use Azure for example, may extend active directory (AD) controls into the cloud, so they can define “new” security controls using their existing AD controls. AWS is adapting to the new security customer in working toward enterprise-readiness in their network monitoring. They have a ways to go though. Over time both platforms have added a few resources, but neither offer a comprehensive security stack.


The problem is that the Cloud providers are securing their networks not your applications. They are providing insight and monitoring of suspicious activity on their network but not on your databases. This is like a security guard that monitors the streets for suspicious activity when the actual suspicious activity happens at the homes they’re breaking into, not on the streets.


It gets even worse though. Because it’s still up to you to properly use all the security products they are making available AND use them correctly. Meanwhile they are still learning how to properly provide them themselves. Add to that how each Cloud provider does it differently and you’re looking at a security resource problem as in you won’t find enough security resources to help you with securing all the different types of Cloud environments.


Now please ask yourself and your team if these add-ons, workarounds, and limited cloud-provided security insight are good enough and consider alternative solutions. Some multi-cloud security vendors, ShieldX included, give customers a single viewpoint or “pane of glass” to define security policies and control. A micro-services driven approach with custom-built orchestration for discovery and scaling makes these solutions very effective in cloud migration.


Other features provided by ShieldX are important when it comes to cloud security readiness: the ability to micro-segment and do DPI for “threat protection” on the traffic to detect any threats within the E/W (core) network.

Read More
PART I: AWS and Azure–Cloud Security Isn’t True Security

Like taking flight, most enterprise CISOs begin (and remain) building their security structure while their assets on the ground, before transitioning a number of them to AWS or Azure cloud storage and apps. And rather than building on a cloud foundation from the very beginning of their business model, the most likely scenario for our readers is to have a fair amount of data centers stationed on their own servers, even after their move to their cloud(s).


However these assets are positioned, assessment of your own security posture should take into account their configuration as well as their location—and cover everything in between. Below we go into the different considerations for secure AWS and Azure storage, as well as the importance of a holistic security plan for whatever your organization has decided to shift—or keep on premises.


The basics

In a general sense, AWS and Azure have grown more similar than apart. AWS was initially built to hold Amazon’s assets and information. Their data center was then converted to use for customers. So from day one, the security architecture was not built to allow customer control in several aspects, let alone the microsegmentation that you can only get from a third-party provider.


As far as Azure is concerned, they launched in 2010 but are now a Fortune-500-favorite to the cloud game, starting as an internal project for building and deploying their own applications.


Add-ons add up

Neither AWS nor Azure features security as a pillar on their website, and there’s a reason for that. If there’s anything you take away from this article, it is vital to remember that when it comes to security, anything put on the Cloud is a shared responsibility model.


If you build an application, do anything on your own that holds customer data, or write code—that’s all your security responsibility. It works well only as long as every user has done their bit.


According to their marketing, both the Azure Active directory and AWS Directory Service profess their “reliability” and “scalability” and touch on security features that can basically be categorized into:

  • Visibility
  • Threat protection
  • Security assessment
  • Cloud configuration assessment, and
  • Policies and constraints, including varied microsegmentation


One security researcher summarizes that, though he prefers them for data protection, his main challenge with AWS is that “they don’t offer control over the subnet level. For a security provider to mitigate that issue we need to look at every machine’s traffic.”


We encourage you to visit both websites or this handy comparison guide for specifics, but let’s move forward. According to Azure’s Advanced Threat Protection offering, as an add-on security feature, they profess to:

  • Identify suspicious user and device activity with both known-technique detection and behavioral analytics
  • Analyze threat intelligence from the cloud and on-premise
  • Protect user identities and credentials stored in Active Directory
  • View clear attack information on a simple timeline for fast triage
  • Monitor multiple entry points through integration with Windows Defender Advanced Threat Protection

But comparison of in-cloud offerings is not the takeaway point of this article. Other articles do that. Our point is this: We believe any cloud’s security description should not satisfy you. You should leave a clouds’s website with multiple questions and assumptions. Cloud security isn’t true security. Never believe the hype.


Take the above bullets. You may ask yourself, How does Azure identify suspicious user activity via analytics, when a user could be monitoring on-premise apps before breaking in without suspicion? How do they analyze threat intelligence on premises? Would that require timely installation and automatic updates? Yes, Azure monitors multiple entry points—cloud entry points. Is every department of your company using the same cloud login? Is that a good thing?


So let’s pretend, with all your open-ended questions, you’ve opted to purchase their security plan. But you need more. To secure on-premise apps you’ve gone with an agent-based solution. A few other departments have added on a patchwork of virtual appliances to supplement their data security. Like many companies, you may throw consistency out the window and inadvertently end up using multi cloud/platform approaches even across divisions. Suddenly, in Q3, the CFO calls you in a panic, asking why vendors are emailing and asking for overdue licensing and maintenance fees.


We’d like to offer you a little reminder. Rather than relying on multiple add-on security providers, with an agentless network provider like ShieldX, you are consolidating and applying one set of controls across multiple platforms. It’s this problematic nature of cloudy security issues which is why ShieldX devised the solution in the first place. But enough sales talk.


PART II coming tomorrow.

Read More
Agentless Micro Segmentation: How Does ShieldX Do It?

At a recent trade show, I was asked: “How does ShieldX implement agentless micro segmentation?”  Not coincidentally, Gartner recently published a research note (login required) and called ShieldX out for its agentless technology, correctly calling us “microservices-based micro segmentation.”

How do we do it? ShieldX deploys a network-based architecture where we insert in multi-cloud environments to collect and inspect infrastructure traffic for visibility, analytics and security control, instead of relying on end points (agents). We implement agent-less network traffic inspection using an overlay network. Insertion is handled by Segment Interfaces (SI) microservice. In VMware ESXi environment, we use SI on trunk tap for Tap Mode and Layer2 VLAN Bridging to SIs for Inline and Microsegmentation Mode. In Azure environment, we use Flow Inspectors (FI), placed inline as a NAT provider for N/S traffic and route traffic between workloads via User Defined Routes (UDR) for E/W traffic. In AWS environment, we use the FI as a NAT provider for N/S traffic and use Network encapsulation and route entries for E/W traffic. This ensures we are placed in the “Goldilocks Zone”: not on the system (too close) where it makes deployments, upgrades, testing and maintenance more difficult, but also not removed from the network at the perimeter only (too far), where traffic cannot be rerouted and steered in a timely and effective way. This makes ShieldX the “just right” solution for all of your micro segmentation and cloud security needs.

But what is the most important impact?  Friction-less deployment and maintenance with no additional testing at every upgrade.  I always say the proof is in the pudding: in their review of ShieldX, Alaska Airlines noted: “We evaluated vArmour and Illumio. They didn’t meet our requirements. ShieldX is a superior solution.”  We deploy in just a few hours or less, and immediately begin to provide a full set of security controls and automated micro segmentation.  Longer term, managing perpetual flux on an ever changing network means—with machine learning—making changes to a micro segmented network is easy.  Again, noting our customer: “The Adaptive Intention Engine is fantastic. It allows us to develop security policies using the language of our internal customers. It’s machine-learning applied to security workflows. That allows us to much more easily construct the policies that will protect those workflows.”

Read More
VMWare Security Analysis

Data center virtualization was originally designed to improve the utilization rates of computing, networking and storage assets. As the early pioneer of such technologies, VMWare grew to become the dominant vendor of data center virtualization software. Unfortunately, cloud providers’ popularity and rapid feature expansion have not matched the limited security solutions they offer along with their data packages.

Unaware customers who migrate their assets via providers like VMWare, without a holistic inter-cloud security strategy in place, are left both insecure and financially vulnerable.

While every cloud provider should be considered an analog, in this advisory we will address VMWare specifically as both a trendsetting example and leading cloud provider. Here we provide users with five reasons to consider an inter-cloud security approach when those assets are in play.


A successful software-defined data center implementation should support scaling of computing resources

This allows for business units to add new applications rapidly and with enhanced DC security. This should be enabled in a VMWare-powered data center. But this is not a feature VMWare offers. A barely hidden secret in IT corners is that many previous loyalists have chosen to convert to AWS and prompted a rapid rise in demand for cloud computing and IaaS.

A comparison of the growth in AWS-based virtualization and VMWare’s on-premise virtual servers illustrates the movement toward AWS.

Solution 2013 2014 2015 2016 2017
AWS 3108 4644 7880 12,219 17,459
VMWare 5150 6040 6650 7090 7920(*)

(All figures in $mil.)

*Re-statements to account for Dell acquisition


The result has been that enterprises now own two separately virtualized assets. One is in their data centers with VMWare, and the other is in AWS VPCs and/or Azure Vnets. The public cloud has delivered economic benefits for them as well as more flexible control over their resources.


VMWare’s virtual networking and security toolkit are not built to maximize security

While VMWare has robust server virtualization offerings, its security features are simply too underdeveloped for the majority of customers’ needs.

To supplement them, customers seek alternatives with Cisco ACI and a multi-vendor mix for their security needs. Meanwhile, the cumulative cost to VMWare customers keeps rising. Gartner has seen consistent adoption of these offerings over the past year, and Cisco now reports over 3,500 paying ACI customers. (Gartner MQ on Data Centers)


VMWare never quite ‘got’ public cloud standards

VMWare initially took an adversarial stance towards their competitors. Of course, these were public clouds, most notably Amazon’s AWS. Not only did VMWare downplay the compelling benefits of AWS, but more importantly they did little to match their capabilities or provide alternative, legitimate pathways for customer workload migration.

Then they followed up with their own public cloud solution which experienced a myriad of growing pains. Their vCloud Air was sold to OVH in May 2017.


Add-ons add up

After launch when it was forced to reconsider its position, VMWare offered its cloud customers an option of deploying its virtualization toolset (VMWare cloud on AWS) on top of the already virtualized AWS cloud (functionality illustrated by VMPro).

The following table quantifies the cost of running VMWare Cloud on AWS compared to native AWS virtual servers, VMWare providing no additional benefit.

Note the additional cost requirement to heavily invest in VMWare’s private data center in order to access preferred pricing in AWS.


VMWare on-premise license requirements Yearly cost of 10 VMWare servers on AWS (1) Yearly cost of 10 AWS EC2 instances without VMWare overhead (2)
100 CPUs of vSphere Enterprise Plus $467,883 $193.20
100 CPUs of vSphere Enterprise Plus & 10 CPUs of NSX $441,890 $193.20
100 CPUs of vSphere Enterprise Plus & 20 CPUs of NSX and 20 VSAN licenses $389,903 $193.20

(1)(VMWare data procured from their blog.)

(2)(AWS pricing is based on a reserved instance standard for a 3-year term as derived from their pricing sheet)


VMWare has not delivered on its promise of a robust security platform

When it comes to segmentation and threat prevention across the data center and public cloud, its customers are still waiting for answers. VMWare has underdeveloped inter-cloud security offerings—and they are hampering customer adoption of true multi-cloud infrastructure.

Let’s go back to the very beginning of connective security, starting with virtual servers. Virtual servers naturally gave rise to virtual network switches, which connected them within a single physical server and across their data center. The servers needed to be segmented and inter-server traffic inspected for threats.

Initially, VMWare offered the VMSafe API to allow partners to bring their expertise to bear in order to keep this virtual network safe for their customers. But after getting their partners invested in this approach, VMWare abruptly canceled their API effort in favor of internally developed techniques. The outcome was that the virtual network suffered in its security posture compared to what was delivered on the physical network. This limited security foundation is unfortunately coupled with an aging virtual network and repackaged as an “inter-cloud” offering called NSX-T. NSX-T is not lacking in bold claims.

While the NSX-T design guide claims to provide “micro-segmentation for AWS workloads,” it does not offer any threat mitigation beyond the original NSX offering, which is limited to working on top of AWS with little support for other leading clouds such as Azure and GCP.

The security offered by NSX-T is based on basic firewall functionality for N-S traffic and  coupled to the segmentation built into each vNIC.

NSX-T does not begin to address the fundamental requirements of a multi-cloud security solution. The security policy must be expressed as an intention to be applied not to VMs, but to operations from application workloads. The solution must work seamlessly across all major clouds.

Customers who have integrated their assets with VMWare have been struggling to absorb and deploy this limited model as they look to mitigate inter-cloud security challenges.

Take a hint from a proprietary major utility company, which had to deploy virtual firewalls in addition to NSX to protect their virtualized data center. Operationally, these dual security frameworks were challenging to maintain.

The customer was unsure, after all their efforts, whether they had the protection they needed. When they moved their workloads to AWS, the same data center security implementation could not be deployed there. The increasing opex and capex burdens, and reduced confidence in security, set back their timeline for moving additional workloads to the cloud.

VMWare’s capitulation to AWS has resulted in a new marketing approach wherein VMs from the data center can migrate to AWS. As noted earlier, this doubles their customers’ spend and reduces their flexibility. Additionally, this migration is currently supported on AWS, but not on Azure or Google Cloud.

Meanwhile, VMWare has taken to the airwaves stating that there are too many security offerings in the marketplace. The implication is that customers should turn to VMware for a simplified and seamless security umbrella.



Enterprise customers are attuned to VMware messaging and some have absorbed its technology and marketing pitch. While VMWare has robust server virtualization offerings, its security solutions are inadequate in relation to its features.

When what is being provided does not meet their fast-changing usage needs, customers either turn to complex and costly add-on solutions, or are otherwise hampered in their search for workload security across multi-cloud platforms.

Moving forward, enterprises should consider a true SDDC strategy that offers overarching protection for cross-platform assets. Don’t put blind faith in security for your entire company as provided by one of several cloud platforms in use.

Read More
ShieldX Product Reviews

ShieldX has been fortunate to have our amazing customers write some amazing reviews of the Elastic Security Platform on IT Central. Both reviews can be accessed here, but we’ve summarized some highlights below.  All are direct quotes while we’ve added emphasis.

From the first product review:

  • ShieldX makes the cloud safer than on-prem deployments. That is because that the number-one cause of security incidents today is human error, and those errors are often a result of very complex security structures. ShieldX makes it a lot easier and a lot simpler to define your policies and define your rules, and that greatly reduces the opportunity for user error.
  • ShieldX also enables us to migrate to cloud environments faster. That is an important part of it for sure because it takes the exact same policies that we would apply to our on-premise environment and enables us to simply apply them to the cloud. It becomes one policy for both on-prem and for the cloud.
  • The Adaptive Intention Engine is fantastic. It allows us to develop security policies using the language of our internal customers. It’s machine-learning applied to security workflows. That allows us to much more easily construct the policies that will protect those workflows.
  • It gives us a lower dollar-per-protected-megabyte than a traditional firewall, but it’s also consuming fewer resources in our network environment because we’re not having to send our traffic out of the virtual environment just to send it back in. It also helps with lower maintenance costs.
  • We switched to ShieldX because traditional firewalls are more expensive, and they require you to take all of your traffic outside of your virtual environment to inspect it and then return it back to the virtual environment. ShieldX lives inside of your virtual environment so it’s able to protect your workloads without having to send them north to a firewall only to come back down south to another resource.
  • We evaluated vArmour and Illumio. They didn’t meet our requirements. ShieldX is a superior solution and I can give you the quick differences: Illumio is really an orchestrator so it’s not providing security controls. It is managing the security controls provided by the operating system. It manages Windows Firewall, for example. vArmour, which is a closer comparison to ShieldX because it does provide security controls inside of the virtual environment, is one of those monolithic firewalls, so it does not scale as well.

From the second product review:

  • ShieldX has been designed from the very beginning to work well in cloud environments. It understands autoscaling, automation, and auto-configuration. These are the things which are important in today’s operating environment.
  • ShieldX ensures that we can have the separation needed for our environment to avoid drastically increasing the cost on the licensing side. From this perspective, it’s been very positive and helpful.
  • The Adaptive Intention Engine is important. The Adaptive Intention Engine explains what is the reason that we’re doing this security infrastructure, what are we trying to get out of it, and what’s the intent behind it? The problem with the way that things are done traditionally is you have an intent, but you now have to apply that intent in many places in order to achieve your goals. So, you end up with a duplication of effort in several areas. This is something which could take up quite a bit of time, both from an engineering, operations, maintenance, and troubleshooting perspective. If you have an issue now, you will need to look in two or three places to try and find the source of the issue. There was a lot of tracing which had to happen in our legacy operating method. In the new method, there is one place to design and apply a policy, which is simpler.
Read More

About Author

Ratinder Ahuja

Ratinder Ahuja

Founder & CEORatinder leads ShieldX and its mission as its central pivot point, drawing from a career as a successful serial entrepreneur and corporate leader, bringing with him his unique blend of business acumen, industry network and deep technical knowledge.

Test Drive ShieldX START NOW