Sunday, January 24, 2010

Ablative Security

The threats facing enterprise networks are incredibly diverse. Attack vectors are constantly changing and a never-ending sea of zero-day vulnerabilities plague those responsible for assuring corporate defenses.

While I'm familiar with just about every host and network security technology on the market today, I've been wondering if there are alternative ways of handling the quadratic equation of threats versus protection.

A concept I'm toying around with relates to Ablative Armor - essentially the concept of a protective armor that is (partially) destroyed in the process of defence - and whether it has legs from a network security perspective.

Ablative materials were used to protect returning space re-entry vehicles for a time, and are currently used as advanced "reactive armor" on heavy tanks and other front-line vehicles. The material and reaction type doesn't matter here for this discussion - merely the fact that these kinds of technologies provide some of he most advanced protection around. However, while they're carrying out their protection, they are similarly consumed by the defense - but (most importantly) leave the key equipment untouched.

Does ablative protection exist in IT security today? In some ways, perhaps it does. While at ISS, we came up with a technology called Buffer Overflow Exploit Protection (BOEP) which was designed to monitor system memory and, if it saw anything that looked like exploitation of a stack overflow, caused the host to immediately shutdown or reboot. BOEP works great as a preemptive protection technology - and in a way you could argue that by causing the system to reboot in this way is inelegant, but it may partially fit the bill of "ablative".

Perhaps the use of active honeypots/honeynets could constitute ablative security? They're throwaway systems designed to lure attacks (and attackers) to them - for both study and diversion - and are generally consumed in the process (i.e. once they're infected/compromised, they can't really be trusted and used for other tasks). But, at the end of the day, perhaps honeypots/honeynets aren't really a defense after all - being merely telescopes for studying attacks rather than front-line defenses of critical assets? Probably.

What about sinkholes? By dynamically/automatically hijacking the command and control domain names used by botnet nmasters and diverting all traffic to a sinkhole - does that constitute an aspect of ablative security? Maybe - after all, once you sinkhole that domain, neither the attacker or target can reuse that domain (or IP address) for much afterwards - and the attackers are alerted to who the defenders are. But still, I'm not so sure.

So, what would ablative security (or armor) look like in a network security sense? I doubt that we'd want the firewall to suddenly start smoking like a Gemini heat shield and shut itself off (permanently) upon thwarting the latest zero-day exploit.

If ablative security revolves around the targeting system being consumed in the process of thwarting an attack, perhaps automatic nuke-and-pave host-level responses are in order. For example, a virtual watcher program monitors the health of the virtually hosted operating system a user is using. They browse a malicious drive-by-download Web site, the "host" gets infected, and starts doing bad things. The canaries within the compromised "host" inform the virtual watcher, which then notifies the user to the fact that they're compromised (perhaps even telling them to take a couple of minutes off to grab a coffee), then automatically proceeds with re-imaging the "host" from a known good/save version. In this model the "canaries" are consumed in the defense of the system.

I think that this approach may be one take on the concept of ablative security, and there must be others. You could argue that the use of canaries for detection borders on honeypot functionality or something else. That said, there's nothing to say that the canaries have to exist within the host environment - and could just as easily (or perhaps more easily) exist at the network level instead.

My gut feel is that the concept of ablative security has a degree of unseen usefulness in protecting against some of the threats out there today and coming at us in the future. I'm going to ponder on it for a while. If anyone has thoughts on the topic, I'd love to hear them.

2 comments:

  1. Gunter - just a point of correction here, as our former colleagues at ISS are still selling BOEP-enabled products. BOEP didn't reboot systems, at least not directly. Depending on the configuration of that particular product, BOEP would either block the system call that was determined to have come from data memory space, or it would kill the entire process - which is still somewhat inelegant.

    There is one exception, however. It is possible for BOEP to kill a particular Windows process, triggering an immediate reboot, but that process was not monitored "out of the box" and would have to be manually configured.

    This doesn't really diminish the point of your example, as killing a compromised process image still fits your description of 'ablative', but I did want to point that out.

    ReplyDelete
  2. Good article Gunter - I think this has a real ring in high end Unix env - such as HPUX and AIX - the watcher could monitor the LPAR and reset as necessary . You would need a process of caching and cleaning any current transactions But certainly sound

    Simon

    ReplyDelete