Defending Against Zero-Day Attacks, Whether 11 or 111

On March 27, a sandboxing technology provider published a white paper regarding 11 zero-day vulnerabilities they discovered in 2013.  While advanced attacks are top-of-mind for IT security people, the report left me wondering what the reader should take away from this.

Are 11 vulnerabilities a lot or a little? Does it even matter in today’s threat environment?

Consider this: the discovery of a zero-day file doesn’t mean an endpoint was infected. Discovery of the file means that malware was observed in motion. Whether the number is 11 or 111, what matters most is whether or not the endpoint was infected.

My view is–it’s more productive to focus on what is a security problem instead of what could be a security problem. There simply isn’t enough time and brainpower for security teams to worry about events that aren’t actual threats.

Here’s an analogy. Think about a zero-day attack in terms of credit card fraud. What if your credit card company called you 11 different times to say there might be suspicious behavior on your card? What could you do with that information? Cut up the card and ask for a new one. Change all of the accounts that auto-bill to your create card. Tell your spouse to stop using it. A lot of energy is expended without confirmation that anything nefarious occurred.

On the flip side, wouldn’t it extremely valuable to get one phone call saying, “We know your card is being used fraudulently and we’re shutting it down.”

If no real threat exists, there is no need to know. If an actual threat is detected, the need to know is immediate.

Apply that train of thought to zero-day files. The discovery of a file itself doesn’t indicate that an endpoint is infected. At Damballa, we don’t rely on file discovery to make a determination that an actual threat has infected an endpoint. Our goal is to determine if the infection happened at all and stop it before damage is done. We detect:

– Malware that downloads after the exploit occurs
– Malware that downloads without an exploit
– Network activity from malware downloaded outside the corporate environment

Last year, Damballa released a case study detailing how we stopped an unknown vulnerability we called “LazyAlienBikers” from becoming a breach. The malware targeted FORTUNE 500 companies. It had downloaded in many networks but was not tied to a known exploit, vulnerability or file.

Damballa discovered the malware that uses successful evasion techniques to exfiltrate data, including:

– Using SSH over HTTP ports to bypass firewall blocking of non-HTTP traffic
– Tunneling through Web Security Gateways on port 443
– Using a custom compile of the PuTTY client for encryption
– Exfiltrating megabytes a day from select endpoints while other infections remained dormant

We collected overwhelming case evidence for incident responders who were able to take immediate corrective action.

As Brian Krebs noted in an article in December 2013, on any given day, the bad guys have access to an arsenal or zero-day vulnerabilities. So far in 2014, 14 known vulnerabilities have been discovered. The number doesn’t matter as much as the defense you have in place to combat advanced attacks.

I’ll close with some great advice by Stefan Frei, PhD, at NSS Labs:

– Assume you are compromised, and that you will get compromised again.

– Prevention is limited; invest in breach detection so that you can quickly find and act on any compromises.

– Make sure you have a process for properly responding to compromises when they do happen.