O, Perimeter Where Art Thou?

The Jericho Forum continues to make progress in moving the security conversation towards a deperimeterized view, where hard boundaries give way to a more integrated model. The idea seems reasonable enough, but how to practically get there is another story. Dan Blum reports that too much deperimeterization may be an irresponsible approach

Last week at the Infosecurity Europe conference I participated in, and lost, a debate on deperimeterization. I fear that I'm not alone; other security people may also be losing this debate but in situations where the stakes are for real. ... "If you go too far with the deperimeterized architecture it leads to irresponsible security and your organization will rue the day," I said ... There are three classes of mechanisms that can protect information: filters, transforms and enclaves.

Filters keep known good content within some boundary and prevent undesired information from entering or leaving enterprise environments. But they are subject to time based attacks, steganography, and obfustication. This is why we still get spam.

Transforms include encryption or signing to protect confidentiality or integrity of content between distributed users. But users are unreliable (try a web search on "why Johnny can't encrypt"). Also, in widely distributed heterogeneous environments there are many vulnerabilities in implementation and seams between implementations that attackers can exploit. Rights management attempts to protect the content even from its recipient and as such suffers some of the crypto issues and may be actively attacked by its own users. Encryption also introduces recovery and availability issues and can be a management nightmare.

Enclaves are groupings of users and computers that can communicate securely together and keep the rest of the world out. They can be achieved through various mechanisms including network separation and isolation. The hardened, dedicated firewall is in general a higher surety solution than enclaves created with cryptographic or identity based access controls. And the hardened, dedicated firewall offers higher surety than what most filter or transform mechanisms have.

My security research service at Burton Group recommends that enterprises leave the hard shell soft chewy center architecture behind and create internal perimeters to establish zones of trust. Enterprises should have restricted zones that are inaccessible from the internet for things like trading, manufacturing control, and credit card databases. They should have outer zones for extranets or visitors, and business zones on facilities that could be extended through VPN.

Our opponents then countered that they had zones all over the place and kept having to change them. That none of the restricted zones could be isolated. Yes, I reply, but that's what secure proxies are for.

At the end the proponents closed by repeating "the world has moved on" and we can envision these new security technologies that will be great for business. As I mentioned earlier, they won the vote.

It might have helped if I had said what I thougt of later: "The world has not moved on. Human nature hasn't changed. The nature of markets haven't changed. Haven't we learned - there is no new economy. In the five year vision time frame we still won't control all the users and systems in the deperimeterized environment, software vendors may still continue to favor convenience over security, and business constituents may often opt for the cheap but less secure solution. Many users will certainly continue to be lazy or naïve. Criminals and attackers certainly aren't going away. In this environment, how could responsible security architecture not preserve the option to make considerable use of firewalls as a strong separation defense?"

That we lost this debate is, I think, a triumph of wishful thinking on the part of that audience and perhaps others.

There are some good points on both sides of this debate, and the filter, transform and enclave patterns are a very mature way to approach deployment. Dan's blog eloquently portrays the dangers inherent in a reckless approach to deperimeterization. The problem with approaches that rely heavily on perimeters is that as Brian Snow said:

We will be in a truly dangerous stance: we will think we are secure (and act accordingly) when in fact we are not secure.

In other words, we are ok, we have a firewall. No need to worry too much about our "internal" authentication and authorization models, right? Oh except for the 65 exceptions in our firewall ruleset.

And that is the real problem with the perimeter model - it has potential ugly failure modes because once you are beyond that perimeter protection, you are in John Robb's systempunkt-land:

In Blitzkrieg warfare, the point of greatest emphasis is called a schwerpunkt. It is the point, often identified by lower level commanders, where the enemy line may be pierced by an explosive combination of multiple weapon systems. Once the line is pierced, armored forces dive deep into enemy territory to disrupt command, control, and logistics systems. Once these systems are disrupted, the top-heavy military units they support collapse in confusion.

Also, the perimeter model may not be flexible enough to efficiently support new lines of business, new interfaces, mobile clients, business relationships that are spun up and torn down quickly (like call centers).

Butler Lampson's Computer Security in the Real World presentation (wherein he also said that least privilege did more damage to security in the field than almost anything else, but that is another story) outlined the following defensive strategies:

Keep everybody out - Isolation

Keep the bad guy out - Code signing, firewalls

Let him in, but keep him from doing damage –Sandboxing, access control

Catch him and prosecute him –Auditing, police

Both the Keep the bad guy out and Let him in... strategies relying on some set of whitelist or black list to work off of. These turn out to be difficult to identify and enforce. The firewall at the perimeter does little to stop SQL or LDAP injection, for example, so then the lack of a sandbox or access control model hurts. An enterprise network is an asset and it is worth defending its boundaries, but it is not safe to assume those boundaries are resilient to all attack types. Firewalls may not be ready to be thrown away just yet, but their biggest value may not be a sense of a boundary, but rather an minimal attack surface, diverse OS and limited set of services on their host.

Comments

[ekivemark]

This seems like Deja Vu all over again...

I was on a project for a major federal initiative a few years ago and had daily debates with fellow consultants.

We were defining a multi-tier storage and presentation architecture with need for tight security. The two sides of the debate were: 1) Apply perimeter-based security. 2) Build security in to each layer of the architecture.

My argument was that since the scale of the resulting system was going to be so large and expansive a dependence upon perimiter-based security would be prone to failure.

I advocated the latter approach and recommended defining a directory-based architecture that would enable people, applications, processes and devices to be provided with identities. This would provide good granularity in defining security rules and would allow security access rules to be defined without necessarily requiring visibility in to all layers.

For example, users could be given access to applications or services, applications could independently be given access to pools of data.

My mind is flooded with the many different aspects of the identity debate. In the Deperimeterization debate I believe in a model that does not depend upon perimeter-based access control.

In a professional context our identity is comprised of many roles. We are granted access to information and services based upon the confluence of these roles. The Identity metasystem has to recognize the identity aggregation and separation that is at work here. Much of this is familiar territory for enterprise access control systems. The complexity has emerged as business has evolved and our roles and the services we consume spread far beyond the organization we may be employed by.