Header Ziff Davis Enterprise
Advertisement
Advertisement
Friday, September 21, 2007 12:33 PM/EST

Delist This Security Idea

SecurityEverybody loves lists. Magazines love lists; TV shows love lists; Web sites really like lists. But possibly no one loves lists more than security vendors.

When you break down a lot of the core elements of security products, it often comes down to big lists. Lists of known viruses and spyware, lists of vulnerabilities, lists of access controls and lists of programs that we want to run and programs that we don't want to run.

This obsession with lists most recently came up in reports from one of the largest security vendors out there, namely Symantec. In interviews related to the most recent release of the Symantec Internet Security Threat report, Symantec executives have said that because of the growing security threats and the increased sophistication of the bad guys, it may be time to move from the classic black list approach to security and go to a white list approach.

This means that instead of determining which programs running on someone's computer might be bad guys, future security tools would instead only let known, "good" programs run and block out all other programs.

Now the idea of white lists isn't a new one, most good security implementations involve some combination of white listing and black listing. And I do think that white listing is a good idea, when done on an individual or company basis (meaning that I as a person or a company choose which applications I want to let run).

But this isn't the kind of white listing that is being talked about. Instead it sure seems that Symantec is talking about managing a centralized white list of good applications and if an application isn't on it, it won't run.

And if this is Symantec's idea, then in my opinion it is a really bad one.

First of all, how would one get an application onto this list? Would it be free and easy for any developer or would there be regular fees and hurdles that would leave many open-source and small developers out in the cold?

And what about programs I myself or my company writes? Would I be able to circumvent the Symantec white list controls and easily get these to run or would I have to jump through a series of complex hoops just to run my own applications?

One other thing. Doesn't this whole idea sound an awful lot like Trusted Computing; you know, that great thing where Microsoft would protect us from running bad programs and using our own computers in the way we wanted to? I don't know about you, but if I don't trust Microsoft to tell me what I can and can't do with my own computers I really don't trust Symantec to do the same.

Finally, the big weakness behind the whole white listing idea is that it doesn't really work from a security standpoint. Just because some central authority says that a certain application is safe or trusted, it doesn't mean that that application itself can't be used as an attack point by the bad guys.

A large number of security problems don't result from some rogue application getting on a system; they come about because an application already on the system has a hole in it that can be abused.

So thanks but no thanks. When it comes to making lists of what can and can't run on my system, I'm going to make the call on what goes on those lists, not some third-party security firm.

Hey, here's a new list idea for you! How about bad security ideas? Sounds like we have a candidate for the list.

For more IT related content on the blogosphere, check out www.ithub.com

TrackBack

TrackBack

http://blogs.eweek.com/cgi-bin/mte/mt-tb.cgi/11763

Comments (5)

Hal :

You need to learn more about trusted computing. It has nothing to do with what you described. TC allows software to be written that can prove its integrity and identity to remote systems, and to seal (encrypt) data so that other software can't read it. It does not stop you from running anything; but it lets you run software in a mode in which it has a degree of integrity that is impossible today. This allows that software to have a degree of trust which will enable many new applications as well as strengthening the security of existing ones. But it has nothing to do with limiting what software you run (except insofar as software can't molest a program that you allow to use the new TC features).

Jim Rapoza :

Well over the last several years I've had many in-depth meetings with Microsoft and other trusted computing backers so I think I have a pretty good idea what it is about.
You might want to read a column I wrote two years ago. In my opinion not much has changed since then.
(Read Don't Trust Trusted Computing)

Hal :

Sorry, but that eWeek article of yours seems more like FUD than analysis. You complain about Trusted Computing because of the Sony rootkit fiasco and Vista's protected video path, neither of which has anything to do with trusted computing!

Your lesson seems to be that corporations are evil, therefore trusted computing will be used for evil. But you could apply that reasoning to any new security technology. We should not use fingerprint readers because they will be used for evil, we'll have to be fingerprinted to do anything. We should not put locks on our doors because everyone will have to be locked inside their houses all the time. This is pure fantasy and there is no grounding to it.

What exactly is TC going to do that will be so evil? Are you even aware that TC has privacy-enhancing, even piracy-enhancing uses? It is a far more complex security technology than you seem to realize.

JY Gresser :

TCP, lists, malicious sw removal tool etc. a key issue is who can certify the piece of sw you get, i.e. when it comes to your computing platform. a) this is a multistage process, b)in any case you can't trust the current hw or sw providers because they only control part of the process.

alerter :


I don't think the main take-away from this article was a broad swipe against Trusted Computing.

Trusted Computing is supposed to be about solid attestation for a customer/enterprise sanctioned HW & SW configuration.

The problem that I see, everyday, is *overbearing* "anti-virus/anti-Malware" that does not do enough to allow customers/enterprises to *intelligently* and *effectively* specify what *isn't* "malware."

I won't name the offenders (the list is quite long), but the offenses are many:

1) Don't allow the customer/enterprise to "white list" anything at all. Tough luck if your security tools or other third-party software are flagged as malware.

2) Only allow the most bone-headed manual white listing of exceptions to malware detections.

Bone-headedness includes all forms of white listing based only on filename or folder name. Intelligent white lists need to be based on file location and file hash.

A sanctioned hash in the wrong folder should be blocked. A sanctioned file that does not match its hash should be blocked.

3) Place arbitrary limitations on how many customer/enterprise exclusions are allowed to
auto-magic malware detections.

4) Make malware exclusions an all-of-nothing proposition.

A-V should Continue to scan for possible infections in white listed "malware" files.

This problem is mitigated, to a certain extent, by basing malware white lists on location and hash -- but signature-based anti-virus can be many days late in detecting the latest crap that is already out in the wild. It is possible for an already "virus" infected file to be white-listed against "malware" detection; because of the de facto a-V definitions lag.

A positive "virus" detection should trump a manual "malware" exclusion.

There should also still be a separate category of "virus" detection exclusions, to handle the case of a-V false positives.

�...

When challenged about any or all of the above deficiencies in their products, too many a-V/a-M vendors come off as Holier-than-Thou GateKeepers, who always know better than the customer/enterprise and have a boat load of excuses to unload for why they don't support customer/enterprise white listing, or why their bone-headed white lists are the only way to go.

That's what makes me distrustful of any preordained "centralized white list of good applications."

Post a Comment

 
 


Advertisement
Advertisement