While using whitelisting together with AV might make some sense, whitelisting alone will never be able to stop malware.

I recently attended a speech by some marketroid from Bit9 about what they are doing. Well, they are trying to establish a global whitelist of all known good software - and, apparently, are failing miserably (although he didn't say so, of course). According to him, just Microsoft, SourceForge and Mozilla produce about a quarter a million of new executables every day. Each. Currently, just the index of Bit9's database of hashes of known good software is more than a hundred gigabytes - and they are nowhere near finished.

How are you going to deliver that to the end user's computer? It's much worse than the daily (hourly?) updates that AV currently does. And a centrally accessed database simply doesn't work. What are you going to tell the customer - you can't use your computer today, because we have a networking failure and can't check the programs you want to run against our whitelist just now?

And how are you going to prevent malware from ending on the whitelist? The AV people have their hands full trying to analyze 5000+ new malware programs every month. And these guys are experts. Do you really believe that a whitelisting company is going to analyze a million programs per day, in order to determine whether they are malware or not - and not make mistakes?

And you can't offload the decision whether something should be allowed to run or not to the user, either - because the user is even more incompetent and will make mistakes even more often. After all, if the users could really decide whether a program should be allowed to run or not on their computers, they wouldn't get infected in the first place!

Preventing access to types of files by policy doesn't work, either. Are you going to prevent access to Word documents by default? That would make the machine unusable. And, if you don't, the user can get hit by a Word document containing an exploit. Yes, you can prevent unknown macros from running, and if the exploit downloads, drops and runs an executable - you can prevent *that* from running. But an exploit doesn't have to do that. The shellcode in it can do plenty of damage and it runs in memory directly from the document; unless you prevent access to the document to begin with, you can't stop that.

And what about viruses like CodeRed that don't exist as executable files in the first place?

The rumors of AV's demise are greatly exaggerated, I'm afraid.

P.S. Yes, I work for an AV company. That might make me biased, but at least I know what I'm talking about.

The controller of the centralised list would wield enourmous power. Suppose it was controlled by a company, call them "Monopolistic Software", how could competitors and open source developers get a guarantee of fair treatment in the validation process? Anti-virus does not have this problem because preventing a rival's software from running would require a positive act, blacklisting, that can be verified, demonstrated and used as evidence in court. The unfairness of "delays" in validation could be glossed over.

My further comments are here:

http://articles.yuikee.com.hk/newsletter/2007/06/k.html

I completely agree with Vesselin on the points he makes, Allan Dyers comments also shed some light on issues i didn't think about before.

As Mr. Bloor's "research" is largely funded by whitelisting companies, what did anyone expect from this article apart from the usual marketing blabber to draw attention to a relatively unknown tech bubble company?

Some of the vendors withinthe White Listing market do not rely 100% on lists of 'known, good' executables!

Yes, there are millions of executbales out there, i have thousands here on my laptop - it is a mangerial nightmare trying to maintain a list of known good applications, and then everytime the application is updated or patched then the list needs updating and pushing out to the end users..

Some of the leaders within the field use another, out of the box, methodolgy that will block all unauthorised executbles, and prohibit any new ones from ever running, whether they be known or unknown.

A practice called Trusted Ownership Checking works as follows:

All files (*.exe's, *.dll's, *.vbs, *.bat etc.. basically anything that wants to execute) will at some point reside on disk. When something is wrote to disk, standard NTFS practices kick and stamp that file with an owner (the person that wrote it to disk).

Now, if you were to populate a quick list of trusted installers (i.e Network Admin, System Admin, Computer ADmin, Installer Software.... basically the only person or account authorised to install and deploy software) you can prevent any user from executing code they have introduced to the system. In this case it does not amtter whether the code is known or unknown, where it came from, what it wants to do... The fact is, when the file goes to execute, quickly check the owner of the file, corss referrnce against list of trusted users, if they are nto on the list, the execution is blocked before it happens...

So as you can see, no need to create, update and maintian the whitelist of applications.. simple control by user ownership... Minimal Overhead, 100% protection!

"As Mr. Bloor's "research" is largely funded by whitelisting companies, what did anyone expect from this article apart from the usual marketing blabber to draw attention to a relatively unknown tech bubble company?"

Actually, it was surely much more an attack on the AV trough which you pay for for protection and which can guarantee nothing of the sort, except through a Denial of Service.

The neanderthal Big Stick approach to delicate, finely tuned, security matters.

"The rumors of AV's demise are greatly exaggerated, I'm afraid.

P.S. Yes, I work for an AV company. That might make me biased, but at least I know what I'm talking about."....... Exaggerated maybe, Doc, but is their demise/metamorphosis into whitelist holder/controller, their next logical move?

PS Do you know what I am talking about when I tell you IT is Quantum Communications Processing?

The commentators above miss the point. We run with an image workstation build where admin is largely withheld from the users, and installations are packaged and pushed out. We know all the executables we use and we don't want to extend that list without review. We certainly don't want users to run code merely because it's on a white list -- think about Google Earth licensed "for personal use only".

Windows can be set up to run nothing unless the MD5 is listed as approved. But no-one uses it because it's too hard to update the list. That's why I want whitelisting. It's a means for distributing approved hashes, not a source of them.

Malware detection, especially signature-based detection has got a future, but it's going to be an expensive niche service, on the perimeter, and in specialist devices, servers, stand-alone workstations and non-build equipment generally. Not on the corporate workstation.

Mind you, if that sounds bad for McAfee, it's worse for the whitelisting firms. They probably wouldn't exist at all if the existing hash software control in Windows was easier to use. Should we be watching for a functional improvement in Vista SP2?

At first, it seemed like the perfect solution to me - hell, I remember reading an article some FIVE YEARS ago about how the current AV programs were flawed, and how there were no programs whatsoever that would simply block executables that you did not want to run.

I was enchanted by the idea! It seemed so simple, but so elegant!

Then I got to thinking, and what I thought of I didn't like. There would have to be some central database listing all of the known good programs. Good programs are created all the time. And what happens if the people in charge of this database take some cash from, say, Microsoft to prevent older versions of software from running in order to maximise their own profits?

I run Office 2003 because it came with my laptop of the time and because it suits my needs. I feel no urge to buy 2028 or whatever the hell the latest version is because that would be extortion - I don't NEED it, so why should I BUY it?

But if Microsoft could force me to buy their programs? If any software vendor could force you to upgrade to the latest and greatest simply by removing older versions from the whitelist?

And what about competition? "Hey, man, I'll slip you 500k if you take Open Office off of your whitelist..."

And what about all my Japanese ecchi games? Do you seriously think THEY'LL get whitelisted? Hah!

Something DOES need to be done about computer security. But whitelisting isn't the answer; it's just fascism, a "Father-Knows-Best-Dear" policy that imposes a rule from the top-down without regard for what we may want. Fascism sounds good to fearful people, but it's never an answer; what you lose is more important than what you gain.

Or in the words of Ben Franklin, "Those who give up a little essential freedom in exchange for security deserve neither."

Neither solution is perfect - this is the nature of security.

I very much doubt that the implementation of whitelisting will require a new check every day to get your normal applications to work. It will cache these results and only need to go 'outside' for new files. This will make it viable for most things - except macros I would have thought. But what is is going to do with data files which have been infected and are using buffer over-run vulnerabilities to execute arbitrary executibles on the users PC? Surely they're not going to try to put ALL files into a database.

Desktop AV is good at what it does - detecting known viruses on the desktop. It's not so good at catching the new viruses for one very good reason - we expect it to be very fast. If AV is given more time, it will be better at detecting new viruses, but our users expect everything yesterday, so we daren't turn up the wick on the detection for fear of them complaining their PC is running 0.5% slower than it was yesterday.

Sounds to me like whitelisting will become a major technology, but as part of an AV solution, not the whole.

Andrew Radley

StreamShield Networks

SourceForge has 100.000 projects and you claim they produce 250.000 new releases per day? Same applies to Microsoft with a few hundred releases per year and Mozilla with a handful...

A hash database of hundred gigabytes would contain some 6 billion hashes. That's 17000 applications released per hour for the past 40 years.

Nobody knows how many new applications are released per day but it's pretty certain that it's a lot less than one million. I'm sure there isn't even a million software companies/OSS-groups in the world.

I'm not implying that AV software isn't needed in the future, I'm just pointing out some obvious flaws in your post. You are biased.

Why should I need a multi-gigabyte hash list ? I don't think whitelisting should work in that way. To me, I should only need to whitelist what I have running on my computer, same was my firewall lets me specify which apps can access the internet.

That should cut down the size of the required database to a mere few hundred kilobytes.

I designed my own mail whitelist filter and it actually works pretty well. Whatever it does not keep goes to a spam database, where another process deletes anything that is not from a domain I approve (I don't know anyone in .ck, so I don't see why they are sending me this "Offer you can't refuse"). I can then peruse through what is left and delete or add filters as I see fit. Whatever is really important I can copy back to my mail and validate so that it is whitelisted next time.

Whitelisting is a great idea, and I say it should be aggressively pursued. I'm looking forward to seeing a useable implementation.

Can we have someone who isnt from marketing tell us something about it ?

How can something so flawed be so relentlessly promoted as a panacea cure for malware?

Whitelisting will be the death of the shareware and free software industries. I cant believe it keeps coming up in amongst the otherwise sane articles on the Reg

Create a whitelist server which doesn't download the entire database, but compares the programs your company uses to the global whitelist and then applies the appropriate whitelist entries to a LOCAL whitelist. That way the overhead of the global whitelist is avoided, and updates are only run when new software is introduced into the corperation / updates of applications are rolled out.

Rocket science it isn't.

It's all a bit tedious isn't it? Our way is best! No, OUR way is best! NO OUR WAY IS BEST! And so on, ad infinitum. This "problem" is never going to be solved by a single technology or single software provider. Whitelisting isn't "the answer" same as blacklisting isn't, or AV or any other measure.

About the only reliable solution is to disconnect your computer from the 'net. And even that doesn't protect you from hardware failure. Nothing is going to stop that overpaid exec from leaving his laptop loaded with the entire client database in an airport lounge. Considering this is really all about risk management and system uptime, the only thing you can do is have rock solid policies and strategies in place so that when the worst happens, you know how to deal with it.

I'd love to know, though, how the marketing people at ESET (I'm wondering ir Dr V up there is one of theirs) feels about having their spangly flash advert for the No.1 AV product from 2006 on the same page as an article that says all AV is crap and you don't need it. That did tickle me.

If the whitelist includes, say, Excel, then it's game over. The same is true for any other "honest" application that exposes a scripting environment. The Microsoft COM world exposes large swathes of functionality to those scripting environments. Unless the application supports sandboxing (which would presumably open up a world of holes as implementation errors abound) you need an n^2 model: perhaps the MAPI library should be available, _except_ to excel. That might be managed centrally. Even this doesn't work particularly well: trusted parts of Excel might well be legitimately able to make network connections, but the scripting engine might fall outside that boundary. And then you have the problem that _some_ scripts might actually require such connectivity, but other macros should not have it.

The MS OS model is not type-rich enough to really manage this. Approaches like Singularity, I think, offer a better chance of managing this complexity: object instances act as capabilities; access to those instances can be gated via factories and security managers. Without decomposing the large MS desktop applications into separate components, each with their own security policy, I can't see whitelisting as a particularly effective approach.

A lot of the comments here pretty much seem to deal with the corporate environment, which is fine and afterall, does need protecting. But what about the home users? They can't wait around for someone with specific admin access to come along and whitelist the programs they want. They are the admin themselves.

As always the home users are the ones who are going to be the big problem here. More often than not, they are the God of their own computer, regardless of how much actual knowledge they have and they're the ones propogating the mass of virii.

All these solutions seem to do is take a large database of known quantities and let users interrogate it in one form or another. In a real home environment these options aren't really practical. The only reason AV vendors get away with it is because as older virii drop out of use they get dropped from the database to keep the size down. Then they get reinstated if there's a new outbreak.

The whitelist approach will work in locked down corporate environments where the build rarely changes. Users typically have no Admin privileges and find it difficult to install software anyway. That’s one type of PC. The other type is the unregulated one often found at home. If you have children then there’s and even greater likelihood that they will be installing new games/demos/programs on a weekly or daily basis. Putting aside the rights and wrongs of how kids treat PC’s, how will whitelists cope with this?

I get irritated with Bloors articles as he has a vested interest and they are never impartial and often irrational. And no I don’t work for an AV company. I do however have a few PC’s and three kids. I want something that will allow the kids to use them but will keep out all the malicious code.

There is very little doubt, as already said, that whitelisting (on it's own) cannot hope to control malware. The technology is very useful but only when working alongside a malware engine. Which, by the way, is already in practice.

So what happens if AV as we know it has been made extinct and a network becomes infected? Would the whitelist software have a way of disinfecting any programs?

If so, then surely you are actualy using an AV engine of some sort.

If not, are we expected to believe that whitelisting will have a 100% catch rate?

This would be a complete nightmare!

For example, this week I have been working with a client who's been changing some of his backend systems. This has resulted in me sending him several test applications that I've knocked up during the course of the day. Can you imagine how impossible this would be if I had to get each test app checked onto a whitelist?

Even now we occasionally bump into a customer who has over enthusiastic filtering. There was one that blocked pretty much every file extention known to man. We tried changing the .exe file extention to many things, including .wav (which still got blocked!).

Ironically we eventually managed to get an exe to them by zipping it up and then changing the extension to .doc. Docs are of course perfectly fine and have never carried anything nasty have they!

Whitelisting seems great for industry. The IT guy defines a set of states in which his machines are allowed to operate (NB: the secretaries machine may be in a different state to the MDs and then there's the linux guy). BUT, we already have a solution for this - Trusted Computing.

Of course, updates will be an absolute pain! But the IT guy will be testing these and deciding which to install? And subsequently updating his list of states.

In the home market on the other hand, it simply won't work! User can't install `really cool app' he has discovered. User disables protection software. User is in worse position than before.

Hey Blackadder,

Put down the handbag!

you should read more carefully, see those two little words "According to him" Vesselin was quoting.

Whitelisting is a fantastic idea, no worries there. But...

The idea of all malicious code running from executables is a flawed assumption. Take red-pill blue-pill for example. A cool way of getting kernel-mode running via the paging file. You absolutely do not need an executable to get kernel mode code running. You absolutely do not need a driver image file to sustain a presence in kernel mode. If you have a presence in kernel mode you can easily start introducing different code paths into any process you like.

"Ah, but you can checksum verifications of loaded modules frequently..." When do you do this? Are you absolurely sure that you have those nanoseconds requried to do something horrific to your machine covered? Is your thread that does this still running? Are you dispatch routines still what they should be? While you are busy fixing that what damage has/is being done?

Whitelisting as a complete security solution needs to do a lot, lot more than I unserstand it currently does. I am no expert in whitelisting, but to my mind there is a serious amount of extra work to do.

Now, if there was a whitelist that guaranteed the known good software has no exploits too, then I would be happier. However, software with no exploits is as rare as rocking horse poo. And here is my favourite response I got from a pro-whitelisting guy (not a quote) "so, if an exploit is found in a binary, it can be removed from the list...problem solved!" Ummm, this sounds like a window where millions of machines can be totally boned and not actually that different to waiting for an AV vendor to release a signature/definition/heuristic update.

Ultimately, software can be subverted. Having a bunch of device drivers (or any other module for that matter) loaded on my machine with data sets on which decsisions are made reminds me somewhat of AV anyway.

Blackadder, can I suggest you read Vesselin's post again and work out just who the figures quoted come from? Hint: it's not Vesselin.

The problems people are mentioend in raltion to what about needing to add new applications to the white list is easy to work with.

Some of the vendors i have looked into allow for a 'Self Authorising Mode' - where admin priveledged user, or, trusted users, have the ability to authorise their own executables that would normally be blocked by the solution.

For example, some guy makes his new application or installs something that needs to run, this is not on a whitelist and would normally be blocked from running. He is assigned as a self authorising user and so he is promoted, this would normally be blocked, do you wish to run it? - can click yes if it is something legitimate (also audited and archived). This protecs also from malware trying to run, again, this is not on the whitelist, do you wish to run it? - nope, i had no idea this awas about to execute, i do not know what it is, so i am going to block it before it even runs!

The other point on here is that people are assuming they need a whitelist for all global executables? - this is uneccassary, only need one for the applicatins within your environment surely? yes this can take to populate..

this has already been mentioned but the long winded approach of whitelisting is superseeded by in my opinion, a more secure and more manageable way to whitelisting.. the trusted users approach.

Only things that are owned by an approved user or account is allowed to run, no need for whitelist of applications, if you are not on the list, you can not execute your own code! no white list needed!

This also protects authorised applications from being exploited with vulnerabilites, for example if something tried to execute as a macro or script from with Word or Excel, the piece of code that is trying to execute is owned by the user, and as the user is not on the list, the bad code can not run, although the word or excel programme is fine..

Whitelisting is ok, but by no means the answer.. there are far more effective ways of securing the environment with the likes of trusted ownership and automaitcally self healing and repairing registry keys from malware drops!

I know of one particualr vendor that does this, and have seen customers that have audit trails of up to 300 instances of blocked scripts and applciatins per week! that would not have been picked up by the antivirus, and anti malware engines...

I have read the comments posted so far with great interest.

There are some great arguments for white listing as an alternative to AV technologies. I personally believe that AV has had its day and we as IT professionals must have a solution that is more secure, scalable, and maybe most importantly of all easily manageable.

My feelings on whitelists are simple. They are way too difficult to manage effectively by far. The arguments against whitelisting are very valid. How do you manage a white list for 10'000 machines? It just isn't practical. Who wants a global list of "safe applications" held by some corporation somewhere? I certainly don't. There are others ways and only one person here has mentioned it so far.

Trusted Ownership. Yes, I do use a product where trusted ownership is key, and I would say that as a simple yet very effective way of stopping all unauthorised executions not just of exe files but anything that asks to be execute., In my opinion there is no better solution.

I have an installation account (install_user) and install all my apps as that user. That user account is one of the "Trusted Owners" in my list, once deployed, any application that tries to run that is not owned by install_user will be denied. That means if I (admin) or any of my users download spywhere, it won't run. If a user downloads some software they shouldn't, it won't run. I have complete control, and my trusted owners list is tiny. There is other functionality but I'll leave that for another time

Secure, scalable & manageable. Works for me

AV worked, Whitelisting is better, however trusted ownership solves the issues that Whitelisting can't by its very nature

Guys, seriously. Does anyone think for one minute that a whitelisting system wouldn't allow for exceptions? You'll get a little warning message that says the app isn't on the whitelist and our good friend the "ignore" button will be right under it. Oh, you'll be able to turn it off for your corporate users, no point in letting them have their way, but the home user will be able to click it any time he likes.

In truth, we already do whitelisting. Signed device drivers, phishing filters and web browser "safe/unsafe" utilities all use a sort of whitelist to help users make smarter choices.

It's caused very little problems in the real world, and application whitelisting will be no different.

Does the solution stand on it's own? No. Any solution that relies solely on a list of what's good and what's not good is doomed to fail. Of course, that's assuming that the whitelisting technology stays static. Antivirus developed hueristics, whitelisting probably will too.

The biggest problem out there right now are users who don't know enough not to run or install apps without checking with someone who can tell them if it's malware. Basically, what this does is allow the average user to install apps while reducing the risk that the app is malware.

Don't view it as evil, or the ultimate answer to life, the universe and everything, just look on it as a helpful signpost for those who can't find their way out of the malware forest.

You need more than one solution. The more the better.

Whitelisting hasn't worked to control spam. I have one domain that is blacklisted by Spamhaus. And they won't tell us why.

Couldn't whitelisting be used by, say, the RIAA or MPAA to block certain downloads? Nah, that would never happen.

Dr Vesselin what are you a Dr in. I can take it from your knowledge on CodeRed its clearly not IT. “The "Code Red" worm is self-replicating malicious code”

Also If you understood how virus's work you would know your black list approach DOES NOT WORK. The last report on AV said 98% of KNOWN virus's were captured by the leading AV company (no names mentioned). 98% of KNOWN, why cant you capture ALL, they are bloody KNOWN. What hope do us end users have

A lot of people seem to be missing the point here (perhaps on purpose if they work for an AV vendor)… you don’t whitelist every application under the sun – you simply approve those applications that you need to run on your network. Most enterprise whitleisting solutions will push only differential updates to clients when new applications have been centrally approved and thus minimise network traffic too. A good whitelisting solution will also include flexibility such as local authorisation which can grant certain users the ability to override policy, but be fully audited and whereby administrators can then accept or reject the authorisation of that particular application should a user abuse their privileges.

The merger of Pathlink and SecureWave for example is a clear indication of where this market place is moving. There is a definite need for a unified protection solution that offers vulnerability assessment, patch management, application delivery, application white-listing, remediation and peripheral device control. Patchlink are now not only able to offer all of this, but also make whitelisting even easier to implement via automation of updates to the whitelist require for patch and application delivery.

@ Dillon Pyron: "I have one domain that is blacklisted by Spamhaus. And they won't tell us why."

Tell me the domain, and I bet I can find out why in less than 5 minutes - without asking Spamhaus, most probably.

I see Mcaffe have found a way to maintain some anti-virus market share by placing advertising in a whitelisting article. Clever :)

Nice to see a new buzzword for an ancient technology.

Maybe I view "whitelisting" in a different light than the vendors trying to sell the snake oil here, but it's pretty easy to "whitelist" programs on your own desktop and ban everything else by default. It involves logging off your admin account already and using a limited account (or standard on Vista, or restricted on 2K). Of course it means dumping the old stuff that doesn't work, but hey, at least you don't have to pay for a subscription to whitelists.

I guess I was just seven years ahead of my time.

While most people seem to have got the word (whitelisting, by itself, can't stop malware; multi-layered defence in depth should be used instead), many have obviously not read my comment carefully enough - or have forgotten to engage their brain while doing so. So, I guess, some additional clarifications are in order.

Anonymous: Trusted Ownership doesn't work, either. Everybody runs as admin anyway. :-) Even the idea isn't new - there was a paper in "Computers & Security" in the early 90s about using "strongly labeled objects" to stop computer viruses. Doesn't work, folks.

amanfromMars: We deliver exactly what we guarantee - protection from the vast majority of known malware. Nothing more, nothing less. Oh, and cleaning up your messes after you manage to get your computers infected anyway. We'd gladly sell you something stronger than that (e.g., integrity checkers) if you morons were just smart enough to buy them and use them properly. Sadly, you aren't, so we sell you what you want to buy - known-virus scanners, the weakest kind of protection against viruses. And no, AV companies won't methamorphose into whitelisting companies. At best, we'd add whitelisting to the set of tools in our arsenal, if it proves a viable approach - which seems unlikely.

umacf24: You haven't been reading. Go back and re-read the part of my comments about executable code residing in non-obvious places like shellcode in Word documents with exploits. In other words - things that is simply not practical to whitelist.

Andrew Radley: Actually, stopping non-whitelisted macros is pretty trivial. Microsoft Office after version 2002 does it by default, except that they offload the responsibility to the user (as usual). Recent versions of Office won't run (and will silently ignore) any macros not digitally signed by a key the user has indicated as trustworthy. It's not the macros that are the problem. It's the data files containing exploits and shellcode - Office documents, GIF/JPG/WMF files, ANI cursors, etc. If you don't block access to those, you can be hit by malware; blocking access to them makes the system unusable; and whitelisting the "good" ones of them is not practical, because they are created and modified a lot more than executable files.

Blackadder: I don't vouch that these numbers are correct. I was quoting a guy from Bit9, who are major proponents of whitelisting. Maybe he was lying through his teeth to convince us how hard they are working. All he managed to convince me was that they have no hope of ever succeeding.

Pascal Monett: And who's gonna build that whitelist exclusive for your computer, huh? Either you're going to get it from somewhere, or you're going to build it yourself. If you're getting it from somewhere, since you're not the only customer around, whoever is providing you this service will want to sell it to other customers too - which boils down to maintaining a global whitelist which, as I already explained, is unfeasible. If you are building it yourself, you're guaranteed to screw up, if you're anything like the average user.

Jim bloke: I'm not from marketting, gawdammit! I'm a techie.

Matt Thornton: No, I don't work for ESET. Google me.

Rob: No, we don't drop from our AV databases detection of old viruses. If we did, the testers would find out and scream bloody murder. Of course, why we still have to detect the Ping Pong virus, which is a boot sector virus that works only on 8088 CPUs is anyone's guess.

Nick Dinsdale: I'm a doctor (Ph.D., actually) in computer anti-virus research - as you would have doubtlessly discovered, had you bothered to rub two brain cells together and do a Google search for my name. Got my title from the University of Hamburg. That's Hamburg, Germany - not Texas, for our geographically-challenged US readers. My Ph.D. thesis, titled "Methodology of Computer Anti-Virus Research", is used as a textbook at several AV companies to train their personnel. Yes, CodeRed is self-replicating malicious code. And that invalidates my point exactly how? For the slow among us, my point was that this virus does not exist as a *file* (only as network packets) and therefore cannot be stopped by denying access to non-whitelisted programs (which are, per force, in files). Oh, and if *you* are the one who is in charge of maintaining your local whitelist and determining what is allowed to run and what not, I guarantee you that you're going to screw up. Better employ the services of someone who knows what they are doing. Finally, the merger of Pathlink and SecureWave is no more "a clear indication of where this market place is moving" than the merger of half a zillion AV companies before them - companies that made virus scanners.

Hmmmmmm Dr. Vesselin Bontchev...

Something strange here... Can you please explain to me how Trusted Ownership can be bypassed? I think we all know which vendor uses this as their flagship method, and that vendor has apparently never, ever, seen anything unauthorised (be it user introduce app or unknown malware) ever execute in it's working environment.

When I say working environment am I am ranging from some of the biggest banks, governtment bodies, telecoms, defence etc.. companies, through to various experts at Hackerfest and many other security conferences... no one over the past 8 years has ever got round it, as long as it is set up, configured and then used correctly.

I have seen them offer large cash prizes for anyone who can execute something unauthorised, either intentional game, applet, script.. or something that would have been deemed a zero or pre zero day threat... by any means, from usb key, to root kit, to scripted exploited of a known good application...

Please, for all of us who have invested in this technology - simply detail exactly how to bypass a proven technology, and i will give your comments the repsect they then deserve. Until then, I'll continue to think that you either have not seen how trusted ownership works, or, understand how it is supposed to by intergrated into 50,000 user environments?

Moving on - what is all this about a global white list? - why on earth do i need to populate a global white list, that will contain appliacions and files that are totally useless to me as they are never going to run in my environment and they are not part of my users build, so why must i search for these new applications to whitelist them? - utter rubbish?

YOU ONLY NEED TO WHITELIST THE AUTHORISED APPLICATIONS WITHIN YOUR ORGANISATION - NOTHING MORE! and this is easier than it seems, most of the vendors have wizard driven approaches to locating all relevent files and scripts, then automatically assigning them with a SHA-1 Digital Signature/Has.. Job Done!? Please xplain where in that scenario do i need to go out and update my whitelist to put on some foerign application i never going to execute? Please... explain!

Yes, AV is pretty good at stopping what it knows about (well, about 98% of what it knows about) - but something more is needed to block the thousands of other pices of code it does not, and proabably will never know about! - Bring on Whitelisting.. but more importantly, for a more secure enviornment Trusted Ownership and partial WhiteListing is optimal... How else would you prevent a targested piece of code that is sent to a specific user within in an organisation? , yes, may get caught in a spam filter, but again, working on lists and rules.. some will get throguh, some will execute, it will not be known my AV and will then happily sit there recording key strokes, sniffing netwroks.. what ever it wants! If Trusted Ownership was installed, regardless of where the code come from, or what it plans to do when executed, Trusted Ownership would block before it executes! by sittig at end of execution queue, simply checks the owner stamp on the file, compares to list of trusted instalers (which for your information does not include everyone as they are admins) and cos the user is not on the list - the script or exe is prevetned from launching!

Please again, tell me how this can be bypassed and why i need to populate a Global List of applications for my whitelist...

Dont forget.. prove some of this technology wrong and there could be a nice hefty cash prize waiting for you! - prove us and them wrong, may be earn your cash and and be the big name in security that broke this so far successfull model, i will then happily eat humble pie.

The two different approaches have a similar difficulty - that of keeping up with a changing list. The difference is that with a whitelist you should at least be partly (if not wholly) in control of those changes.

As pointed out already, with AV you pretty much assume the vendor will keep the whole list up to date and you just take updates of that. With a whitelist, you need to be much more selective, depending on what your objectives are. Whitelisting is of course not only an anti-malware tool but has advantages for license management and stopping 'good' but undesirable software - such as all sorts of tools which have legitimate admin uses but you would not want in the hads of regular users.

Getting users to run without admin priviledges should be a much higher priority for most people. Only after that huge gaping hole is it worth expending the time and effort on complex things like whitelisting.

I've written more about my own succes with whitelisting on my blog, here:

http://veroblog.wordpress.com/2007/06/28/whitelisting-applications-versus-anti-virus/

Anti-Virus is Not Dead – AVIND; nor, incidentally, are anti-spyware or anti-anything dead. We need to be able to identify and remediate (i.e. have research and signature-based technologies) as well as block and prevent (technical issues with white listing not withstanding).

Rather than repost material, I'll offer a link. I put a more extensive position around this together on the CA blog yesterday (note it's not a vendor specific or commercial blog at all, it's for Research bloging) at: http://www.ca.com/blogs/default.aspx?pgType=com&id=90744

Folks, (a) this ain't no chatboard, (b) I hate repeating myself and (c) I have a very low tolerance for stupidity, so do everybody (yourselves included) a favor and read carefully what I write and try to understand it and think while doing so, OK?

Network_Ninja, I never made any statements about the bypassability of "trusted ownership". I only said that the concept of stopping viruses by using strongly labeled objects is not new (dates from the early 90s) and that it DOES NOT WORK. It might work in some very limited and fascist setups, where the user is allowed to run just three and a half applications playing hopscotch with each other's data - but in a normal, working environment, IT DOES NOT WORK. It makes the machine unusable and the users rebel against it.

As far as bypassability goes, it depends on the implementation, of course. Given that you're oh-so-enamored with the buzzphraze "Trusted Ownership", you're probably referring to AppSense? Well, the last time I looked at it, it was using the NTFS owner to label the objects - i.e., it was working on a file basis. Meaning that anything that didn't depend on the concept of "executable file" would get right past it. Scroll up and read again - and again, and again, until you understand it - my example about a Word document with an exploit and shellcode that does damage without dropping and running an additional executable. Would you authorize the user of the protected computer to run Word? If not, the computer is unusable. If yes, would you authorize the user to open documents that were externally introduced (e.g., e-mail from somebody outside the organization)? If not, the environment is unusable. If yes, you're vulnerable. Case closed.

As far as "banks, governtment bodies, telecoms, defence etc.. companies" go, in my long career as an anti-virus researcher I've had to disinfect computers from representatives of all of those - so don't tell me how well they are protected.

As far as the "global whitelist" goes - I've already explained it TWICE - and you're still not getting it?! Yes, I know that you're interested only in whitelisting the good applications on your computers. Sadly, you're not alone. So, if a company is to provide such a service (i.e., building such a list for you), it will perforce have to build a global whitelist - in order to account not only for the software on your computers, but also for the software that might be found on ALL their customers computers. Hopefully, you don't imagine that such a company will have the only goal to serve you and nobody else? Nope, they will have to maintain some sort of global database of known (to them) good software - and even ship you updates (hourly?), so that if you want to install some new piece of software, your protection doesn't prevent you from doing so. In fact, some companies that tout whitelist-based products (e.g., PrevX) have already started doing so. So, it's just as bad as AV - no, it's worse, because good programs are created even faster and in greater numbers than malware, so it's more difficult to maintain.

The alternative, of course, is to build the whitelist yourself. Then, yes, it has to contain only your executable files and nothing else. But that assumes that you have the competence to do so. My congratulations if that is so - it puts you in a vanishingly small minority of users. Oh, and it assumes that you have the competence to determine that your system is not already infected at the time when you create the whitelist. Oh, and it also assumes that you never install anything new on your computers - or that you have the competence to determine whether the new thing is malicious or not and to put it on the whitelist. And if you have all THAT, then - surprise, surprise - you need no whitelist or blacklist (i.e., AV) - because you never install anything malicious on your computer anyway. Congratulations again, but the remaining quarter a billion users are still looking for a solution that doesn't require them to be able to do all that.

As good ol' Doc Fred Cohen proved more than a couple of decades ago, there are only three ways guaranteed to stop viruses - limited functionality (you can't infect your microwave oven), limited sharing (you don't pass stuff from one computer to another) and limited transitivity (even if you do pass stuff to another, it can't be passed further). If you can implement and enforce any one of those, you're safe. But the rest of the users are looking for a solution that (a) doesn't make their machines unusable and (b) doesn't require them to have a Ph.D. in computer security.

To put it another way: if your favorite Trusted Ownership actually worked, wouldn't you think that everybody would be using it and malware would have been a thing of the past?

AdamV, whitelisting and AV (which is essentially "blacklisting") indeed do complement each other - but for a good defense in depth you need even more than that. I wish the users were intelligent enough to realize this and competent enough to set up and use properly defense-in-depth, I really do. Sadly, they aren't.

CodeRed needs an endpoint to execute. If it can't execute, it can’t do any damage. Let me put it into laymen’s terms for you. Humans are inoculated against the flu. This doesn’t stop the flu from flying around in the atmosphere, but it can’t infect the end user.

I’m not suggesting don’t use AV, but within a corporate environments, there is no need to run AV on each desktop/laptop. Run only the free clear up part of Defender perhaps once a week or month. This method along with whitelisting will future proof the company.

Also if you had done your research, you would find that effective whitelisting solutions are centrally controlled by the IT dept and do not rely upon users to maintain their own whitelist.

Last point which made me laugh last night when reading your reply DR, You say you have to visit banks & other agencies to disinfect their machines. AHHAHAHAHAHHA was this becuase their AV failed. I do belive you have just proven yourself wrong once again

Unplug all network cables, Internet connections. Turn off WiFi, Bluetooth and anything else wireless. Disable infra-red. Remove floppy drives, CD/DVD drives or stick some tape over them. Tape up the USB/Firewire ports. etc.

Then your system will be safe and there's no need for AV or whitelisting at all! ;-)

Oh and just to be sure, remove the keyboard, mouse, remove the power (and batteries if applicable), lock in a cupboard.

On a more serious note, corporate IT control of what can and can't be installed is frequently rendered useless by end users who require local admin rights (developers in particular).

Nick Dinsdale, stop posting nonsense and go read how the CodeRed virus works. It exploits a buffer overflow in idq.dll and enters your machine as a network packet (HTTP request). It is never saved as any kind of file - it exists only in memory. Whitelist-based protections rely on compiling lists of known-good executable programs that are allowed to run. Even if we leave aside the very difficult (theoretically unsolvable) question of what is an executable program and what isn't, the point is that they whitelist FILES. And, guess what, CodeRed DOES NOT EXIST AS A FILE! Got that? What are you going to whitelist or blacklist in order to protect your machines from such attacks? Network packets? Or maybe you're going to specify by policy that vulnerable DLLs aren't allowed to run? That would make your machine unable to connect to the 'net. Not to mention that you don't know in advance that they are vulnerable.

As far as "whitelisting controlled by IT dept" goes, what do you think the people in the "IT dept" are? Gods? Nope, they are users, too. And, yep, they, too, are incompetent as far as malware protection goes. And they make mistakes too. Not to mention that the environment "you're allowed to run only these few applications and nothing else" simply doesn't work for the majority of environments - a few fascist high-security setups being the vanishingly small exception. And what about the gazillion of home users? Who's gonna protect them, eh? Are you going to assign somebody from "IT dept" to each one of them? Or will they have to rely - banish the though - on conventional AV?

As far as "not needing AV on every desktop goes", you need AV (and, mind you, not just a scanner!) at EVERY ENTRY POINT. In some companies, that's every desktop. In others it's only some machines.

Regarding the last point about disinfecting supposedly secure environments that had become infected - nope, it wasn't their AV that had failed, alas. In most places, THERE WASN'T ANY! In a couple of cases they had bought an AV product AND HAD NOT BOTHERED TO INSTALL IT, the morons! So, again, do not presume to tell me how "well-protected" these places are!

"Antivirus are dead" or whitelist approach as the substitute of the blacklist, well this is here quite excessive: what about classical users who are the champions to surf on porn sites, p2p networks or warez (video games for free)...how can they filter infected files from safe file? by an analysis with a debugger on a test environment?

The future of "Defense in dep" in any environment (home or corporate) is a combination of several technologies and security models and approaches; virtualization (in vogue, higly appreciated by "cost killers"), black list softs (antivirus, web filters), white list softwares (HIPS and anti-spam for instance), hardwares protection (antivirus in the chipset, antirootkit like Copilot), Rollback or reboot and restore softwares (DeepFreeze etc)...

But there's a fact: antivirus need to operate their mutation: an antivirus only based blacklist is not currently an interesting investment: a behvioural analysis module for instance could be a plus:

That's was demonstrated by "A-B-C" by the test of the Security Sofware Testing Alliance:

http://ssta.over-blog.fr/article-10792223.html

I suggest the read first of the last article: "antivirus: the antimarketing test".

Let's imagine the result with a pure antivirus..RIDICULOUS...

Regards