Beyond Native Cloud Security Controls

One thing you tend to get with a move to the cloud is a flat network. You have a virtual network perimeter, but inside the network, you’ve got no points of control unless you put them there by hand. If you logically group your workloads along the lines of an old-school tiered architecture, you can put in virtual appliances such as next-gen firewalls, but you have to do this manually and it’s not a setup that really delivers on your need to scale workloads dynamically. At the end of the day, this means security remains a drag on the business and no one wants to be “the guy” who slows things down.

This was all spelled out in a great article that recently appeared on SearchSecurity.com. In the article, Dave Shackleford spelled out his laundry list of what’s wrong with a non-cloud approach to securing cloud infrastructure:

  1. Flat networks abound
  2. No native monitoring of east-west traffic
  3. Limited routing control
  4. Network access control is often primitive
  5. Inline intrusion detection are difficult to implement
  6. Content-based inspection capabilities are scarce

He goes on to point out that it’s possible to remedy some of these ills using some of the native capabilities in cloud environments, such as security groups in AWS and network security groups in Azure. While I agree that it’s possible to tighten up a network this way, there are some important ways in which this approach falls short when even mildly stressed. The primary issue is complexity—lots of workloads and lots on interconnections among them—and this has to be countered with automation. You simply must have automation to handle the process of configuring the microsegments that connect all the workloads on your network.

Bottom line: you need to get the logic of your security controls expressed directly in the interconnections of your network architecture. Again, you could in theory do this by hand using the tools I’ve mentioned, but if your infrastructure is of any size or complexity at all, you really need the next level of tools to automate this. Not only that, but you need these tools to dynamically follow the changes in server workloads on your network on an ongoing basis and readjust policies and microsegments on the fly.

As ShieldX is deployed, it automatically creates a summary of your workload assets and then uses a machine learning algorithm to discern what kinds of processes are running on each workload. If your organization uses containers and has developed a discipline of tagging your workloads, these tags are used to directly and automatically deploy policies to govern the microsegmentation of your network. Otherwise, the grouped workloads are presented to you in a user interface that makes it easy to express policies for kinds of workloads.

From all of this, logical tiers are created and dynamically updated so that the tiers continue to govern communications among workloads as workloads scale up or down within various tiers. This elastic tiering is unlike anything offered by any other vendor and—another unique characteristic—this is done without the need to deploy agent software onto each workload.

Why does it matter whether software agents are used? For one thing, in legacy situations it sometimes just isn’t possible. Perhaps more importantly, this runs counter to the very idea of containerization, where you want one service or function encapsulated per container (and often isn’t possible even if you don’t care about the aesthetics of it). Either way, you wind up with a microsegmentation capability that leaves critical workloads out of the equation.

ShieldX doesn’t use agents. It also doesn’t rely on the manipulation of ACLs, the problem being that ACLs are an inherently IP-address-centric approach. More agile microsegmentation is possible using approaches such as Cisco Underlay Networks and Azure User-Defined Routes.

To conclude, the ideal multi-cloud solution would:

  • Automate and continuous discovery of assets.
  • Autogenerate security policy.
  • Auto deploy controls to fulfill dictated policies.

Without this level of automation, security teams continue to exist in a perpetual hamster wheel. The cloud—along with cloud native solutions—bring the promise of automation and economics that traditional vendors have failed to leverage.  In the old days, IT teams manually managed networks but eventually migrated to SDN.  Now, with ShieldX, its security can enjoy the same level of agility.

Read More
Why I Joined ShieldX

We recently announced that I joined ShieldX Networks as CEO.

Like many job seekers, I relied on friends and trusted colleagues to inform my decision. Mike Fey first turned me onto ShieldX (he recently outlined his reasons for investing in ShieldX and it is a must read). Mike encouraged me to invest alongside him. Consequently, when the ShieldX team started to look for a CEO to partner with the founding team, a much more direct level of involvement began to surface. It did not take long for me to recognize that ShieldX is where I wanted to be, if the founders and board would have me. While there were several reasons this opportunity was so compelling, it came down to four main drivers.

Market opportunity.
The ShieldX Elastic Security Platform could well be THE enabling security offering with the ability to both enable the “migration to” and “security promises” of microsegmentation in the era of cloud computing. The move to the cloud is fundamentally changing how IT and networking are done, how applications are developed, where security risks need to be mitigated and how security needs to be inherently and elastically applied. To date, many enterprises have begun their data center transition to the cloud, but during this transition, hackers and malicious insiders have uncovered and exploited blind spots—particularly along the emerging East-West data center. We, as an industry, have spent a few decades focused on securing North-South network traffic boundaries; but as networks became flatter, larger and more dynamic, a growing attack surface within arose that led to an ever growing number of security breaches due to attacks spreading on the East-West axis.

What if we could offer improved network security by using elastic security software, which offers visibility, policy generation for microsegmentation and a rich set of dynamic security controls to enable fully automated security in this new world? What if we could simplify achieving and reporting on compliance in the cloud? For CISOs, the current set of market options means buying multiple point products, some of which are being shoehorned into solving a problem they were never designed to solve.

Further, what if we could offer security without increasing customer overhead? ShieldX does this with technology that was designed from the ground up to serve in this elastic environment where it once was impossible to define your network security posture. As Mike Fey stated in his blog, “East west security is more important than north south.”  ShieldX can—and will—protect all data center workloads in the future. As anyone interested in deploying a Zero Trust effort will understand—ShieldX is in the thick of an important market.

Today, the majority of approaches to microsegmentation require agents. Not ShieldX. Instead, ShieldX pioneered an application layer security approach that brings visibility to traffic patterns enterprises haven’t seen before the arrival of multi cloud.  And it is not just visibility. ShieldX’s approach also brings application layer threat prevention.  Remember what IPS brought to on-prem network perimeters? ShieldX does this in your cloud.  Being agentless allows for robust functionality like virtual patching, for example virtually patching cloud workloads which combats the new trend in ransomware, where the new target is unpatched workloads/VMs in your data center and cloud. And then there’s automation.  One of ShieldX’s customers used to have a firewall analyst update policies taking up four hours (!) daily. Our automated policy enforcement dynamically assigns policies based on predefined criteria aligned to your business process, enabling this valuable resource to be redeployed into more strategic activities.

I knew Ratinder and Manuel professionally and by reputation from McAfee. Both are innovators and famous within the industry for good reason. When stars aligned and Ratinder and the ShieldX board were looking for a CEO partner, it was hard to not get excited. The team that built ShieldX is hard to duplicate. Few innovators could build a platform that promises to upend security as enterprises move to the cloud. Also, if one looks at the other people associated with the company, be it investors, board members or advisors, they would have to say this is truly a “hall of fame” caliber line up.

Competitive landscape
Today, if you want security in the cloud you have to choose between virtual firewalls, agent-based technology or go with cloud-native capabilities. Virtual firewalls suffer two fundamental problems—they don’t scale elastically in the cloud and they create way too much administrative overhead in an ever-changing cloud environment. If you require more TLS decryption in an environment for inspection, for instance, you need to buy more licenses of the firewall to achieve the required TLS decryption; even if you don’t need other features included in that license. Worse, because of the extra traffic incurred by virtual firewalls, you’ll end up paying excessive CPU overhead costs and you’ll have to hire additional network security staff to administrate ACLs in your ever-changing cloud environment. Cloud native providers supply basic security capabilities, but they are hardly best of breed, they too require way too much overhead to constantly re-configure, they only support their own platform, and lack the advanced application layer security capabilities security teams require. And many new entrants in this space require agents. The drawbacks of agents are pretty well known but you can always ask one self-answering question:  Is it OK in a production environment to deploy agents to workloads without extensive QA and compatibility testing? Perhaps the biggest deficiency of all the above approaches is their lack of automation. By contrast, ShieldX installs quickly and brings fast time to value.  More importantly, our software is architected to provide elastic scalability and makes policy and control management dramatically simpler.  At the end of the day, ShieldX lowers your operational costs to enable microsegmentation and lateral movement protection. Bottom line: ShieldX brings an unfair advantage to the market.

I encourage you to try ShieldX. Three of our customers not only influenced my decision to join, but also echoed my sentiments in these detailed reviews including this compelling testimonial from Alaska Air:

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 also enables us to migrate to cloud environments faster.

Read More
Capital One Breach—Its Cloudier than you Think

Looks like another breach—but this one continues a recent trend we’ve been seeing on the rise.  Namely, the attacker took advantage of poorly or mis-configured firewall to access cloud-based data.  Some claim it was a web application firewall, other reports aren’t clear.  Regardless, as we move into multi cloud, this problem is becoming more and more pervasive.

Capital One was, like many companies, is stuck in a time warp.  Historically security was done mostly by fortifying the perimeter of the network, assuming that the adversaries could be kept out by locking a single gate or chokepoint.  More and more, we learn that this architecture is no longer effective, as there is an incongruity between the physical data center boundary and virtual perimeters. Those new perimeters can take up any size and shape and change at cloud speeds making it impossible for traditional security to follow—especially traditional firewalls. Worse, the security controls offered by cloud vendors are weaker than traditional options and are often no match against sophisticated attacks.  In this case, the attacker was a former AWS employee who likely knew the ins and outs of the fragmented, cloud-based network.

What are the lessons?

  1. Without auto-generation of policies, those dynamic environments will always have sub optimal configurations on the firewalls. Today, many enterprises employ people whose sole function is to update firewalls policies.  Spending hours every day—often a full time role!—security teams have people who constantly update firewall policies.  When you move the cloud, this isn’t scalable, its impossible for humans to keep up.
  2. Its not just the automated security policy generation—you also need automated control deployment. Policies are only as good as the controls that drive them.  Even if you get policies under control, the dynamic nature of the cloud still means the controls must adapt at the same, instant speed.
  3. Intention, intention and intention.  Automation isn’t enough if you can’t tell your system what you want it to do.  When you input a destination into Waze, hiccups happen.  Does Waze say, “sorry, you can’t go there anymore.”?  No, it adjusts,  The same flexibility is required in security: continues and automated transformation of the security intent into security controls eliminating configuration errors over time.
  4. East West is the new North South.  Tracking lateral movement in a fragmented cloud environment is more critical than ever.

You’ve moved to the multi cloud—welcome to the new reality.  One of the biggest questions facing every senior security professional is figuring out how to secure enterprise networks as they fundamentally and constantly change over time. This requires a level of flexibility and scale heretofore unknown in the security industry. Traditional appliance-based solutions were built monolithically and are not well suited to cloud architectures. And new cloud friendly products do not provide the depth of security to protect environments from the variety of attacks typically faced.

So what can you do?  Check out our CISO’s Guide to Multi Cloud Security which provides more than a few clues.

Read More
Why I invested in ShieldX

I have had the pleasure of working with the Shield X team for a couple years and recently made a significant personal investment in the company.  Why?

First, let’s assess just how cloud computing has impacted security.  In my view, the future of how we defend workloads in the cloud requires a ground up re-architecture.  We all grew up with a “defend the north-south” mentality and didn’t think much about east-west defense.  And for good reason—defending east-west was extremely difficult, expensive and simply couldn’t scale.  In a cloud native future, however, east west is as risk-laden as north south in the “old” days. As enterprises place their data centers in the cloud, you’ve essentially fragmented your crown jewels.  Enterprises are now realizing just how much security and compliance postures become downgraded by a move to the cloud.

Historically security was done mostly by fortifying the perimeter of the network.  That architecture is no longer effective, as there is an incongruity between the physical datacenter boundary and virtual perimeters. Those new perimeters can take up any size and shape and change at cloud speeds making it impossible for traditional security to follow. Additionally, the security controls offered by cloud vendors are weaker than traditional options and are often no match against attacks hindering confidence and compliance in cloud adoption.

Today, many vendors tackle the problem with agents, rigid rules sets or hard coded approaches.  Inevitably, you’ll be let down in your cloud migration journey if you deploy any of these options with negative repercussions on compliance, security and cost. Many early adopters of agent-based approaches already regret their decision.

This is where ShieldX comes in.

ShieldX represents a new and very needed way to do security.  ShieldX, is a perfectly designed solution built for the new cloud paradigm.  Not only does ShieldX fix the flat network problem, but it also makes compliance a no brainer.  And ShieldX doesn’t stop there, bringing:

  • Visibility:  ShieldX discovers infrastructure assets such as networks, virtual switches, DV switches, virtual private clouds, vNets, subnets, workloads, tags and so on. Monitor network traffic and using machine learning arrange assets in application views. ShieldX uses traffic classification and network scanning to understand the attack surfaces and vulnerabilities.  In addition, ShieldX uses data classification of both data in motion and data at rest to understand information loss risk.
  • Compliance: Passing an auditwhen your data and applications are all over the cloud often serve as a wakeup call for cloud security.  The ever-changing nature of the cloud are diametrically opposed to the neat, orderly and segmented environments auditors like to see.  With ShieldX’s microservices architecture, security enjoys a cloud-native solution that works the way cloud tools are supposed to—elastic and scalable while satisfying auditors.
  • Automation:  Combined with machine learning, ShieldX uses its visibility to provide a risk view and suggest appropriate micro segmentation and advanced security policies. The security operator can use the application model, along with the risk view and the suggested security policies to create their security intent easily and quickly.
  • Full-stack security controls to extend coverage where you don’t have any–ShieldX provides a comprehensive set of controls that go beyond basic ACLs, including micro-segmentation, access control, threat prevention, malware detection, URL classification and filtering, TLS decryption, indicator of pivot detection, anomaly detection, sensitive data migration detection and more which are policy-based and adaptive.

Moving forward, as enterprises continue their massive shift away from VMs and into true cloud architecture, ShieldX will be at the forefront of their defense strategy. In summary, ShieldX is the only solution that continuously discovers workload applications and associated risk, automates policy generation and control deployment in the multi cloud.

Read More
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

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