How to protect your company with application and protocol use policies

Computerworld - It happens all too often that the first time a vulnerability becomes known is when a forensic investigation is under way to find out how a system was broken into, or when a virus that's already spreading is being analyzed.
Whether the vendors knew about the vulnerability a year ago or found out about it this morning, if the exploit code exists when the vulnerability is made public, it's a potential zero-day exploit that can threaten critical assets immediately.
Even after a patch has been created and advertised, there can be an extended period while the patch is tested and deployed on every system. During this time, systems are vulnerable to being exploited. Worse yet, most incidents of attack accelerate after an announcement or release of a patch.
A well-known example is the Slammer worm that targeted Microsoft SQL Servers. A hybrid worm that combined a distributed denial-of-service (DDoS) attack with the automated propagation techniques used by worms such as Code Red had targeted a known vulnerability in SQL Server systems. While signature-based systems are needed to provide overall protection, they aren't sufficient to stop unknown and zero-day exploits and application-level threats. To protect against emerging threats, organizations should consider using the following methods:
Enforce acceptable protocol and application usage
Many attacks target protocols such as HTTP, DNS and FTP. Certain programming errors, such as unchecked buffers, can be exploited by attackers to compromise or damage a system. These attacks exploit loose programming practices in applications and systems. Enforcing acceptable protocol behavior goes beyond checking requests for comments (RFC) and ensures that the data flowing through the network adheres to the policies of the applications running in your environment.
Most application attacks, by their very nature, contain malicious code that would cause the attack packet stream to violate acceptable protocol usage. Simply put, since it's clearly known whether a packet stream complies with acceptable application or protocol usage, any data stream that violates those protocols can be deemed malicious and thus be blocked.
Here's an example: The HTTP 1.0/1.1 protocol allows host names up to any length, so an RFC checker wouldn't bother checking this field. Application usage enforcement knows that since the Domain Name System doesn't allow for host names of more than 256 characters, the best way to stop attacks is through blocking any HTTP request that contains a host-name field with more than 256 characters. With checks like these, a properly configured protection system can block zero-day attacks that might exploit a still-unknown vulnerability in a Web