Many intruders are unpredictable.
Two posts by pdp perfectly demonstrate this:
- Bugs in the Browser: Firefox’s DATA URL Scheme Vulnerability
- Web Mayhem: Firefox’s JAR: Protocol issues
How many of you who are not security researchers even knew that data: or jar: protocols existed? (It's rhetorical, no need to answer in a comment.) Do you think your silver bullet security product knows about it? How about your users or developers?
No, this is another case where the first time you learn of a feature in a product is in a description of how to attack it. This is why the "ahead of the threat" slogan at the left is a pile of garbage. This is another example of Attacker 3.0 exploiting features devised by Developer 2.5 while Security 1.0 is still thinking about how great it is no big worms have hit since 2005. (The specific cases here are worse than Developer 2.5, since jar: and data: protocols are apparently old!)
How do I propose handling issues like this? As always, NSM is helpful. If you've been keeping track of what happens in your enterprise, you can perform some retrospective network analysis (RNA) to see if you've seen this latest attack vector. (RNA is a term which Network Instruments would like to have coined. I like it, even though the concept of recording traffic in this manner dates back to Todd Heberlein's original Network Security Monitor in 1988. The first mention I can quickly find is in this 1997 paper Netanalyzer: A retrospective network analysis tool.)
RNA and, from this point of enlightenment, ongoing network analysis via NSM and, ideally, other forms of instrumentation (logs, etc.) facilitates impact assessment. Who cares if the sky is falling somewhere else, as reported in whatever online news story -- is your sky falling? If yes, what's the damage? How best can we mitigate and recover? These are the sorts of questions one can answer when some data is available, enabling management by fact and avoiding management by belief.