Tag Archives: Data Breach

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.

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→