Beating the Internet Explorer zero-day threat

Microsoft is quickly working to patch a new zero-day threat that has been discovered in recent versions of its Internet Explorer browser. Of course, Microsoft isn’t the only vendor dealing with this type of issue; a recent zero-day vulnerability exploit of Oracle’s Java engine was recently found in the wild. We know that this isn’t the first set of zero-day vulnerabilities for which actual exploitation code exists (think Stuxnet), nor will it be the last.

A good friend of mine who is an extremely adept developer recently lamented how poorly educated most of his fellow programmers are when it comes to secure coding practices. He insisted that – someday – we’ll reach a point where code threats are eliminated through some combination of developer education, automated tools to parse code for security vulnerabilities, and application sandboxing implemented at the operating system layer. Being the more pragmatic sort, I informed him that when that day arrives, our great-great grandchildren will celebrate it on our behalf.

The fact is unpatched vulnerabilities are a way of life in the technology world, and while pie-in-the-sky methods of eliminating (or at least reducing) them are noble efforts, information security professionals must find real-world methods to deal with them today. Traditionally, security organizations mitigate code-based threats with signature-based detection tools: anti-virus, intrusion detection and prevention (IDS/IPS), and integrated unified threat management (UTM) devices are all critical parts of detecting known threats. The key, of course, is the word “known.” Signature-based tools assume that the signature of an attack is known: hardly a given with zero-day code that exploits previously unknown vulnerabilities.

So what other methods exist to detect these threats? Ultimately, the practice of information security is based on detecting abnormalities. We know what is “normal” and “acceptable” – whether it’s at the policy level (“employees must change their password at least every 90 days”) or at the control level (“block all inbound TCP access except to ports 80 and 443”). When things are not compliant with these standards, we know we have a problem, and we need to evaluate it. The same concept can be applied to detecting zero-day exploits in the wild. By evaluating whether security objects – systems, applications, networks, and users – are behaving “normally” based on what is expected we can identify whether an abnormality is ephemeral or persistent, and provided enough data is collected determine whether its root cause is an accidental or unintentional event or potentially an exploitation of a vulnerability (whether known or not).

The key to being able to do this type of detection is to collect and analyze all of this information in a single console. SIEM vendors (and, in the spirit of full disclosure, I work for one such vendor) have emerged as the tool of choice for this type of “abnormality detection” since functions such as data aggregation, normalization, categorization and alerting are all part of the technology regardless of vendor, and policies can be written within these products to encapsulate a baseline definition of “what is normal” for a given environment. The problem that SIEM vendors need to address, however, is that most of their products look at everything as an event – and the reality is we need to look at more than just event-based information (such as logs). Detecting zero-day threats also requires analysis of state-based data (how something is, not what it does), network traffic (which, although it is “event-like,” has some properties that are not shared with traditional log-based events), system- and application-level performance metrics, and other data. Fortunately, most SIEM vendors are moving in this general direction, with varied degrees of success.

There are not enough hours in the day to complete a discussion of how to minimize a zero-day threat, but the reality is they do indeed exist and will continue to be a threat into the foreseeable future – and from a practical perspective, relying entirely on a vendor’s response to vulnerabilities does little to actually mitigate the risk posed by zero-day exploits in the wild. Instead, security practitioners must take an approach that focuses on detection of “what is abnormal” rather than “what is a known threat.” Deduction must be the main tool in the security professional’s arsenal. As Sherlock Holmes said, “When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.”