Log in

Site menu:



Site search

September 2019
« Dec    



Negative Day Threat Detection

Announcements of exploitable OS and application vulnerabilities are so commonplace that we’re perhaps even more inured to them than we are to a perpetually ‘Elevated’ Homeland Security threat level. While the severity of the first threat is far outweighed by that of the second, the former is far more likely to be attempted or exercised, so much so that incidents of its occurrence should be considered inevitabilities. Despite this, there continue to be examples of failures to patch systems against newly announced vulnerabilities even when updates are made available very near the zero hour. Even days later, failures to patch leave systems vulnerable, and allow attackers to devise even more methods of concomitant exploitation.

But as the article states: “Microsoft patched the vulnerability with an out-of-sequence patch on 23 October. Trojans exploiting the flaw were spotted the day afterwards. Analysis of these strains suggested they may have been in circulation before Microsoft issued its patch.” What protection is there against exploits that are launched against a vulnerability before the vulnerability is remedied by the vendor? Fortunately, there are some extremely agile, automated defensive services, such as SonicWALL’s dynamically updated Unified Threat Management technology. For MS08-067,  SonicWALL published a Gateway AV update concurrent with the Microsoft announcement, meaning that subscribers to the SonicWALL service were protected against this exploit even before applying the Microsoft patch. Other security vendors provided similar updates with varying degrees of timeliness and automation, including the open-source community.

It’s that one point from the quote above, “[that strains of the malware] may have been in circulation before Microsoft issued its patch” that is cause for concern. While zero day protection is effective against considerate attackers who wait until after the zero day patch or pattern-update has been released, what about exploitations or events that occur prior to that? At that point it becomes an issue of incident response, step 1 of which is generally “contain the damage” — but other than hoping there are detectable traces of infection, how is it possible to identify something that occurred in that past?

In homage to this prescient NSFW Onion piece, it’s time for someone in the information security space to say “Zero Day Threat Detection? A whole lot of good that does when something happened yesterday”¦ Good luck detecting bits and bytes after they’ve faded into the ether. Well, we’ve just turned the Ethernet into the Perma-net: Let’s see someone try to evade Negative Day Threat Detection.”

In seriousness, efficient prevention is still usually far more useful than detection, but since failure is inevitable why shouldn’t we employ tools to aid in incident response? With the elements of storage getting bigger and cheaper all the time, why not put the ever increasing capacity and decreasing cost to just that use? Then, when it’s discovered that something of-interest  (any “unknown unknown” such as data-leakage, a database breach, a network outage, or a malware event) has occurred in the past, it becomes possible to retrospectively detect it and determine its severity and scope.

For the MS08-067 example, it would be possible to determine if any systems were affected prior to October 23rd by using the Emerging Threats pattern to search for instances of the offensive executable that might have traversed the network over the past two weeks by issuing a simple DeepSee query like “within:2w filetype:exe hex:C84F324B7016D30112785A47BF6EE188″

Yes... it\'s real.

Negative Day Event Detection — Take information security up to 11

Share: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Twitter
  • Reddit
  • Slashdot
  • LinkedIn
  • Facebook
  • email
  • Print

You must be logged in to post a comment.