the blacklist value proposition

how do you defend the use of blacklists in the face of seemingly stronger defensive mechanisms like whitelists?

no matter what defensive technology you use there will always be some holes in those defenses... there will always be exceptional cases that your defenses don't currently handle and/or are unsuitable for handling... what's the fastest/easiest way to deal with exceptional cases you want to avoid? yeah, you guessed it, with a blacklist...

let me give you an example: lets say that we have an application whitelist... application whitelists control the execution of some subset of known program types... they're limited to the known types because, well, how do you intercept a kind of execution that's never been seen before?... they're also usually limited to a subset of the known types because developing the technology to intercept and block programs of an arbitrary type (such as script programs for a particular interpreter, or the unanticipated programs that exploit code represents) is not necessarily easy or cheap and for the more obscure types it's often just not worth the investment...

now lets say that a piece of malware is created that exploits this partial coverage of the set of program types... when there's only one such piece of malware, or even just a handful, the benefits of re-engineering the application whitelisting software to be able to cope with this additional type don't justify the costs in terms of time, money, and effort required to do it... when there are so few instances (relative to the billions of programs out there) it is faster, easier, and cheaper to just look for those particular instances (via a blacklist) than to re-engineer the whitelist to handle them... it won't be until the program type in question becomes mainstream that it becomes worth it to add capabilities for it to an application whitelist...

similar scenarios can be constructed for any other type of preventative measure... as such there will always be a need for blacklisting regardless of what other defenses are in play because there will always be a need to deal with emergent exceptional cases as fast and cheaply as possible... even malware blacklists (ie. known malware scanners) themselves have exceptional cases that they can't deal with - that being new/unknown malware... however, as i've stated in the past, novelty is an advantage that wears off, and as far as i can tell it's the only one that does...

whitelist opinion smackdown

i realize i've been rather quiet as of late - not sure why, perhaps i lost my mojo... anyways, you can all thank cdman for rousing this ogre out of slumber...

in a recent post, cdman lays out his response to randy abrams' post on whitelisting... perhaps it was the hint at the possibility of an ad hominem attack against a fairly well known and long-standing member of the av community (randy was, for a long time, the voice of av from within the belly of the beast - aka microsoft) that piqued my interest, but that wasn't cool so let's move on...

cdman's first substantive beef is the suggestion that whitelisting companies can't do their job without anti-virus software... ignoring the fact that in practice this is actually true (whitelisting companies currently depend on anti-virus software to determine if something is safe to add to their whitelist) lets look at the hypothetical alternatives he suggests - specifically that whitelist vendors could rely on reputation or building the generic malware equivalent of marko helenius' automatic and controled virus code execution system...

relying on reputation offloads the problem of keeping bad software off the whitelist onto the very people providing the bad software... sure people who provide bad software consistently will get a bad reputation and not be trusted, but what about people who only do it once in a blue moon? microsoft releases tons of legitimate and safe software but they have on occasion also distributed virus infected materials... you'd be hard pressed to justify not whitelisting code from microsoft if you were relying on reputation but if you did whitelist all their code you would eventually whitelist something you shouldn't have... furthermore, relying on reputation is precisely the method that customer-generated whitelists are primarily made with, which would make a vendor-generated whitelist using the same technique rather pointless...

next is the idea of building a system to automatically execute samples and perform baseline comparisons to see if the sample compromised the system... and of course this has to be done on a scale sufficient to handle the rate at which sample files are produced (otherwise whitelist vendors wouldn't be able to keep up, much like av vendors supposedly aren't able to)... but have you looked at bit9's (a whitelist vendor) figures? av companies already augment their small armies of malware analysts with automated methods of determining what's bad, and old methods like this are almost certainly among them... if the av vendors can't keep up with the malware then what hope do whitelist vendors have in keeping up with the goodware when it's production rate is (necessarily) several orders of magnitude greater than that of malware? there are all kinds of capabilities peculiar to traditional av companies that whitelist vendors could try to replicate in-house, but the scale of the samples they have to deal with make it impractical for them to do anything other than to replicate the blacklisting capabilities in full in-house and that would mean they would still be using what the general population considers av - it would just be their own...

a third option cdman mentions is using technology like that developed by mandiant... whitelist vendors are unlikely develop such capabilities in-house when it's almost certainly cheaper to buy products/services from others who've already developed those same capabilities, but lets hope in this case they stay away from such ethically questionable companies as mandiant... bad enough that mandiant hires people whose marketability in security is thanks in no small part to their past efforts at making the problem worse, but to then turn around and have some of those same people do essentially the same thing in the company's name at an event like race-to-zero smacks of not just some lapse in HR's judgment but rather of an alignment of moral compasses... perhaps i'm in the minority here, but if a whitelist vendor gets in bed with a company like mandiant i wouldn't touch them with a 10 foot barge pole...

second to the beef about what whitelist vendors would do without av software was cdman's beef with randy's understanding of what actually constitutes a whitelist... i have to admit that my first impression on reading the statement that the TSA implements a whitelist was one of confusion... the most widely known (and reviled) measure the TSA implements is the no-fly list, which is fairly obviously a blacklist... i actually left a comment on randy's original post expressing my confusion but literally as i was writing it it dawned on me that there were other measures implemented by the TSA such as the newly revised rules for flights which basically require one to be granted permission in a 2-stage process before you can fly... of course, as i write this i'm reminded of the various trusted traveler programs that schneier has written about on occasion - those are also whitelists...

despite all the disagreement, though, in the end cdman and randy are actually in agreement about the role of whitelisting - it's simply another layer... both think it's got it's strengths and it's weaknesses, areas where it's more applicable than others, etc.. however, i think randy has once again distilled a complicated topic to a simple analogy when he compares the folks who say whitelists are the end of av with airbags calling seatbelts obsolete... what a clever way to say they're full of hot air...

what are anti-virus best practices?

i'll be blunt - some of this (maybe even all of it) is going to seem dead obvious... i'm sorry if this is old news you, however it would appear that quite a number of otherwise smart people (be they security professionals or [ahem] rocket scientists) have decided either that av marketing is gospel and thus been bitten by the ensuing false sense of security, or that av marketing should be trustworthy (even though the marketing for virtually every other product on the planet isn't) and became bitter and jaded because av failed to live up to the expectations that the marketing created...

just to be clear, this is going to be best practices for known-malware scanning (what most people consider to be the entirety of av)...

1. use it - i don't just mean have it installed, i mean sit down and actually scan things (like files you download or removable media you insert into your computer) from time to time (and scanning the entire drive on an automated schedule doesn't count)... install and forget security is bullshit... you need to interact with the software, to learn what it's alerts actually look like so you can distinguish them from fake alerts, and to become skilled in the actual use of the tool...
   
   some may say that's working for your security software instead of making it work for you and real people have real jobs to do, but it doesn't actually take much time or effort to scan incoming materials and both of those other concepts ('working for the software' and 'making it work for you') are nonsense... it's a tool, and like any tool you can only get out of it what you put into it... if you don't know how to use it properly then you ultimately won't do as good a job at protecting yourself with it as you might have otherwise... it's a poor craftsman who blames his tools...


2. keep it up to date - known-malware scanners are only as good as the knowledge-base they embody... new malware is being created at a rather incredible rate and the only way to make known-malware scanners effective against that new malware is to update those scanners with 'knowledge' of that new malware...
   
   sure there are other types of anti-malware software that don't require such updates, but they also don't come with expert knowledge about known-malware built into them and so are of little diagnostic value when prevention inevitably fails... also, it's always easiest to prevent something bad if you 'know' specifically what to look for...


3. quarantine first - don't trust the scanner to automatically delete things it thinks are bad... scanners make mistakes and you don't want to compound those mistakes by allowing the scanner to automagically delete critical files...
   
   trust the results enough to consider that the file(s) in question may be bad, but verify those results, and verify that it's safe to get rid of the file(s) before you actually do so... trust but verify...


4. don't rely on it alone - just as you shouldn't place absolute trust in it's results when it detects something you also shouldn't place absolute trust in it when it doesn't find anything... this is probably the best practice most directly in conflict with av marketing, and there are a number of people i really wish would stop listening to marketing and catch up because i learned of the benefits of using a multi-layered approach (what would be better known now as defense in depth) back in the early 90's thanks to the people who actually made (rather than marketed) this stuff...
   
   you need to use other types of anti-malware technology in conjunction with scanners (not just additional scanners) if for no other reason than because there will always be a window of time between when a new piece of malware is created and when an update for that malware is made available... in other words: if the malware's too new, a scanner won't do...


5. scan from a known-clean environment - just as you shouldn't necessarily trust the scanner you also shouldn't trust an infected or even possibly infected machine... this likely won't seem intuitive since the av industry itself has for years been producing features and services that contradict this such as web based scanners or the ubiquitous scheduled system scan... in an effort to be less of an uncompromising s.o.b. let me say that those are features and services that are offered for convenience and shouldn't be solely relied upon as they do not replace outside-the-box scanning...
   
   you can't trust a compromised environment to accurately report it's own integrity... the code the runs first wins and the only way to make sure malware doesn't run first is to operate in an environment where no code from the suspect system has run; not the operating system, not even the boot sectors...

now, hopefully, most or all those smart people who i know are familiar with the concept of best practices will modify their expectations and stop listening to those marketing departments that are filling their heads with lies... (stop. listening. to marketing!)

if i have a whitelist, do i still need AV?

on reading this dark reading article about a texas bank dumping AV in favour of application whitelisting technology i was reminded of an email conversation i had with a reader who was dealing with almost the exact same issue only days earlier... i've come to realize this is a question more and more people are going to be wrestling with as time goes on so instead of expecting them to contact me privately i'm going to answer the question of whether you need AV software if you have a whitelist here... the glib answer is no you don't need it...

of course that answer continues with: you don't need the whitelist either, or your computer for that matter - people survived perfectly fine before any of that stuff existed...

clearly, the glib answer isn't all that useful...

the real answer is that i can't decide for anyone whether they need AV... in practice security has a lot to do with making trade-offs and which trade-off is right for any particular person or organization is best decided by those who would have to live with the consequences of that decision... what i can do, however, is point out weaknesses in both individual technologies and describe some of the benefits of using them together...

it's no secret that known-malware scanners are ill-suited to detection of new/unknown malware, updates can be a hassle for large organizations, and the ongoing subscription fees have in the past seemed like a necessary evil but are increasingly seeming less necessary as application whitelisting works it's way into the mainstream...

of course, as we know from figures provided by bit9, the set of good software is larger and growing faster than the set of malware so a vendor-supplied whitelist will almost certainly be worse from an update point of view (and maybe subscription-wise too)... the customer-editable whitelist is much more palatable in that regard because you only put on it those things you actually need in your production environment... coming up with the initial whitelist (not to mention modifying it if/when the needs of that environment change or when software needs updating) puts the customer in the position of having to decide what's safe or not... certainly one should only trust software from known, reputable sources but those sources aren't perfect (even microsoft has accidentally distributed malware in the past) so the first benefit of continuing to use known-malware scanner even though you've chosen to use a whitelist is that you can check the software you intend to whitelist (as whitelist vendors often do for whitelists they provide)... this is an example of the axiom "trust but verify"...

that alone may not seem like it's enough to warrant keeping the desktop av, however, so consider this: just as known-malware scanners don't recognize everything that's malware, application whitelist software doesn't recognize everything that's a program... will the whitelist software block office macros if the office binaries are on the whitelist? will it block batch, perl, kixstart, etc. scripts if their respective interpreter is on the whitelist? will it block javascript from the myriad of ways it can be launched on the system? as an example, i use the application launch control functionality of sunbelt personal firewall as a whitelist and i discovered quite by accident recently that it does not block individual batch files... a known-malware scanner would detect known malware in a batch file, however, and in an office macro, etc... that's a second benefit of keeping known-malware scanners around in a whitelist deployment, and it's one that applies even at the desktop level...

that's not all though... there's also the issue of exploit code that exploits vulnerabilities in whitelisted applications... if the exploit needs to launch additional applications that aren't on the whitelist then the whitelisting software will have interfered with and potentially blocked the exploit, but what if all the applications it needs are on the whitelist? the whitelisting software would be helpless to stop it but a known-malware scanner might still have at least some chance to do so...

known-malware scanners are weak against that which is novel while application whitelists (assuming no malware gets whitelisted) are weak against that which is exotic... together they're only weak against that which is both novel and exotic... this is the essence of what defense in depth means when it comes to the anti-malware world - not using multiple different scanners but rather using multiple and entirely different types of technology so that the second (or third, or fourth, etc) line of defense can stop at least some of what gets through the cracks in the previous line(s) of defense... it's still up to the people affected to decide whether the benefits of a multi-layered strategy warrant the cost but they should definitely consider it as no technology is an island, perfect unto itself...

race to zero is no pwn2own

from mike rothman on the race to zero controversy:

It's like the PwnToOwn context at CanSec. Some folks will find some interesting holes and the vendors will patch them. Same deal here.

simply put, modifying known malware so that it no longer resembles known malware closely enough for anti-malware products to recognize it is not the same as finding new software flaws that need to be fixed...

with an infinite number of possible modifications, it's technically impossible for known-malware scanning producers to anticipate them all so they stay out of the pointless business of anticipating them entirely... as such failing to anticipate the ones used in this contest doesn't represent a flaw that needs to be fixed anymore than failing to read minds does... dealing with the new/unknown threats is the job of other technologies like behaviour-based HIPS (which i've already shown is available from a surprising number of traditional av vendors)...

coming from the guy who put me on to the phrase "mismatched expectations", this incite was a little off... but i guess i should expect as much when the prevailing wisdom in the security industry can't distinguish between malware research issues and vulnerability research issues...

all in all, the race to zero contest is really nothing like pwn2own... it's more like a cross between anti-virus fight-club and the consumer reports fiasco...

the price of anti-virus

i found an interesting opinion on the pricing of anti-virus products over at the agnitum blog a while ago - basically mikhail penkovsky is saying (among other things) that part of the development cost should have gone away a long time ago... well, i have a different opinion...

i've often said that signature updates tell a known-malware scanner what to look for while engine updates tell a scanner where and how to look...

the need for signature updates is patently obvious - malware authors keep writing more malware so more signatures are required to detect the new malware... you might think that after a while, however, you wouldn't need to update where and how the scanner looks for things, there should only be so many ways and places to hide the malware, right?

wrong - not only are there basically an infinite number of ways for malware to perform all the functions we already know about, as new legitimate software is developed new opportunities for exploitation open up along-side them (ex. create a new document format that contains macros and watch new macro-based malware get developed)... furthermore, there are a number of things that scanners still don't do well enough that require more research and development (like seeing through packers and other obfuscation techniques)...

these are just a couple of the reasons why the underlying scanning technology itself is constantly being redeveloped and reworked and why the cost of that development has never gone away...

what is known-malware scanning?

known-malware scanning is the process of scanning a computer resource (be it a file, an email, an entire disk, etc) for malware that matches a malware signature and is therefore known to the scanner (hence 'known-malware' scanning)...

known-malware scanning (more often referred to as virus scanning despite the fact that scanners have been detecting non-viral malware for a long time now) is a blacklist-based technique for detecting/blocking known bad programs... the blacklist itself is the set of signatures the scanner uses to try and match samples against...

known-malware scanning is obviously only effective against malware that is known...

back to index