From Fort to Trade Network. IT Exposure Issues.

 

In most fantasy RPGs and in historical context, a fort is a well built defensive position that allows you to detect attacks and funnel them to places where they can be defeated. It's well constructed, has restricted points of entry, and has defense in depth. A trade network on the other hand is a lengthy line of trails and/or roads with little protection and lots of wide open spaces that allow enemies to attack at a point of their choosing.

IT is in a state of transformation that these two definitions fit rather well. It started with CDNs, continued with SaaS, and has been evolving ever since.

Prior to CDNs, IT datacenters were the fort. They had limited points of entry, firewalls protecting those points, and in a well designed datacenter, significant defense in depth. It didn't stop all attacks, but just as not all forts - from dirt berms to castles - are created equal and many fell while others withstood countless attacks, the same was true of datacenters. Most were not readily penetrated, and those that were usually stopped the assault quickly.

But with the growing footprint of the systems that used to be protected within the datacenter, our IT is increasingly looking more like a trade network than a lair. Long stretches of space separating variously defended groupings of applications.

In short, as we've grown where we deploy things, we have increased the attack vectors that ne'er-do-wells have against us. And for most IT shops, that is a problem that is only now being addressed.

What we need - really need - is a system that allows us to set all security policies for the datacenter, the cloud, and even in some cases for SaaS and CDN from a centralized location. We need to be able to say "our applications and the networks they run on are protected in a consistent manner no matter where they are deployed." That's a tall order. Since security is distributed across the application domain, network domain, and database/storage domain, it is a tough problem to resolve, but one we must.

To be able to set security policy at the datacenter and say "I don't care where it's deployed, this is the security system", whether we're talking about DDoS or XML injection, is growing imperative.

Of course F5 has products that will take you a long way down that path, but there are still a lot of variables to manage. If your cloud provider allows you to deploy VMs, most of the relevant F5 products are available in the cloud. For CDN and SaaS, my understanding is that you'll have to ask your vendor what is available, though both are slowly moving in a cloudy direction, so maybe that's only a short-term issue.

To be able to say "User X has access to application Y, no matter where user X is coming from, but only on devices that meet criteria "A, B, and C" is a highly granular security mechanism that helps in the application realm. To be able to say "Automatically detect DDoS attacks and reject them" is another in the networking realm. Soon you start to see a small configuration of issues that need to be extended out to the cloud, and if done so with a minimum of fuss (there is a whole lot assumed by both of these - ability to access user info from the cloud in the first one and ability to detect multiple forms of DDoS in the second for starters), can make your trade network into a series of fortifications connected by a unified strategy for dealing with intruders.

I much prefer to keep fortifications and the need to defend against ne'er-do-wells in my gaming, but since we don't have that luxury, a state of the art protection system that can be extended to all of our many points on the web is necessary. And sooner, not later.

 

Published Sep 13, 2011
Version 1.0
No CommentsBe the first to comment