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.