Perimeter, Seneca Cliff, Bandages & Aspirin

Increases are of sluggish growth, but the way to ruin is rapid (Seneca, circa 65 AD)

The ancients Romans got it right: Seneca’s observation on growth and decline is insightful.

Take for instance data breaches and enterprise perimeter.

Perimeters are built incrementally, typically in layers, with numerous patches in between, over many years. Each enterprise’s security model consists in large part on the way the perimeter was designed, built and maintained.

Yet all it takes is one massive data breach to break one’s entire security model, and literally cause the perimeter to implode (most data breaches originate from remote access, e.g. breach of perimeter).

These data breaches are perfect examples of Seneca Cliff Effect.

Seneca Cliff Effect implies that a structure, built over a long time in a stable environment, cannot withstand an unplanned, unthought-of shock. Once that happens, the structure implodes. The shock isn’t a “Black Swan”, e.g. a high-impact, low-probability and hard to predict event. It’s just an event the structure wasn’t built to deal with, such as exploiting a naive flaw in the perimeter to exfiltrate massive amounts of sensitive data.

The breach itself is merely the trigger. It’s the after shocks that bring the implosion.

What’s also implied in this model is that the implosion happens when growth (or complexity) has reached its limit.

How can Seneca cliff effect be avoided? Is it just by poking a finger in the dyke’s hole, or does it call for a review of the entire structure (perimeter in our case)?

Can bandages & aspirin fix collateral damage?

Many of the solutions we see today, including those tagged as innovative or disruptive, do not represent a fundamental departure from the <already-broken / about-to-be-broken> security model. They are more of a local treatment, temporary relief: Bandage and aspirin applied to a severe injury.

In other words: They are more of the same.

Bandage: “Let’s segmentize our network (to death..)”

What:

Microsegmentation, Software-Defined Segmentation (SDS), “Segment of One”…

Crux:

Take the existing local network and merely break it down to isolated segments, so that if one segment is breached, the other segments are secure.

Symptoms:

More layers, more controls, more appliances, more complexity (more confusion).

Counterview:

These solutions mainly make the hacker’s job slightly harder, but once even one segment of the network is breached, it’s only a matter of time until the rest will be breached too. The cost of implementing these solutions: More management overhead and more complexity.

Aspirin: “Let’s move our network to the cloud”

What:

Firewall as a Service (FWaaS) , Software-Defined Perimeter (SDP) , Network security as a Service…

Crux:

Take the existing local network and merely move part(s) of it to a cloud service (the “as a service” part), or add more elements (the SDP part) to it, further complicating it. Either way — keep the existing network topology & framework intact.

Symptoms:

More environments to manage, more layers, more controls, more complexity (more confusion). Integration pains with other perimeter services remain intact (or getting worse).

Counterview:

If the fundamental premise of these solutions isn’t different than the existing ones, how can change of location (on-premise > cloud) or changing the order of existing layers provide more security and better way to avoid the Seneca cliff effect?

Quo vadis perimeter?

Think about the complexity the IT staff is facing:

  • Most of the users are remote users (if one is pulling mail on mobile device, one is a remote user, regardless of one’s physical location)
  • Applications are everywhere (on-premise, IaaS, PaaS, SaaS)
  • The local enterprise network (LAN) is long dead. It’s broken to many locations and diverse environments
  • Enterprises typically use more than one cloud service — hybrid, multi-cloud etc.

How can adding more layers and controls, or replacing one or two layers with new ones, resolve security issues resulting from the very design of the perimeter?

Isn’t it time for a new approach, for a fresh look at the entire thing?

Every cloud has a silver lining

Consider these fundamentals and building blocks:

Secure (isolate) what matters, remove the rest:

The smallest unit to secure isn’t a network segment, rather it is the application. Focus on apps and isolate them, remove the rest. Remove, meaning — make these parts completely disconnected and inaccessible. Provide the users with only temporary access, to designated apps only, never to the network. Establish an end-to-end zero-trust model.

Simplify:

Security hinges on simplicity, not on complexity. Complexity must be dealt with by the vendor, not the user. Build comprehensive integrated solutions, which are easy to understand, easier to manage & control and require little or zero integration. Use-cases served by the solution must be covered in their entirety — end-to-end approach. Make the layers that are auxiliary ones, even if critical (e.g. proxy, ADC, LBS), completely transparent. The aim: The solution should just work.

Centralize:

Use the power of the cloud wisely: One deployment, one point of control and management, globally.

Scale:

Use the power of the cloud effectively: Make the solution scalable and elastic, capable of accommodating every usage scenario.

Sum Up

Some title this approach “Cloud DMZ”, others — remote access as a service. Whatever the title would be, the result should be the same: All a customer has to do is sign up, connect users on one end, apps on the other, and start working, securely. If it takes more than a few hours at the most, something is wrong with the solution.

Hybrid Enterprise Requires Hybrid Security

We, at Soha Systems, attended IBM InterConnect conference, late February. Amidst the multitude of announcements made during that week, the one that resonated most with us was the one that covered IBM’s partnership with VMware around hybrid enterprise (IBM Wants VMware Shops On its Cloud, How IBM Stole Google’s Thunder).

As a cloud security vendor focusing on providing security to hybrid enterprises, we were intrigued by this announcement, which added a significant building block to the visibility of hybrid enterprise. Here’s our take on this subject matter.

We love public cloud. It’s disruptive. It forces IT staff to rethink time-honored traditions and habits. It is truly an incredible phenomenon. But public cloud is only one piece of a much bigger puzzle — that of the hybrid enterprise (aka hybrid IT or hybrid cloud).

Most enterprises are, or will become, hybrid entities. That is, they will have workloads and apps distributed in a number of public clouds, on private clouds and in their own existing data-centers. Very few enterprises, if any at all, will move 100% of their infrastructure to the public cloud, let alone bet on a single public cloud provider.

Gartner, IDC, Ovum and other industry analysts estimate that 80% of all enterprises will commit to hybrid cloud within the next 2 years. This makes the hybrid cloud market much bigger than the public cloud market.

Hybrid IT is the new IT and is here to stay (Chris Howard, Vice President and Chief of Research, Gartner)

The hybrid enterprise is a continuum:

This continuum is suggestive, not deterministic. As a matter of fact, numerous enterprises turn to public cloud first, and when enough workloads run there, they tend to move to private cloud, sometimes in their own premises. Moving from public cloud back to your own premises is a perfectly “cloudy” phenomenon — a classic hybrid move.

Challenges to provide security to hybrid enterprise

Existing IT security solutions focus mainly/only on existing on-premises infrastructure. They provide software and appliances, and have been doing this for the last 25 years. On the other hand, the new cloud security vendors focus only on securing cloud workloads and apps.

So from IT security staff perspective, the cloud means more complexity, more solutions from new vendors, more dashboards, etc. So much so that Cisco recently issued a warning stating that complexity remains the enemy of security. But THE premise and promise of the cloud is simplification of IT. So what’s missing? Where’s the gap?

How should security to hybrid enterprise be provided?

The only way to bridge that gap is by introducing a completely new security model: Plainly put, hybrid enterprise requires hybrid security. Not security retrofitted for the hybrid world, but security that is designed and built from the ground-up to support the hybrid enterprise.

Fundamentals of hybrid security model:

  1. Hybrid security should be a native, as-a-service solution
  2. Hybrid security service should be an integrated end-to-end solution, save time and cost of purchase, integration and management. It should result in lower TCO and simplified IT
  3. Hybrid security service should be able to secure payloads running in any and all behind-the-firewall environments (e.g. should be able to provide security to on-premises enterprise apps and enterprise cloud apps alike, with the same ease of use, with little-or-no integration)
  4. Hybrid security service should be able to run, as a native cloud service, both in multi-tenant, single-tenant and on-premises modes, retaining the same level of functionality, elasticity, scalability and manageability in all modes
  5. Hybrid security service should provide a single point of configuration and management to all secured applications, a single pane of glass
  6. Hybrid security service should facilitate migration of applications from one environment to another, detaching the security from any single cloud provider, to allow delivery of security to all clouds and all environments (“software defined security” if you will)

It takes a village to raise a child

At Soha Systems, that is exactly what we have developed. It takes many years of enterprise experience to understand the complexities of integrated security solutions, let alone migration from one environment to another.

The result of this vast experience is a solution that brings the above principles to real life. Check it out…

 

From the enterprise to the cloud and back again…

An interesting trend is gathering steam. SaaS vendors are trying to extend their services to the enterprise infrastructure (aka “behind the firewall” applications) by offering connectivity to their cloud services by means of API integration.

3 questions arise:

  1. Why would SaaS vendors try to connect to the old on-premise world?
  2. Why would they do that using API integration (e.g. literally forcing their customers to hand-wire it)?
  3. What is the best way to extend cloud services to on-premise and behind the firewall applications?

Some context:

When enterprises began adopting SaaS applications, security concerns arose. Cloud security vendors (CASBs, gateways, brokers..) emerged to provide enterprises with a measure of security and control over public SaaS applications.

As time went by, enterprises increasingly adopted the cloud, building and deploying enterprise applications in private and public clouds. These applications were/are provided as a service, but only to the enterprise’s users (employees, contractors etc.).

Some people call them “cloud applications” because they are staged and run in the cloud. This created confusion between these applications and SaaS applications. The confusion has recently exasperated as they are become known as “enterprise SaaS” and “IT SaaS”.

Let’s put things in order.

SaaS (e.g. salesforce) and “enterprise SaaS” are NOT the same

It’s all about ownership and control:

  • If it’s owned and controlled by someone else (i.e. NOT by the enterprise), and is publicly available to all, it’s SaaS.
  • If it’s owned and controlled by the enterprise, is located behind the enterprise firewall and available only to the enterprise’s users, it’s “enterprise SaaS” (even if it’s run on AWS or Azure).

SaaS is not driving enterprise applications to extinction

Not every enterprise application is destined to become SaaS.

For many reasons (security, compliance, special customization) not every application that can be sourced as SaaS, will be sourced as such. Enterprises do not easily surrender their data and resources to external service providers.

Many legacy enterprise applications are moving to the cloud. But enterprise applications running in private or public clouds are the same good old behind-the-firewall enterprise applications. They just changed location and form of delivery. Nothing else has changed.

Cloud computing revived the life of enterprise applications, allowing internal applications to be delivered as a service. It also created a thriving DevOps scene. DevOps means one thing: MORE enterprise applications.

Cloud services at large, SaaS in particular, were not designed to provide services to enterprise applications behind the firewall

SaaS applications were designed as integrated service platforms to accommodate many users (and other SaaS applications) coming in to them. They were not designed to build pipes and connectors to environments that are not cloud-based.

But the “behind the firewall” market is huge. Actually it’s still much larger than the SaaS market. So how do SaaS vendors meet that temptation? — provide APIs to integrate to behind the firewall infrastructure…

About APIs and cloud services

API integration means letting the enterprise customer hand-wire the cloud service to its internal IT. Obviously, this is not a scalable model. Worse: It means MORE complexity. APIs do not simplify life (or costs) for IT staff.

APIs are by nature insecure.

API integration means the enterprise exposes its internal services to external (and thus untrusted) entity. APIs are poking holes in the enterprise network. So they require the customer to add another layer of security — API security — to the already too-complicated and hardly-manageable IT.

But cloud is all about LESS wiring and less IT complexity, is it not?…

So what is THE way to integrate native cloud services into behind-the-firewall environments?

In order to do that, one has to have a footprint in the enterprise network. A footprint which is minute enough to be easy, simple and painless to set up, yet advanced enough to increase simplicity, flexibility and security.

As a matter of fact, at Soha we did just that.

Cloud-Perimeter: Old habits die hard

The cloud disrupts IT and compute paradigms, and allows us to rethink everything about them. But more often than not, the move to the cloud means merely transfer of on-premise IT to cloud environment, almost unchanged.

Perimeter is one such example.

Like most other security means, perimeter (aka DMZ) was born out of necessity — set a secure buffer zone between the untrusted external network (Internet) and the trusted internal network (corporate LAN). Perimeter is the component of the network that is designed to “take the bullet” for the network it protects, to serve as the first (or last, depending on your point of view) line of defense.

What is perimeter?

“In computer security, a DMZ or demilitarized zone (sometimes referred to as aperimeter network) is a physical or logical subnetwork that contains and exposes an organization’s external-facing services to a larger and untrusted network, usually the Internet. The purpose of a DMZ is to add an additional layer of security to an organization’s local area network (LAN); an external network node only has direct access to equipment in the DMZ, rather than any other part of the network. The name is derived from the term “demilitarized zone”, an area between nation states in which military operation is not permitted.” — (source: Wikipedia)

The early perimeter was very simple: One or two firewalls and a VPN. Over the years, with the growing number of Internet-facing services and remote users, more security and network services were added to the perimeter (e.g. WAN Optimization, Server Load Balancing, Application Delivery Controllers, Web Application Firewalls, DDoS protection, IAM).

A simple perimeter:

In reality, perimeter did not — and cannot — provide the level of protection it is supposed to provide. The increasing number of security and data breaches we witness, and their severity, are evidence of that. In most of these breaches the attackers were able to penetrate the perimeter protection rather easily.

The problem with old world perimeter

Perimeter can be hacked and penetrated in many ways — it is merely a more secure and isolated network segment. But once attackers penetrate the perimeter (and they do…), they are effectively in the corporate network.

Why is perimeter part of the network? It has to do with the architecture of early corporate networks that were fixed and rigid.

Interestingly, with the move of corporate resources to the cloud, the same paradigms persist. Enterprises simply build corporate network segments in the cloud (e.g. VPC). The perimeter follows, and becomes a replica of the on-premise perimeter — attached to the corporate network in the cloud, and part of that network.

Now, the A-B-C of security begins with isolation and separation. The more isolated and separated the resource is, the more secure it is expected to be. So why not completely isolate and separate the perimeter from the corporate network?

If the cloud allows us to do things differently (and better…), why stick to the old practices when we know they fail?

Enter cloud perimeter

Consider a standalone cloud-based perimeter, delivered as a service: The separation and isolation from any network or cloud it protects are inherent. It’s physically and logically isolated from the application environment it protects.

Conceptual illustration of cloud-perimeter:

Such a cloud-based-perimeter comes with multiple additional benefits:

  • Removes the attack surface from the corporate network edge: perimeter is the attack surface of the network it protects. If the perimeter is provided as a cloud service, the attack surface is removed for the corporate network.
  • Hides the protected applications: When cloud applications are protected by a cloud perimeter, users who access them cannot even know what cloud they’re running on. Effectively, the cloud-perimeter hides cloud applications from the public Internet, yet makes them completely accessible to authorized users.
  • Provides a single, unified, central perimeter for all corporate environments (public cloud, private cloud, on-premise etc.): Since a cloud service by its very nature can serve any number of connected environments, there’s no need to set-up or configure new perimeter with every new application that requires remote access, or with every new network location (e.g. new branch office). Think of it as a “perimeter hub”.
  • Can be easily replicated to regions and zones: Another property of a cloud service — it is omnipresent (e.g. local and regional POPs).
  • Has no scalability pains: Cloud service is inherently elastic and extensible. Additional services are automatically deployed and scaled up.
  • Significantly reduces the “cloud lock-in” phenomenon: If perimeter (and other fundamental services) are provided by the host/public cloud platform, they are exclusive to the cloud platform, hence — “lock-in” the customer to that cloud platform.
  • No upfront or ongoing integration and no maintenance costs: Cloud service is all about subscription, not upfront investment.

Veteran IT folks use to say that perimeter is “IT’s unwanted and unloved child”. It’s also one of IT’s budgetary black-holes. Cloud-based perimeter can change that.