Tag Archives: Remote Access

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…

 

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?