Most people tend to agree with the old adage: Knowledge is power. But there are some groups that think knowledge is a bad thing—knowledge on the part of others, at least—and these groups work hard to keep people in a state of blissful ignorance.
Many software makers actively try to keep data under wraps—information about vulnerabilities or security holes that they are unwilling or unable to fix. But its just these software vendors that would benefit most from the spread of this kind of information.
I can understand why some companies dont want negative information to get out. After profits, most modern corporations are heavily driven by marketing and public relations. And what could be worse news for a software company than a security hole in one of its products?
But any vendor that gives in to this kind of thinking is bowing to the people who know the least about software and IT. The companys developers and customers, on the other hand, know that it is pretty much impossible to build a software program that wont occasionally have bugs or security holes.
A constant barrage of problems is another story, but customers understand that occasional problems with software are a fact of life. The most important thing to customers is not vulnerability-free software but software that is vulnerable for as little time as possible. Customers also want to know about problems so they can take steps to protect themselves until the problems are fixed.
But some vendors think that security by obscurity is the best way to go, and theyll fight tooth and nail against anyone who prevents them from hiding their security foibles.
The latest round in this battle, early last month, took a chilling turn in a French court decision. The court ruled that a security researcher broke the law by publishing details about a vulnerability in a French security application. The court also ruled that the researcher could no longer disclose security vulnerabilities.
What many people wont hear about is that this researcher may not have obtained the security software legally, which almost certainly affected the ruling. Most people will instead see only the headlines, such as “Researchers who discover programming flaws can no longer legally publish their findings in France” or “Publishing exploit code ruled illegal in France.”
Bottom line: The ability for researchers to expose vulnerabilities that vendors would rather keep hidden will be further limited simply out of fear and uncertainty.
Part of the problem is that not all security researchers are paragons of white-hat purity. But most security researchers are simply trying to find out if there is anything wrong with a program that they use or that clients use.
And when researchers find a problem, their first goal is to give the vendor a chance to fix the problem. If the researcher follows proper notification and if the vendor acts responsibly to repair the problem, rather than attack the researcher who found it, everyone benefits from the resulting improved product. (Security researcher Rain Forest Puppy has a good template for notification procedures at wiretrip.net/rfp/policy.html.)
If software companies fear bad PR, then legal action against researchers makes no sense whatsoever. If I see in the news that a vendor is fighting a vulnerability disclosure on one of its products, I instantly assume that the vendor cares nothing about software quality and security. And I doubt that Im alone in this thinking.
On the other hand, I respect companies that deal with problems openly and promptly or that are proactive with things such as bug bounty programs that reward researchers who find problems.
When a vendor feels genuinely wronged by a researcher, the vendor should turn the tables: Share the threatening or extortionary correspondence from the researcher with the security community and the press. That researchers clout and influence will drop like a stone.
In the end, embracing researchers and dealing with problems openly and promptly are in vendors best interest. Throughout history, totalitarian governments that restricted knowledge and resisted openness tended to rot from the inside. The same tends to happen to software vendors that try to hide problems or deceive customers.
Labs Director Jim Rapoza can be reached at firstname.lastname@example.org.