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.

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.

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.”