Back in Southern Illinois where I grew up, we had a screen door between our back door and the outside world. That screen door's job was to keep an eye on the air flowing through the screen, let in the cool air but keep out all the bugs. It's a mighty fine tool for airing out the house but keeping out all the nasty things that buzz around a farm in Illinois.

Fast forwarding to our patch problem, why exactly do we rush to patch our systems every month, often within 24 or 72 hours of the release of patch? Because the code sitting on our systems has some sort of problem and someone from outside our network could send it a special piece of code that would force the system to do something we don't want it to do.

For example, if its a buffer overflow attack (one of the more common types), then our system doesn't watch when that special piece of code overruns its allotted space in memory and runs itself from another memory location, often now with administrative privileges.

So, we patch every month to make sure we prevent that special piece of code from being run by our system.

Back to my earlier analogy, wouldn't it just be better if we just installed a screen door between our systems and our network? If that screen door could constantly be looking for special pieces of code, it could filter out that code before it ever hit our internal machines, right? What if that screen door was hooked up to a central database where it would get updated regularly on new pieces of code to watch for. Now, you've got something similar to an antivirus engine, but one that instead is looking for network traffic flows.

Hook that baby up between our internal network and our connection to the outside world and BAMMO, you're protected against all the Southern Illinois mosquitos. Patching needs get much less important, because the reason to patch is being stopped at the perimeter.

Now, take this analogy one step further. What if we install this screen door on our network, but somehow one of those dangnabbit mosquitos gets inside by hitching a ride on someone coming in from the outside? They've made it through our protective screen door and can start biting people on the inside at will. How do we fix that? Well, in some places where the mosquitos bring really bad diseases, people put more netting over their heads and over their beds.

Technology like that would protect us from an internal attack.

Most network security is like a warm M&M: Really hard on the outside, but pretty soft and gooey on the inside. What if we could apply another set of screen doors on the inside of our network for a secondary layer of protection. That screen could work with virtualized machines using VMware's ESX Server to monitor and screen out the traffic as it goes in and out of the machine's network interface.

In this example, we're completely protected. Baddies from the outside world can't get in through our perimeter screen door. If any of them happen to get into the squishy center via an infected laptop or other vector, our servers are secondarily protected right at their physical interface to the network.

With this, I know I can patch when I want to and not when I have to. I can bring up virtual machines that have been powered off for six months or twelve months and not have to worry that they might get hacked before I can patch them. I can thoroughly regression test patches against my applications before I rush to apply them. And most importantly, I don't have to cancel plans with my wife every month for a few late nights.

And that blew me away.

If you're interested in learning more, check out http://www.bluelane.com.