My theory on this is two fold

1) layer

Use a thirdparty proxy to filter application layer protocols. The software then doesn't need to be patched, only the rules need to be updated.

2) diversify

Don't use a Microsoft technology to proxy for a Microsoft technology. Why? There is a good chance that the same exploits will exist in both products if they share an implementation, which sends you back into the patch cycle.

Do you mind explaining more about your product. Is it a proxy?

Hey Christopher,

My product is actually a kernel component within the Windows kernel, working directly at ring0 with the Security IO and filter manager. It intercepts all applicable IO requests and makes determination against a known baseline on what is considered a normal operation, and what is not, configured by you and optimized by a learning process on the system. Anything that attempts to breach an access control policy can therefore be stopped before it actually occurs.

Think of it like this. We KNOW that the IIS web server should NOT be WRITING to web pages. It needs to read and execute the pages, but never write. Until IIS 6, almost every major release had at least 1 vulnerability that allowed for Web defacement. We can apply an access control policy to remove this risk and ensure that this behaviour in the IIS process is simply BLOCKED if it tries a write operation. In this way, we couldn't care less if another similar vulnerabily is exploited... the activity breaches access control policies and is WRONG, and will therefore be stopped. We can go one step further and even terminate the process, which helps to eliminate the propogation of malicious code from causing further harm to other systems.

Your ideas of proxying at layer 7 is interesting, but difficult to maintain. As application logic quickly changes as business processes evolve, it becomes increasingly difficult to manage what occurs. On top of that, network proxying is useless against crypto streams. This means the proxy has to move directly to the application layer on the host, which then shouldn't be at layer 7, but actually down in ring0 where you can defend the core against malicious or hostile code.

You are right that a layered approach is the best method. Which is why I said patch management and antivirus ALONE can't reduce the risk enough. Doesn't mean we shouldn't use them. Or application proxies. Or stateful packet filters. Or IDS. It's all about defense in depth. Yet in the end, the last line of defense will be on the host... where it has never been more paramount to ensure that it gets done right.

I agree you need to set your sites on the unknown - so why even factor in the disclosure to patch lifecycle which only starts the clock after the unknown becomes known? Set your goals higher and the value will go with it. Your HIPS solution should provide protection for the vulnerability from the point of software implementation, regardless of whether anyone reputable knows about it or a patch exists. Then we can eliminate this ridiculous focus on days and times that supposedly start the clock ticking and provide real protection...

Hey Pete,

Good point. Perhaps I wasn't making myself clear in my explaination. My point was that HIPS gives you the latitude to not fret about the Exposure Window. The real protection comes from applying the three pillars of information security to the way you configure your systems. You can maintain confidentiality, integrity and availability by applying least privilege confinement with a mandatory access control system in the Host IPS.

The IPS can then drastically reduce, and in many cases completely remove many security related risks that are exposed to vulnerable servers and workstations. You can then configure applications in a "least privilege" confinement and contain the potential damage of malicious or exploited software that is exhibiting unexpected behaviour or in danger of succumbing to security attacks.

The focus on the Exposure Window is quite real IF you don't have safeguards like IPS in place. But having IPS doesn't eliminate the threats. What it does is reduce the impact, mitigating the risks to acceptable levels until other technical safeguards can strengthen it, or remove the risk entirely (ie: a patch to fix the underlying problem).

As an example, a properly configured system using IPS may not have stopped MS Blaster completely, but it would have contained the breach and ensured that the rest of the system maintained its availability and integrity. With the breach identified and stopped... the administrator can then do a post-attack forensic audit and verify how the attack vector bypassed other safeguards, allowing the admin to adjust the security policy accordingly.

Hi SilverStr,

What difference does your proposed IPS have from the XP inbuilt firewall.

Joseph,

IPS and firewalls have different purposes. Think of it like this. If you allow port 80 (HTTP web) through the firewall for IE, and encapsulated in the HTTP traffic is an attack pattern to compromise a vulnerability through a malicious script or activex control, the firewall will let it through. If the attack does something outside of what IE is allowed to do (lets say write to the system binaires in the System32 folder) the Host-based IPS can block that hostile operation.

Now apply that to basically any untrusted code being executed on the machine. The firewall will block network operations you may not wish to occur. If the operation is allowed, the IPS is another layer to defend against hostile actions directly on the host. Firewalls deal with packet level issues. Host-based IPS works on the system calls and access control operations on the host itself.

Both are important. But they do different functions.