Lately, security software vendors have been reporting more of a certain kind of vulnerability -- security flaws...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
in the products of rival security software vendors.
From one perspective, this is good. Certainly, security software, since it guards all the other software, should be as secure as possible. "Users need to be aware that any software they put in their infrastructure can add risk if it isn't securely coded. Security products are no exception," said Chris Wysopal, VP of research at Cambridge, Mass.-based security consultancy @stake.
Also, if security software vendors are scrutinizing operating systems and other applications, it's understandable that they would examine security applications, too. "We need to be aware of vulnerabilities in our own products," said Chad Harrington, a security researcher at San Francisco, Calif.-based Zone Labs.
Still, learning about such reports is also uncomfortably like finding out that Car and Driver is published by, say, Mercedes Benz: You can't help but consider its motivation in scrutinizing certain products. Might there not be some desire to one-up or embarrass competitors by exposing their product vulnerabilities? "There are many security researchers looking at many security products," said Harrington, whose company was the subject of a vulnerability report by a competitor. "We don't feel it's unfair."
Firas Raouf, chief operating officer of eEye Digital Security, said, "Security products should receive the same level of scrutiny that any critical software product does. In fact, we feel that security products should be held to a higher standard."
There's no doubt that such vendor-vs.-vendor reports are increasing in number. Using the reports in the Secunia vulnerability database as a rough measure, there is a clear pattern. In all of 2003, there were only five such reports, while there are already 14 in 2004. In fact, there were four reports in February and another four in March, as well as three more in April and May.
Certain vendors seem to appear regularly in these reports -- on both sides of the scrutiny. Of these reports, for example, NGS Software was the most prolific in reporting vulnerabilities, with five reports, while @stake and eEye Digital Security tied for second with four each. The favorite targets have been McAfee, Seattle Lab and Symantec, with three reports each. Internet Security Systems reported three flaws in competitor's products, while being the subject of two itself.
It's ironic to find security flaws in security products, but, given the nature of software development by humans, it's inevitable. "Some people assume that because a product is developed by a company with security expertise that it will be designed and implemented securely. This isn't true. Security product vendors still get their developers from the same pool of engineers that work at any other software company or project," said Wysopal.
Wysopal sees this as a trend: "Security products have been overlooked in the past, as researchers have focused on operating systems and other applications." Harrington concurs, but for another reason. "Security researchers often look at the most widely deployed applications around, and security software fits that profile."
But not everyone agrees. Raouf asserts, "There is no data to support a trend."
So, how should security vendors behave when dealing with other vendors? Professionally. "Security vendors should follow the same disclosure policy for competitors' [flaws] as they do for others," suggested Wysopal.
"Everyone needs to play by the rules," said Harrington. Researchers need to notify the vendor and refrain from publishing details until a fix is available. Vendors must work to create and publish fixes in good faith. And users need to consider the reasons behind some of the reports they read.