Artificial Separation in Antivirus Products
Thanks to Mark Russinovich for his article "Unearthing Root Kits" (June 2005, InstantDoc ID 46266). The article demonstrates the true dangers faced by computer users and the people who run corporate networks.
Mark mentions in the article that F-Secure has released a beta version of a tool that detects root kits. I went to the Web site and wasn't surprised to find that the product appears to be separate from F-Secure's normal antivirus software. This tells me that it will be sold separately when released.
At this point, IT professionals and computers users are faced with having to purchase and deploy software to defend against viruses, worms, and trojans. Additionally, they have to purchase separate software to defend against malware (viruses, worms, and trojans with a license), and now we will start having to purchase and deploy separate software to defend against root kit–enabled threats (viruses, worms, and trojans that hide).
This pigeonholing of the same threats according to how stealthy each is or how it gets put on the computer is nothing more than an industry trying to suck more money out of consumers who fear having their corporate network brought to a standstill or their personal data erased or stolen. The threats are real, but the antivirus vendors are creating artificial separations in their products to charge more money.
If a virus or malware is installed and hidden using root kit technology, I shouldn't have to purchase a separate product to detect and remove it. The antivirus software I pay a yearly subscription for should be detecting the threat. One wonders what things would be like right now if the antivirus vendors back in the early 1990s decided to release separate products for boot sector viruses, macro viruses, and trojans. It's time that all of the antivirus vendors start to do their job and release a product that detects and removes viruses, worms, and trojans from a computer regardless of how they got there or how well they hide. Isn't that what I've already paid for?
—Craig Matthews
fknight@fkradio.net
RAM Room to Spare
Regarding Michael Otey's"Buyer's Guide: 64-Bit Dual-Processor Servers" (June 2005, InstantDoc ID 46276), I thought that the maximum addressing power of a 64-bit bus/platform is 16 exabytes (2 to the 64th power) and not 16TB as mentioned. Of course, whether such a high limit is physically feasible with current technology is probably debatable. After all, gigabyte levels in RAM became mainstream many years after the 32-bit (4GB) platform came into being.
—Ravi Athalye
ravima@vectorconsulting.com
Although 16 exabytes might be the theoretical limitation, 16TB is the current practical limitation for the 64-bit architecture. In any event, I wouldn't consider this a pressing concern because the largest system currently available supports "only" 512GB. There's plenty of headroom.
—Michael Otey
Firefox Isn't a Security Paragon
Paul Thurrott starts off with a bold and dangerous claim in his article "Need to Know: Mozilla Firefox" (June 2005, InstantDoc ID 46291). Bold because it's patently false, dangerous because someone might actually believe him. "Mozilla Firefox . . . offers most of the advantages of Microsoft Internet Explorer (IE) with none of the security disadvantages." (Emphasis added.) Firefox isn't a panacea when it comes to security. It is software. All software has bugs and potentially allows exploits. Recent security patches released for Firefox show that Firefox is no different in this regard than any other software. Although there are valid security concerns over IE that make Firefox attractive, Firefox too carries valid concerns. Administrators should be cognizant of the fact that with Firefox, as with every other piece of software, applying patches and security updates is an inevitable part of the IT process.
—Chris Scharff
chris_scharff@messageone.com
Keep Up the Good Work
I just wanted to tell you how much I've been enjoying the magazine lately, especially the "Hey Microsoft!" and "The Business End" columns. Hope to see more of the same in the future.
—Michael Dragone
mdragone@titleserv.com
End of Article
Register
