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.

Hybrid Enterprise Requires Hybrid Security

Posted on by

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…

Posted on by

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

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.

Cloud Lock-In, Secular Shift and the Bright Star of Soha

Posted on by

Every now and then, when a publicly traded company’s quarterly earnings whiff, you hear the “secular shift” song. It’s a lament about how the “Hotel California Syndrome” doesn’t work anymore. In other words, “vendor lock-in” is loosing its grip on the customers.

OK, translation for the uninitiated:

  • “Vendor lock-in”: aka “proprietary lock-in”, “customer lock-in” and “technology lock-in”, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs (source: Wikipedia).
  • “Hotel California Syndrome”: The concern of vendor lock-in (“You can check-out any time you like, But you can never leave”).
  • “Secular shift”: Customers are becoming less committed to a specific vendor, or platform; are less religious in their consumption of HW, SW and services; are becoming freer and more opportunistic in their IT choices.

The public discussion about cloud lock-in has gone quiet recently. Perhaps it is because the options are becoming fewer with the recent give-ins of so many vendors (HP, Rackspace and VMware vCloud to mention but 3). Perhaps it is because many customers have just given up on their freedom.

Thing is, there are actually two cloud lock-ins. And of the second lock-in, which is much costlier and more painful, no one speaks of.

There’s the visible part of the cloud lock-in: The cloud service itself. The switching costs and pains are well known. This is not the cloud lock-in we’re talking about.

Then there’s the invisible part: The security apps, network tools, integration and configuration one has to do in order to make one’s cloud-staged apps functional. It’s a hefty corollary price (or a collateral damage…) the customer has to pay in order to make the cloud actually work. Very little of it (if any) is provided by the cloud providers as part of their platform or as (paid…) add-ons.

Let’s take a look at this pain. What does the “corollary cloud lock-in” consist of?

  • Firewall
  • VPN
  • WAF
  • DDoS
  • IAM
  • WAN optimization
  • Application delivery controllers
  • And much more…

Sounds painfully familiar? It’s the DMZ, with all of its gravy and trimmings, and then some. This list of pains represent significant cost and time investment. It’s a sunken cost, as it’s the cost of making the cloud actually work.

To make matters worse, this investment is tied to the specific cloud provider one chooses. It’s not transferable, scalable or extensible to other clouds the customer uses. This expensive effort is so painful the mere thought of going through it again as part of migrating to a different cloud provider is enough to scare the customer away from it.

So in effect there is a double cloud lock-in.

In many ways “cloud religion” is a forced one. One is perhaps lured into a certain cool and hot cloud platform, but then is mired by what it really takes to actually consume the cloud.

So how do you unlock your cloud?

  1. Build the entire perimeter-related controls (security, access, network, delivery) as a native cloud service
    • Result: Much less cost, much more freedom.
  2. Design it in a way that allows it to be extended to any enterprise network (private cloud, public cloud, even old datacenter)
    • Result: Omnipresence. The solution applies anywhere.
  3. Make it such that it deploys fast and painless by anyone and not just IT professionals.
    • Result: Migration to the cloud is made affordable and easy. A huge hurdle is removed.

If you do that, you remove the invisible and costly lock-in, and make your cloud freedom much closer to reality. As a matter of fact, we did just this. We unlock your cloud. You’re no longer “stuck in the mud”. Take a look at Soha.

Why I joined Soha, or Goodbye Old Perimeter

Posted on by

It doesn’t come often that you see a company and tell yourself “I’ve gotta join this company”. Especially not after 25-odd years in the industry. Well, it so happens there is one such company – Soha Systems.

Let’s go back a few years.

Enterprise perimeter has always been a “thing” for me (perhaps because I don’t like walls.) This way or the other, most of the companies I worked for dealt with perimeter. Truth be told, nobody really likes perimeters, or DMZs, for that matter. Perimeters and DMZs are necessary evils (because the evil they protect against is, well, more evil…).

When the Jericho Forum was established back in 2004 and proclaimed the disappearance of the perimeter, I became an enthusiastic follower. Then the cloud emerged, and the perimeter became fuzzier and more porous.

Then came the cloud security companies: CASBs, cloud gateways, cloud SSOs, the list goes on and on. Hugely underwhelming. They mostly replicated in the cloud the old on-premise technologies and methods. Of course, all wrapped in fancy terms: “Identity defined perimeter”, “software defined perimeter”, and “software defined security”. Everything became defined by something else…

Yawn. And slight panic.

If these technologies didn’t quite work in the old world, how will they ever resolve the same (and graver) problems in the cloud? It kind of reminds me of Albert Einstein’s definition of insanity: “Doing the same thing over and over again and expecting different results”.

The last couple of years, with the massive adoption of the cloud and fast migration to the cloud, I felt IT is running out of options. I wrote a few posts about it (The Ethereal Perimeter; Divide & Distribute: Counter the Flux of Security Breaches, The Ethereal Identity and the Identity Chain of Trust). I pitched for a paradigm shift. There has to be a new approach that will redefine the way users and applications are secured in the cloud.

Enter Soha.

Soha realized the enterprise isn’t just migrating to the cloud, but the very nature of what the enterprise is has changed. The enterprise has literally flipped: From a state where both users and applications are behind the firewall, in trusted and confined environment, to a state where most users are in effect outside the firewall, in an untrusted environment.

That called for something no one else has done yet: Rethinking the entire role of perimeter, breaking the problem into its core elements, and creating for each a solution that redefines it:

  • DMZ is an expensive and overly complicated pain? Then, build it as a native cloud service that deploys is minutes instead of months.
  • Remote user access pokes holes in the enterprise network (e.g. VPN…)? Then, invent remote access to applications that does not require any network access, is more secure and easier to use.
  • Staging an application in the cloud is cumbersome and “unclean”? Then, make a solution that is literally touch and go.

And so much more.

Soha literally redefines how enterprise networks in the cloud era. No other company has taken that challenge. To undertake this kind of heavy lifting, a special type of person is required. An uncommon combination of skills, experience and passion. This is the team I met at Soha.

So — a huge problem to solve, ingenious solution, incredible market opportunity, great team… Wouldn’t you want to join such a company?

The Ethereal Identity and the Identity Chain of Trust

Posted on by

Remember Mark Twain’s “everybody talks about the weather, but nobody does anything about it”? This is exactly my take on identity: Everybody talks about identity, but nobody does anything about it.

The crux: Our identity is everywhere, largely unprotected and out of control. A new identity security framework is badly needed — one which will keep the vital parts of our identity hidden and secure, yet usable to validate and authenticate us whenever required.

The Ethereal Identity: It is everywhere..

The problem begins with the definition of identity. What is identity? What is digital identity? Are they one and the same? Where does our identity begin and where does it end? The intuitive notion of identity is a combination of user-name and password, coupled with a number of other trivial pieces of personal data and user-behavior. Is it really?..

If you ask 10 people what digital identity is, you’re bound to hear 10 different definitions. Interesting perspective can be found in these definitions: Digital Identity in Cyberspace (1998); Digital Identity (2011); Wikipedia: Digital identity.

One of the major challenges of identity security solutions is the difficultly of defining what it really is.

Enterprise identity

In the enterprise space, identity is being dealt with extensively as part of IAM/SSO, but only within the confines of “enterprise identity” — trivial user credentials and set of access rights to enterprise resources. This is a minute fraction of what identity really is.

Personal identity

The personal identity space, on the other hand, was never given serious attention, although the largest data breaches and identity-related data thefts have always occurred there (well, save for the recent OPM breach). The only identity-related services to be found today are associated with identity fraud-prevention, almost exclusively centered around financial services.

Reality check: Our digital identity resides in myriad places throughout the Internet. Breadcrumbs of our identity and our activity are all over the Internet — literally everywhere and in countless shapes and forms: User names, passwords, email addresses, formal identifiers (e.g. social security numbers), traces of financial activity and shopping activity, mails, tweets, talkbacks, messages, personal interests, hobbies, habits and behavior patterns, places we’ve been to, navigation routes we’ve taken, social data and social interaction, photos, videos, jokes, nicknames, memes, real time video streaming (a la Periscope/Meerkat)… And the list only grows as more forms of social media are introduced.

Our identity is Ethereal — like the Internet itself.

Who owns your identity?

Short answer: Not you.

Long answer:
Your “root identity” — your national identity given to you at birth, whether analog/paper or digital — belongs to the issuer, that is — the state.

The Internet is roughly divided into 2 distinct categories of players where one’s identity is stored and used:

  1. Unregulated, commercial, social
  2. Mostly-regulated, financial, health, government

In both categories, one actually gives away the control and ownership of one’s identity. In both cases the players can, at their own discretion, revoke one’s account (effectively — one’s identity).

The main difference is that the regulated players are siloed. They have severe restrictions as to the usage of the personal data of the users, and due to business and competitive reasons do not share it even when sharing is permitted.

Privacy and identity security

Let’s admit it: Privacy is gone. Not so much because of the policies of the vendors who store and use our personal data. Mainly because we so willingly give it away without a second thought, let alone leaving visible and very personal traces of our activity everywhere (tweets, talksbacks, social shares etc.).

“Identity theft”, the intersection of privacy and security — consider these 2 cases:

  1. When a Company Is Put Up for Sale, in Many Cases, Your Personal Data Is, Too (New York Times, June 28 2015)
  2. Large-scale data breaches and identity-related thefts: Adobe,Target and Anthem.

So which case is more “identity theft” than the other?

In both cases important and sensitive personal data of yours gets into the possession of entities and people you don’t know, without your explicit consent. It will be used against your will or consent, let alone your control. And to top it off, it will probably be used in a malicious or harassing way — from “innocent” and “legitimate” commercial spam to money theft.

Not only is our identity everywhere, but it’s also unprotected for the most part. No need to “steal” identity, one literally only has to pick it up.

Short recap:

  1. Identity is extremely hard to define
  2. Identity is everywhere
  3. Identity is out of control
  4. Identity is unprotected and unsecured

Now, there’s a recipe for disaster…

We have to embrace the reality of no privacy. What remains is security. We cannot compromise on our identity’s security. The less privacy there is, all the more identity security must be put in place (two of my recent posts: The Ethereal Perimeter and Identity, cyber kill chain and all that relate to this issue as well).

Harnessing the Ethereal Identity: Towards Identity Chain of Trust

One of the most successful security models is that of the certificate chain of trust. Adapting this model to identity makes perfect sense: It’s a holistic and deterministic system; it allows authentication and validation using credentials which are always hidden from sight and never exposed; and it offers an operational model which is secure, flexible and extensible.

It all begins with the ability to rely on a trusted identity — a Root Identity which is authentic, official, secure and verifiable. An identity against which all authentication and validation actions can be made, the master authenticator & validator of one’s identity.

That type of identity already exists — the good old national identity.

Once we have that trusted source, we can begin and add the rest of the building blocks.

The main elements comprising the identity chain of trust:

  1. Root identity: One source of verifiable identity
  2. Certified and trusted identity brokers (aka CSP — credential service providers)
  3. Participating vendors (aka RP — Relying Parties)
  4. End users

Granted, governments cannot become an active player in the identity game. So in order to facilitate usage of root identity in this game, new entities must be established: Identity Brokers (aka CSP — Credential Service Provider).

While root identity is the anchor of this model, identity brokers are its heart. These will be security vendors, trusted and certified by the government to use the root identities for identity security purposes. They will be connected and integrated with all participating players (RPs). They will be the identity security hub for the end users.

Every participating vendor requiring secure identity services (e.g. authentication, SSO, identity validation, transaction authorization etc.) could become a Relying Party (RP). There are no limitations as to who can become RP: Every player/vendor providing services to end-users, which require secure authentication and/or identity validation.

Examples: Ecommerce, mobile commerce, SaaS and cloud, mobile apps, ebanking, ehealth, eGov. As a matter of fact — even enterprises.

As for end-users, all they will have to do is sign up to the service and authorize the level of activity/validation they’re interested in.

Modus operandi of identity chain of trust

Identity brokers:

The purpose of the identity broker is NOT to become a single-sign-on (SSO) provider, although this capability is inherent. Its purpose is to (1) validate the users to requesting RPs, and (2) authenticate users to these RPs.

What sets the identity broker apart from the roster of authentication providers is its ability to validate users. Validation, especially if done in real-time, is the game-changer of the identity space.

Users validation lends itself to host of services the identity brokers will be able to provide, above and beyond authentication. It will allow to approve transactions, sign transaction (regardless of the signature protocol/format), carry out legally-binding actions and much more.

Mutual anonymous trust:

The identity broker must be secure & trusted, that is — comply with all required regulations and standards. It must NEVER use the stored & used personal data for any other purpose save for identity security. Moreover — none of the stored and used data will ever be shared with any external entity/user. The entire use of stored data will be done within the confines of the identity broker and never exposed to anyone anytime.

The more data the participating RPs will share with the identity broker, the more context will be added to the actions done by the identity broker. More context means more accurate and faster actions.

Since the data will be used by the identity broker to assure and validate actions carried out for other RPs, there will have to be an agreed upon formal policy of “Mutual Anonymous Trust”. Example will provide the best explanation of this trust model: One’s purchase history at one etailer will be used to validate purchase at at another vendor, without any of the vendors’ data ever shared with the each other. Or: One’s history at one bank will serve to validate upgrade account at a different financial provider.

The more vendors will participate in the mutual anonymous trust, the more fine-tuned the user validation and authentication will be. There should be a number of authentication and validation levels, as not every user validation requires using the national/root identity.

As a rule, identity broker will securely store only the minimal amount of user information and data required to carry on its tasks. Most of the other required personal data doesn’t even need to be stored at the identity broker, but can remain at the RPs.

Think of this radical scenario: User doesn’t have to submit credit card and other sensitive details at the etailer/ecommerce/mobile app. Once a transaction using a credit card is required, the request goes securely through the identity broker, to the bank, and back again, without ever exposing ANY detail of the user or method of payment. None of this sensitive information will be transmitted using the channel the user uses vs. the app. This level of security can only be achieved by adopting the mutual anonymous trust model.

A significant side-benefit of mass-adoption of this model (specifically — the reduction of exposed users details and credentials) will be an overall reduction of phishing, spam and all other malicious activity based on easy harvesting of exposed personal data.

Concluding note:

We’re beginning to see green shoots: Kantrara, UMA, FICAM, Identity Ecosystem Steering Group (IDESG) and more. Every now and then we hear clear voices urging to go that way (for instance: Amazon’s Patrick Gauthier: It is time to re-invent Digital Identity, or Salesforce’s Ian Glazer: Identity’s TCP/IP Moment). But we’re still far from decisive adoption of this (or similar) models.

The sooner we’ll get there the better. Literally — our very identity is at stake.

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…

Identity, cyber kill chain and all that…

Posted on by

This is a call to action.

By now it’s common knowledge that identity is the weakest link in any network. But identity is also the weakest link in almost any security framework — because it’s missing from most, and under-represented in the rest.

Unless rigorous and comprehensive identity protection is natively incorporated and tightly integrated into the mainstream security layers and applications, data breaches and mega-hacks will continue to occur en-mass, regardless of how much has been invested in security.

Malware History in Perspective

“In the beginning there was the Computer Virus. IT was formless and empty, darkness was over the surface of the deep. Then came the Malware (network-aware). Then came the APT (identity-aware)…”

The early-days virus had been kind of a naive bubble-boy — it attacked singularly only the machines it directly infected, and caused mild local damage (deleting info or on rare occasions portions of the hard-disk etc.).

The 2nd generation, which came to be generically known as malware, was qualitatively different — it was a “network-aware” malware. Not only did it carry its attacks through the network, it also used network-based attacks as part of its malicious activity. This is still the most common form of malware.

The 3rd generation, commonly known as APT and/or targeted attack, is again qualitatively different than the 2nd generation malware — it is “identity-aware” malware, on top of all of its other sophisticated, sorry — “advanced” — properties. It doesn’t really matter whether the malware itself is identity-aware or the campaign it’s part of. The effect is the same.

Targeted Attacks Not Only Exploit Identity — They Depend on Identity

Today’s main target of attacks are users, not only in the sense of end-points or network-nodes — the identity itself is being attacked. This is starkly different than previous generation malware, where every user who happened to come across the malware got infected.

All of the recent mega data breaches used targeted individuals and specific identities in order to penetrate the target networks and carry on the attacks. These attacks begin with either an identified user (this is the “targeted” part), or a virtual place where “users of interest” go to — typically a website — in order to trap a relevant user (this is the less-targeted approach, aka “watering hole”).

Thereafter the user is:

  • Infected with the malicious payload which takes over his/hers machine.
  • Has his/hers identity stolen, by means of stealing the relevant security & access credentials and impersonating that user to access the coveted resources as well as help cover-up traces of attack.

This is the identity perspective of the cyber kill chain. Targeted attack is a head-on attack on identity.

As long as the user’s identity keeps being compromised, the attack continues (unless detected, always AFTER the fact, through other attack properties — this is where malware detection, network security and threat intelligence kick in).

Identity is a centerpiece in modern advanced malware. Every targeted attack attacks identity, and is DEPENDED on a compromised user and exploited identity in order to be carried out.

The Missing Link

Yet identity protection, in its deepest and broadest sense, is alarmingly missing from mainstream security means and applications. Security vendors do not seem to rush to deal with it. Endpoint security is not identity-aware at all. Heavier-weight security layers (gateways, servers, threat intelligence, “correlation engines” etc.) at best merely inherit the trivial policies from the organization’s directory.

Similarly, identity is hardly mentioned in the voluminous mountains of security literature/blogosphere/media. Yes, lip-service is paid every now and then, but there hasn’t been any serious discussion, analysis or call to action to add identity, in its deepest sense, to the mainstream security applications/technologies.

If identity protection enjoyed the attention given to APTs and targeted attacks, the public awareness and efforts to mitigate the “identity crisis” would be at a completely different level.

A case in point: Looking at the dissected-to-death “cyber kill-chain”, the one amazing and glaring missing link is identity. The parts of identity that are exploited and attacked are referred to in an off-hand technical manner: “Target-environment”, “victim’s system” and “vector of attack” (e.g. the user’s machine), “harvested mail address” (e.g. part of the user’s credentials) etc. As a matter of fact, Lockheed-Martin’s original paper laying down the principles of the cyber kill-chain, doesn’t even mention the word “identity”…

So in a manner of speaking, the weakest link is the one that’s not even there: Identity.

How many more mega-attacks should occur before identity will be added to the DNA of network security, malware detection/protection and security mindset? An industry-wide effort to fix this glaring flaw must be undertaken, with a great sense of urgency.

—

P.S.:

  1. At the same token, it’s time Identity protection adopts a much broader approach than its by-now-incredibly-obsolete narrow and binary approach to IAM.
  2. As to what exactly is “identity” — we’ll deal with that another time…

 

Divide & Distribute: Counter the Flux of Security Breaches

Posted on by

Behold, the fool saith, “Put not all thine eggs in the one basket” – which is but a matter of saying, “Scatter your money and your attention”; but the wise man saith, “Pull all your eggs in the one basket and – WATCH THAT BASKET. – Mark Twain

Mark Twain’s logic has been the staple food of data protection for many years. However, in the wake of the recent mega data breaches like the JP Morgan Chase,Sony Studios and Anthem, it’s apparent that the old common sense doesn’t work anymore.

Putting all the eggs in one basket: The pitfall of nowadays IT systems

Security is associated with control. The common sense of control is ‘Centralize & Secure’; Limit the number of sensitive/confidential/high-value data repositories, and watch them well.

But what does it mean ’watch them well‘? Mostly encrypt some of them, limit the access to them via policy, isolate them (as far as possible) from the network, etc. Looking at a typical IT system, we will find the following:

  • Data is stored in central repositories. If distributed, it’s spread across very few locations.
  • Security credentials (passwords, encryption keys, certificates, etc.) are stored in a single repository, either secure one (e.g. HSM) or most often insecure.
  • Privileged users (administrators): A very small number of users have unrestricted access to the limited-access resources.

Results? Well, not so good, given the increasing number of massive security breaches and data thefts we’re witnessing almost on a daily basis.Continue reading→