the whitelister's dilemma

you remember marcus ranum's 6 dumbest ideas in computer security? #2 on that list was enumerating badness (aka blacklisting), which he believed should be replaced with enumerating goodness (aka whitelisting).

ignoring the fact that his underlying assumptions about relative sizes of the malware and legitimate software populations was incredibly wrong*, there's a much more fundamental problem with turfing blacklisting in favour of whitelisting:

the only meaningful criteria we have for deciding something is good or safe is that we haven't found anything bad in it yet.

oh sure you could assume that a system is currently malware free and start your whitelisting regimen from that (potentially pre-pwned) state. you could assume that software direct from the vendor is safe to add to a whitelist too (because microsoft never accidentally distributed infected materials, right?). you could even assume that things that are digitally signed are safe (it's not like stuxnet was digitally signed or anything).

of course, we know what happens when you assume. the reality is that even if we do adopt whitelisting we have to continue enumerating badness for the purposes of maintaining the whitelist. whitelisting stands on the shoulders of blacklisting - it has to, our only other criteria are assumptions that have all been proven false in practice.

as such, whitelisting can never replace blacklisting, it can only ever complement it.

[* according to figures by whitelisting vendor bit9 that i mentioned here, and frankly the idea of a malicious few coders out-producing the benign many seemed silly anyways]

don't be too proud of this technological terror you've created

lot's of folks have been posting about the 'here you have' mass mailing email worm that's been making the rounds. it's strange that such an old-school technique should inspire so much discussion, but it has and some of it's actually interesting.

one of the discussions comes from the enterprise application whitelisting blog, in other words, it comes from application whitelisting vendor bit9. they are, perhaps understandably, quite bullish about the fact that their technology would have stopped the threat before it could have spread while the anti-virus software vendors were supposedly left to scramble to get detection added after the fact.

while it's true that a classical blacklist or known-malware scanner would require updating after the threat becomes known, it seems that at least some of the anti-virus software vendors that harry sverdlove was taking a shot at were actually able to detect the threat heuristically (see f-secure's post or kaspersky lab's post for example).

it also deserves to be said that many anti-virus software vendors are bundling whitelisting in their suites these days, so people using that feature of those offerings would have been just as safe as if they'd been using bit9's.

most importantly, though - if social engineering can be used to get people to extract malware from a password protected archive sent as an attachment and then run that malware (and we have historical examples of successful email worms that used precisely this technique), social engineering can be used to get people to add that malware to the whitelist.

whitelists do not make you magically immune to this threat. i'm not even convinced they raise the bar a significant amount when you consider how easily people can be tricked into doing all sorts of dumb things. perhaps an enterprise would be in a better position because relatively few would (in theory) have access to modify the whitelist, but administrative users aren't above doing dumb things.

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...

symantec's reputation is in the clouds

the folks at symantec posted something interesting today - It's All About Reputation...

well, they're not the first ones to go into the cloud (obviously, see panda, trend, mcafee, etc)... nor are they the first to go with a reputation system (drive sentry, for starters)... are they the first to put a reputation system in the cloud? i don't know, maybe, but at this point it still doesn't seem like such a big deal...

what gets me, though, is the idea that it's no longer using fingerprints... a reputation system that says X is good, Y is bad, and Z is unknown is basically just a combination of a blacklist and a whitelist - and it's not a bad idea, i've been saying they complement each other well for quite a while now so actually putting both paradigms into a single product makes a lot of sense... the blacklist is what says Y is bad, the whitelist is what says X is good, and since Z isn't on either list it gets called unknown... the thing is blacklists use signatures (fingerprints) and in their own way whitelists do to - they have to in order to make sure the thing you're looking at really is the same thing you saw before and determined to be good/bad... it can't work without a signature/fingerprint/whatever... this new reputation system may use a different form of signatures, but it definitely uses them...

and as for how this protects you from brand new threats as the post suggests, i can only imagine it works like this: things on the blacklist are stopped from executing automatically, things on the whitelist are allowed to execute transparently, and things that aren't on either list will cause the user to be given an "are you sure?" prompt... finally, someone's putting dr. solly's perfect.bat (which asked the user if the file being scanned was a virus or not) to good use...

the other way it might work is that the unknowns get automatically run in a sandbox of some sort... not a sandbox meant for malware classification, mind you (a number of products already do that), but a sandbox intended to separate the handling of untrusted items from the trusted host system... i mean, since they're already adding 2 of the 3 preventative paradigms into a single product (hopefully seamlessly), wouldn't it be cool if they added the 3rd as well? i won't hold my breath for them actually implementing this, though...

look who's drinking the whitelist koolaid now

from a recent blackhat-related post on symantec's blog:

Symantec has been stressing for quite some time that we are on the cusp of a critical inflection point where the number of unique malicious code instances is surpassing the number of legitimate code instances.

the inflection point (shouldn't that really be an intersection of two curves?) will not and can not be reached... symantec is ignoring the figures provided by bit9 whose core business is application whitelists (so when they say good software is growing at a rate that is greater than what anyone says malware is growing at, despite the fact that it's in their interests to suggest the opposite, you better believe they know what the heck they're talking about)...

symantec is also ignoring the kind of basic logic i used 2 years ago when i said (without the benefit of figures) that good software outnumbers malware and grows faster than malware, and that i described in detail more recently: basically that malware writers are a small subset of the set of all programmers and there's no realistic way for a small group to outproduce a large group...

this reminds me of an earlier symantec gaffe wherein john thompson claimed the virus problem was solved... sometimes i wonder if symantec works on the philosophy of not letting the facts get in the way of good marketing...

debunking the mythology of whitelist practicality

while i don't normally listen to podcasts, it does occasionally happen and the risky business podcast episode 66 mentioned on the tenable security blog was one of those times... one of the topics discussed was the practicality of whitelists over blacklists and it amazed me (again) that people actually think this way...

why, when the number of developers making good software far outnumbers those making bad software, do people insist on believing there's more bad software than good and it's easier for vendors to keep track of good software than it is to keep track of bad software...

it's a pretty popular belief these days that it's not practical to keep track of all bad software anymore and vendors should be keeping track of the good software instead because that's somehow more practical but that belief starts to look a little ridiculous when you start considering the origins of the good and bad software in the world... just like most people in the world are actually good people (police states would be a necessity otherwise), most programmers are good people too so they're not writing malware... if most of the programmers in the world are writing good software rather than malware then it stands to reason that the production of good software out-paces the production of malware and since it has always been this way it should also outnumber malware...

as such, good software far outnumbers malicious software and is produced at a faster pace than malicious software... however big the set of malicious software seems and however fast it seems to be growing you need to ask yourself how much more aware you are of those stats for malware than for good software (a lot less attention is paid to those figures for good software)... i've mentioned before (and i'll probably mention again) that bit9 actually has some figures related to both the total number and rate of production of good software and it's shocking the degree to which it dwarfs those same measures for malicious software... billions of good programs while there were still less than a million malicious ones, and millions more good programs produced each day while malicious software is still in the range of thousands for the same period...

for the average person this may not seem intuitive; indeed, how could microsoft alone produce 500,000 new files each day - they certainly don't have that many products... the reason for the discrepancy is at least 3-fold... 1) the average person doesn't understand how many different things actually qualify as programs and would need to be kept track of if vendors were to supply whitelists, 2) the average person doesn't realize how many programs go into a single product, and 3) the average person doesn't actually have any idea how many products a company like microsoft actually produces because microsoft produces software for such disparate sets of people... you think ms word is just one program? it's not, it's many different programs that inter-operate to give you the functionality and user experience you're used to... if it were a single program there would be little or no need to install it, you could just run it as a stand alone application... the same holds for excel, and powerpoint, and outlook, and so on and so forth... do you think the hundreds (if not thousands) of megabytes that windows takes up is all because of data? what data does an operating system need? it's mostly programs...

a common refrain these days is that blacklisting just isn't working, but the problem with common notions is that they're often over simplified... blacklisting just isn't working well enough all on it's own... it is a challenge to keep up with the malware production rate so just imagine how much more of a challenge it is to keep up with the good software production rate... sure whitelisting companies like bit9 seem to be able to do it but you wanna know how? by using the same blacklists people think are failing in order to determine what's safe to put on their whitelist... it shouldn't take a rocket scientist to figure out that such a whitelist will be no more accurate than the blacklist it's based on - anything the blacklist misses will get onto the whitelist and then what will you do?

bad really is in the minority

from liam tung's article signature-based antivirus is dead: get over it:

However, there is a problem with the use of blacklists, said Turner. "When the majority of stuff you're handling is malicious, it makes more sense to use a white list because that deals with the exception — blacklists only work if 'bad' is in the minority."

i totally agree with this statement... there's just one thing that turner and just about every other av detractor out there fail to realize... bad really is in the minority... bit9 (an application whitelist vendor) has shown that there are several orders of magnitude more good stuff (on the order of billions) than bad stuff (about a half million at the time) and that microsoft alone produced as many good binaries in a day as there had been bad binaries produced in the previous 20+ years combined (from the bit9 presentation at the international anti-virus testing workshop in 2007)...

furthermore, most of the stuff anyone (other than the anti-malware industry) handles is non-malicious (unless you're looking only at email and are considering spam)... most web pages are safe, most binaries are safe, the majority of stuff most regular people encounter on a day to day basis is safe so if you're going to advocate a security technology that focuses on the exceptions you're going to have to get over your perceptual biases and realize that bad stuff is the exception so blacklists make more sense (at least by that logic)...

you've heard the argument that blacklisting is inferior to whitelisting because the list of all bad things is growing too big too fast, but we have quantifiable proof that the list of all good things is far, far bigger and growing far, far faster... that doesn't mean blacklists don't have serious problems (they do) or that whitelists are unusable (they aren't), it simply means that particular argument is fundamentally flawed and if people took the time to become familiar with the reality of the situation they'd know that...

what is a blacklist?

a blacklist is, simply put, a list of known bad things that we would like to avoid, block, weed out, etc... a blacklist is generally used in situations where everything is allowed by default except those things on the list... this is sometimes referred to as 'default allow'...

a classical real world example would be the TSA's no-fly list, an example that's often dredged up to support the argument that blacklists are themselves bad... another example would be the registered sex offenders list, a third would be the list of things you shouldn't take when you're pregnant, and a fourth would be the list of things you tell your child not to do... the argument against blacklists in general starts to fall down when you start to consider those kinds of examples - whether a particular blacklist is bad or not is not determined by the mere fact that it's a blacklist...

in the anti-malware context, the most well known example of a blacklist is a known-malware scanner (more commonly referred to as a virus scanner)... that's just a blacklist of bad programs, however... you can also have lists of bad behaviours, behaviour combinations, bad websites, bad (spammy) words in emails, etc...

back to index

the three preventative paradigms

something i've had circling around in my head for a while now is a fundamental division between malware prevention techniques... i'm moderately certain i've missed something (because three just comes up way too often in security) but it seems to me that everything falls into one (or more) of three broad categories: blacklisting, whitelisting, and sandboxing...

i know, right now you're probably saying "kurt! you missed a whole bunch of stuff - what about heuristics? what about behavioural techniques?"... well, lets look at that - what does behaviour-based malware detection do anyways? it monitors behaviours, sure, but how does it decide something is bad? what's going on is that it's actually comparing the behaviours (or combinations thereof) to a list of known bad behaviours (or behaviour combinations) which means it's a type of behavioural blacklist... likewise, heuristics compares properties (like the presence of certain familiar routines) of the program being scanned to a list of properties known to be used in bad programs and so also represents a type of blacklist... the blacklist technique is not the exclusive domain of signature scanning... anything that tries to identify something as bad (basically anything that tries to algorithmically answer the question "is this bad?") must do so by comparing it or some aspect of it to a list of known bad things of a similar type - and that makes it a blacklist...

"but kurt," you say, "that's not the only kind of behavioural technique out there. what about ones where you define what behaviour different programs are allowed to perform such as provided by various HIPS products?"... well, you'd be right, that behavioural technique is not a blacklist... besides being a process-centric access control system, it is more generally a behavioural whitelist... just as the blacklist technique is not exclusive to signature-based virus scanning, the whitelist technique is not so narrowly defined as to only specify application launch whitelists and/or the preferred paradigm for deploying firewalls... if it tries to block everything that isn't good/allowed/authorized (rather than everything that is bad/not allowed/unauthorized) then it must first be able to answer the question "is this good/allowed/authorized?" and to do that it must have a list of known good/allowed/authorized things - and that is a whitelist...

so if it answers the "is it bad?" question it's a blacklist and if it answers the "is it good?" question it's a whitelist - what's left? you might think it's some combination of the two but in fact it's not answering any question at all... the truth is our ability to answer either of those questions is limited so we need to take care of the case where we can't answer either of them and that's what a sandbox does... rather than blocking things outright based on knowledge of what's good or what's bad, sandboxing prevents malware intrusion to the host system by misdirection... the software which may or may not be malware is given a sandboxed environment to work in rather than the host environment and barring any ability to escape sandboxes, what happens in the sandbox (good or bad) stays in the sandbox... it doesn't necessarily prevent extrusion (leaking) of sensitive data you enter into applications running in the sandbox, mind you, and in that sense is a lesser form of prevention - but preventing malware from affecting the host system without any knowledge of or ability to decide on what's good or bad is no small feat...

if we could just assume everything that a blacklist doesn't alert on was good then life would be simple, but unfortunately that's not the case... likewise, assuming everything that isn't on a whitelist must be bad isn't very useful either (at least not unless you're dealing with very restrictive environments and even then there are complications)... once again, these three approaches are complementary and are best used together...

more on whitelisting

or perhaps moron whitelisting... yes dave, i'm taking the bait with the emperor's robin bloor's new clothes article about the decline of anti-virus and the rise of whitelisting... and it's pretty good bait too, since i wrote the rise of whitelisting (anything look familiar?) over a year ago in response to something else robin wrote when his misguided anti-virus-is-dead campaign was still new (a day old judging by the posting dates)...

i haven't really seen much new material that i didn't cover myself in that first response - exotic execution, accuracy of local whitelist management, and scalability of global whitelist management are all outstanding problems with whitelisting... finding out that the whitelist vendors themselves admit to the unmanageable scope of their own efforts is one of the few new things that have come up since then...

robin doesn't address any of this, of course, and like the emperor's new clothes there really isn't anything there in his new article... 2 whitelist companies merged and became bigger than either was before - big woop...

the only interesting things were the comments on the register's mirror of the article... vesselin bontchev hit the nail on the head several times (and i'd expect nothing less, though i wouldn't have expected vess to be first to post on the register - ugh), but what interested me most was the suggestion that robin bloor's 'research' is funded by the whitelist industry...

clearly this would be some segment of the whitelist industry that is misguided enough to think that anti-virus companies are actually their competitors... it's apples and oranges though, av companies won't be competitors until they start offering whitelist technology of their own... what's so misguided about this, though, is that if they actually manage to take av's place on peoples' desktops they're ultimately going to wind up also taking av's place in peoples' cross-hairs... if they displace anti-virus then people will necessarily become just as disenfranchised with whitelisting as they are with anti-virus because whitelisting has failings too...

in the comments robin does admit that whitelisting won't stand on it's own and that additional technologies will be needed to complement it but weasels out of saying what... i suspect intuitively he knows the answer: at the highest, most abstract level, what complements a whitelist? that's right, a blacklist... though he expressly derides the idea as "positioning" in his article and says that you should nevermind it, the fact is that known malware scanning and application whitelisting are natural companions...

i want to call robin bloor a troll, i really do, but if he's being funded by whitelisting companies then what he really is is a shill... either way, i'm done with him - when my arguments (and most other peoples' arguments) now are the same ones i posted if march of '06 there really is little point in continuing with this... besides, considering the uptick i get in hits based on searches involving the term whitelist when he posts more nonsense, i'm pretty sure the counter-arguments are being heard without additional effort on my part so i can put that you are being trolled feeling to rest...

the slow death of someone's credibility

robin bloor doesn't show up on my radar very often, but when he does it always seems to be about how anti-virus is dead, dying, or doomed in some way... this time it's about the slow death of anti-virus technology...

dave lewis thought it worth pointing to (thus leading to the blip on my radar) and the folks over on the authentium blog went against their better instincts and actually responded to it...

it's a good response, too, and it touches on a point i've also made about whitelisting - specifically that the numbers of good programs (ie. those that would be put on the vendor supplied whitelist) far exceed those of malware... why this is interesting is because one of the main arguments against anti-virus technology is a fundamental disdain for enumerating bad things on the premise of it being too big of a problem... clearly, if enumerating good things is several orders of magnitude harder than enumerating bad things then this particular argument is garbage... it's nice to see that a whitelist vendor is owning up to the enumeration cost, even if some whitelist proponents are unwilling... to the unwilling i would say imagine if the TSA used a whitelist instead of a blacklist - do you think telling most people they can't fly because they aren't on the fly list would work better than telling a few people they can't fly because they are on the no-fly list?...

this time around mr. bloor wants us to believe that, because whitelisting is gaining traction in the market, his prognostications about whitelisting replacing blacklisting are gradually coming true... seemingly choosing not to consider the possibility that the trends he's noticed are nothing more than the maturation of the whitelisting market, and unperturbed by history's numerous examples of the av industry adding technologies to their portfolios rather than replacing the old with the new, mr. bloor's arguments seem rather ridiculous...

but then again, they're coming from the same guy who thinks traditional polymorphism and server-side polymorphism are comparable - that because traditional polymorphism (where the transformation function responsible for the polymorphism is carried with the self-replicating malware and therefore open to attack by the av'ers) has been around for 16 years that the av industry should have developed something capable of dealing with the newly emerged server-side polymorphism (where the transformation function isn't carried by the malware and thus isn't generally open to attack) by now...

so should anyone take him seriously when he says whitelisting is better than av and that it's going to replace av? no, because whitelists are not going to replace blacklists, whitelists aren't better than blacklists, they're just different from blacklists... whitelists don't have the same weaknesses blacklists do just as blacklists don't have the same weaknesses that whitelists do... the notion that we would or should use only one type of technology to protect ourselves from malware is antiquated and fundamentally broken - there is no silver bullet, no panacea, and if you don't employ a multi-layered strategy (aka defense in depth) then you're just setting yourself up for unnecessary failure... i have to wonder, when av technology is still here 10 years from now, will robin bloor be eating crow or will he still be forecasting av's death like some inverted version of monty python's parrot skit...

anti-virus is not a faulty burglar alarm

wow, what a great analogy robin bloor makes here... too bad it's his reasoning that is faulty...

one of my favourite turns of phrase lately is mismatched expectations - robin bloor is quite clearly suffering from mismatched expectation by likening anti-virus to a faulty burglar alarm... anti-virus is nothing like a burglar alarm, faulty or otherwise, nor is the problem it is trying to solve amenable to a burglar alarm type of approach...

burglar alarms are pretty simple things - you have one or more sensors that detect basic, easily quantifiable environmental conditions (broken window, open door, motion, etc) and an alarm goes off when the sensor is triggered... this is pretty dumb, all things considered, but it works well enough when the thing you're trying to detect can be broken down to such simple events and even better when the home owner can easily decide whether something is a false alarm...

the malware problem, by comparison, cannot be broken down into simple elements quite so easily and end users are largely incapable of deciding whether an alarm from a malware detector is false or not... this is why behavioural detection techniques (which have been around for over a decade) are still not receiving the same kind of mainstream attention that known-virus scanning receives... instead of going the burglar alarm route, anti-virus incorporates a considerable amount of knowledge about the viruses (now more generally, malware) that the vendor has seen in order to minimize false alarms... anti-virus still has false alarms, of course, but just imagine how bad it would be if av were made to be as dumb as a burglar alarm... if we're going to stick to crime-related analogies, anti-virus is really much more like the criminal databases that have proven so useful in the past to keep known felons out of places they're not supposed to go or out of job positions they shouldn't have... not that those databases are perfect, but they sure do help...

of course, bad analogies are not the only thing robin has up his sleeve in that article... he spreads some clever FUD about the malware pandemic using carefully selected figures from a microsoft study i wrote about once before... yes, the malicious software removal tool removed malware from 5.7 million computers, but what robin fails to tell you is that it scanned over 270 million computers... that gives a malware penetration just 2.1% - hardly a pandemic...

all this is to build up to his conclusion that application whitelisting is a superior technology that should be used in place of anti-virus... maybe it is superior, maybe it isn't, it depends on things i've mentioned elsewhere, specifically whether the user can accurately decide what is safe to add to the whitelist and whether the whitelist can cover enough of the various types of program execution (it's not just *.exe's out there)... should whitelisting be used in place of blacklisting (anti-virus)? no, in reality blacklists and whitelists complement each other, they partially mitigate each others weaknesses, so they really ought to be used together...

and just as a point of correction - contrary to mr. bloor's assertion, application whitelisting is not relatively new... the basic idea dates back at least a decade as an anti-virus (gasp!) suite known as thunderbyte anti-virus included a rudimentary form of whitelisting in it's tbcheck module... tbav was a fairly well known product in it's day and there was plenty of opportunity for whitelisting to become popular, but it didn't... others have languished in obscurity too... anti-virus seems to have remained the most popular in part because it required the least amount of knowledge and/or thinking from the end user - and when it comes to malware, that can actually be a very good thing...

marcus ranum has found his saviour . . . or so he thinks

marcus ranum has finally found an execution control app (in other words application whitelisting software, the likes of which i've written about before) that he's happy with and apparently thinks could be the final nail in the coffin of anti-virus software - read it here...

yes, marcus is one of those people who thinks anti-virus is dead, or if it isn't it should be... he's taken shots at it before under guise of the stupidity of enumerating bad things instead of good things (nevermind the fact that there are far more good things in the world than bad) and in the above article makes reference to it as being an "default permit" technology... clearly, marcus likes to think in firewall terms...

despite that, calling anti-virus a "default permit" type of technology is a rather gross over-simplification... anti-virus software doesn't permit things, it deals with what it knows and what it knows is bad things - when it encounters one of those things it alerts you to the fact so that you can try to protect yourself from it and/or don't inadvertently do something dumb... what you do with everything else is entirely up to you, it's not anti-virus software's business to get involved in that... simply put, anti-virus software is a type of blacklist technology...

now, it shouldn't take a rocket scientist to figure out that blacklists and whitelists actually complement each other, especially here... yes, only allowing known good applications to run is more secure than simply filtering out the known bad ones, but how do you determine which ones to allow? predefined blacklists and whitelists provided by people with expertise allow us shrink the scope of this problem by reducing the number of things we'd need to determine the safety of unaided - but marcus would have us throw out one (or both, considering his reaction to prevx) sources of anti-malware intelligence and figure that sort of thing out for ourselves...

maybe i'm wrong, but i think most people use computers to get useful work done, not to waste their time researching whether executable X is good or bad when that information is often already available in downloadable form... most people aren't very good at that anyways (if they were the malware problem would never have become a big problem) and marcus is clearly no exception since he needed software to tell him that windows probably wouldn't operate properly if everything under the windows directory were denied the ability to execute...

when deciding what's ok to run the user needs help, especially with windows... microsoft has put a lot of magic into windows, by which i mean there's a lot going on behind the scenes that they make absolutely no attempt to be transparent about... without expert knowledge it's hard to know which of the hundreds of executables that get included with windows needs to be allowed to run in order for windows to operate properly...

marcus has apparently learned his lesson about the windows directory, but clearly not about the importance of making use of intelligence that has already been gathered... also not about knowing the enemy, and not about knowing oneself - by which i mean he appears to have not considered the weaknesses of application whitelisting technology... there are, and will always be, types of executable content that application whitelists won't be able to recognize (for example, new scripting languages won't be recognized by old whitelist software)... there are, and will probably always be, ways to get software that has already been authorized to do your dirty work for you (for example, internet exploder combined with some of those improperly labeled safe-for-scripting activex controls - or even buffer overflow exploits)... execution control software has a fairly limited notion of how execution can happen that doesn't actually reflect reality - most of the standard ways it can handle but would it have saved you from a WMF or VML exploit? would it have prevented macro viruses from ever becoming a problem? updating a blacklist to catch these things is relatively straight forward since you're just telling it additional things to look for, but updating a whitelist to deal with them involves making additions to how it looks for things being executed...

whitelisting is not the great stand-alone solution marcus thinks it is... it's a great complement to an anti-virus application, though, and an excellent technique to apply provided you can deal with figuring out what's safe to authorize...