Tag Archives: perimeter

Perimeter, Seneca Cliff, Bandages & Aspirin

Posted on by

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.

Cloud-Perimeter: Old habits die hard

Posted on by

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.

The Ethereal Perimeter

Posted on by

We all like simple and clear definitions.

Perimeter is perhaps the simplest definition of a complex concept. The analogy of ancient walled city lent itself quite naturally to the virtual walls of the enterprise.

But times are changing, and with them so do these time-honored concepts. Tempora mutantur, nos et mutamur in illis.

Quite a few voices nowadays call to replace the old and disappearing enterprise perimeter with a new perimeter — identity. Some call for “cloud perimeter”.

These voices are missing the mark though. It’s time for a fresh look at the concept of perimeter in the cloud era.

“Identity Is The New Perimeter“…

This discussion is going on for quite a few years.

Jericho Forum started it early in 2004 (the monumental treatise on the deperimeterization of the enterprise). Jericho’s assertion had been very simple: Just like the walls of biblical Jericho, which fell after the Israelite army marched around the city blowing their trumpets, so will the on-premise static and rigid perimeter, when the trumpets of the cloud blow.

In 2009-10, the cloud already established, Jericho Forum took it up a notch and proclaimed that “identity is the new perimeter“.

Security vendors began replicate that call. CA (identity as the new perimeter, 2013) and Ping Identity (Identity is the New Perimeter, 2014) echoed Jericho Forum’s trumpets, and the discussion continues on leading security media outlets (Identity and Access Management: Defining the New Security Perimeter, Is Identity The New Perimeter?, The new perimeter and the rise of IDaaS).

Let’s put things in order:

  1. The notion of perimeter as we know it, is dying
    • even if much of the on-premise networks continue to exist
  2. Perimeter is rapidly being outsourced to the cloud
    • and transformed into “cloud security” and “cloud access security (aka CASB)”
  3. The claim that “identity is the new perimeter” is based on faulty logic and misperception of the cloud
    • this error has to do with loss of ownership and control over “cloudified” IT assets
  4. Identity is NOT the new perimeter
    • but it’s much more than the sum of trivial access credentials (such as UID, password, token or certificate)
  5. We see the dawn of the Ethereal Perimeter
    • there is no “new perimeter” — we’re approaching the era of the perimeterless perimeter

Perimeter (as we know it) is dying

The foundations of perimeter are physical/rigid location and strict, visible ownership of all IT resources. These allow to surround them with the various security controls (firewall, IDS/IPS, anti-malware & web security gateways, VPN, IAM etc.) which collectively form the perimeter.

But in the cloud-era, both location and ownership rapidly vanish into thin air, that is —  the cloud. Let’s take a closer look at the transformation of IT to the cloud:

Applications:

  • “Old world”: Owned (licensed digital copies), sourced & managed by the enterprise IT. Typically located inside the enterprise LAN, behind the firewall.
  • Cloud-era: Owned, sourced and managed by SaaS vendors. Only the time-based usage rights are owned by the enterprise.

Data:

  • Old world: Owned, sourced & managed by the enterprise IT. Typically located inside the enterprise LAN, behind the firewall.
  • Cloud-era: Data is owned by the enterprise, but located elsewhere — SaaS vendors & datacenters. The ownership is manifested via legal agreement. No physical ownership.

Devices:

  • Old world: Owned, sourced & managed by the enterprise IT.
  • Cloud era: Plethora of devices. Increasingly owned by the users (BYOD) and only partially managed by the enterprise IT.

Network:

  • Old world: Owned, sourced & managed by the enterprise IT.
  • Cloud-era: Increasingly no-man’s-land. Connectivity owned by service providers, management and control is dispersed between service providers, cloud vendors and enterprise IT (on a very limited basis).

Users (employees):

  • Old world: Located mostly in the office, or connected via VPN (e.g. easily managed & controlled by the enterprise IT).
  • Cloud-era: Increasingly mobile (roaming, remote-workers, telecommuters).

Users’ identities:

  • Both in the old world and the cloud-era, users’ identities are owned & managed by the enterprise, relatively unchanged.

<Faulty> conclusions:

Since (1) the IT resources around which the perimeter was originally formed are disappearing from the on-premise network; (2) the old perimeter security controls can no longer protect the new cloudy resources; (3) only identity remains more or less unchanged; and (4) facing the cloud, identity becomes more critical than ever before — then perhaps perimeter can be reduced to identity credentials and access rights, because these are the only resources that the enterprise still owns and controls.

Ergo, “identity is the new perimeter”…

A very simplistic view, and one that’s easy to fall for. Problem is — its logic doesn’t really hold water.

Below: One of many “identity is the new perimeter” representations found on the web.

 

Some (Ping Identity for instance) even call it “new paradigm”:

Identity is NOT the new perimeter

Put boldly, the claims that identity is the new perimeter, e.g. can replace (even in part) the old perimeter security controls in the cloud era, is a false claim. It is also a very dangerous approach, as it neglects and downplays so many fundamental principles of sound security.

Traditional perimeter severely lacks in anything relating to identity. Perimeter is not identity aware, it was not designed to be identity aware, it refers to identity only as an afterthought. “Classic” perimeter security doesn’t provide any protection against identity-related threats. For all practical purposes network security, malware protection and identity protection/IAM have always existed as isolated silos. That hasn’t changed much. Recently I referred to some aspects of this gap in a blog post.

Similarly, identity protection, regardless of how it’s provided (authentication, broader IAM, federation etc.), isn’t malware-aware or network-aware. No identity protection can protect its user from any malware attack or network attack. It wasn’t designed to do that. Hence, it cannot replace, even in part, any of the key layers associated with perimeter security — be it in the cloud, on-premise or both.

Stating that identity is the new perimeter doesn’t magically turn IAM (or any identity protection for that matter) into an all-around security layer.

So here’s a rather self-explanatory example of cloud-based attack with no identity-related breaches:

Cloud service (e.g. Box, DropBox, Google Drive etc.) is attacked via the web. Stored files get infected by malware (infection can similarly occur when a user simply uploads infected file). Enterprise user logs into the contaminated cloud service and downloads the malicious file, thus infecting the user’s endpoint. Thereafter, the malware begins to move laterally within the enterprise network, infecting more machines/users, launching attacks on file/mail servers and even steal data from restricted repositories (a good dictionary attack can break into secured server without using stolen user credentials). Stolen data is then sent back to the cloud (same or different cloud vendor), where the botnet also resides. This vanilla attack is carried out without compromising a single identity, nor stealing a single set of privileged credentials. This kind of attack is more common than most vendors care to admit.

No identity/IAM solution can detect, let alone protect against such attacks. Unfortunately, none of the legacy security solutions can efficiently deal with such a scenario either, and quite frankly — the new cloud-based security services claiming to handle these kind of scenarios are yet to prove their claims.

Reducing the perimeter to identity alone leaves the medium between the user and the cloud resources completely unprotected and largely unmanaged.

However, identity protection can critically enhance these security layers, provide more context and more data points to allow the perimeter security (old and “new”) make better, more accurate and more timely decisions. These days, no good security can be provided without comprehensive identity-related security.

Welcome to the Ethereal Perimeter

So where does that leave us? If anything, the most accurate description of the “new perimeter” actually comes with the territory — the Ethereal Perimeter.

Truth be told, there is no “new perimeter”. The perimeter is gone, became a “perimeterless perimeter”, and we need to adopt new paradigms that will hopefully lead to new and better security technologies.

Users, applications and data are massively distributed in numerous locations. So how do you provide a “perimeter-class” security in such an ethereal environment?

Middle-of-the-road solutions proliferate these days. Some are routing all cloud traffic through on-premise gateways thus subjecting the cloud-traffic to a known perimeter. Some are simply cloud-based gateways, routing the cloud-traffic through them, delivering a cloud replica of the on-premise perimeter, with some additions dealing with pure-cloud security threats and cloud-usage. SaaS vendors on their part deliver partial perimeter security by implementing some security controls in their datacenters. But the logic  is the same — centralize & reduce distribution — forcing the cloud into some sort of perimeter. They apply the old logic of “hardening” by providing a seemingly “hardened cloud”. In the long run, these approaches will have to change and evolve, as the very nature of the cloud is being distributed.

New technologies and approaches must be introduced. They will have to be capable of dealing with the new territory by being distributed and flexible by design. They will have to be orders of magnitude more intelligent than present perimeter security and cloud security. They will have to be capable of dealing with the incredibly rich context of each instance and each transaction.

The Ethereal Perimeter will not be a monolithic one, but a distributed one: It will not owned by any single entity (such as enterprise) but by several entities AND trusted brokers. It must be capable of communicating, brokering, resolving and mitigating multiple perimeter-parties simultaneously.

The Ethereal Perimeter will be much more a network/cloud organism than a visible steel-belt layer.

Some food for thought:

  • Users/devices: Should be encapsulated by a tiny, mobile “endpoint perimeter”. With virtualization maturing to deal with very small form factors, we’re not far from getting there.
  • Data: Must be encrypted at all times, in transit and at rest.
  • Applications: Must be protected by a “perimeter layer”, which on top of the traditional security controls, must also be able to communicate with the “endpoint perimeters” and identity providers/brokers, understand the context of each.
  • Identity: Since everything in the cloud-era is “identity-rich“, and identity is becoming much more complicated than the old days when it consisted of simple access credentials, new identity providers must be formed. There should be trusted identity providers and brokers, providing “chain of trust” to identity — much like the existing certificates chain of trust.
  • “Instance mitigation”: Since no strict, rigid and monolithic ownership of the perimeter will exist, the mitigation and temporary authority to take decisions will shift from “perimeter party” to another based on context. For instance: When user logs-in to a SaaS app, the SaaS app takes “leadership” and is responsible to resolve all issues, negotiate with the identity broker etc. When the user downloads a files from the cloud, this “leadership” will shift to the “endpoint perimeter” and so forth.

The Ethereal Perimeter will be a very complicated medium. No escape from that.

“The discipline of a lifetime now collapses like the fabled walls of Jericho. Who is Joshua, and what is the tune his trumpets play? I wish I knew. The music that has worked such havoc against such old walls is not loud. It is faint, diffuse, and peculiar. – Kurt Vonnegut, Mother Night

The Ethereal Identity

We know much about malware and network attacks, but very little about identity. While identity may not be the new perimeter, it certainly is the last frontier of perimeter security that is yet to be conquered.

So that’s coming up next…