* Disclosing vulnerabilities publicly isn’t the only way to get results
In a couple of recent columns, I have looked at the practice of trying to get companies to pay money for information about vulnerabilities and the related issue of threatening to publish vulnerabilities unless companies respond according to an imposed timetable.
Software vendors have to shoulder their share of the blame for the frustration felt by users who fruitlessly batter at their doors to get a hearing. Yes, those vendors do have priorities for using limited resources, but the frustration comes from not being listened to. From experience in technical support, I’d say that the critical elements in gaining the cooperation of users who are experiencing difficulties are:
* Paying attention to the calls for help or for repairs.
* Having a systematic method for tracking all calls and correlating problems so that you know what is causing the most trouble.
* Having a system for assigning priorities to specific fixes or repairs.
* Communicating frequently with the people who called in the trouble report.
* Involving the callers in solving the problem if possible.
The worst thing a company can do is brush off a trouble report; the next worst is to claim it will resolve the problem when in fact there is no intention to do so. Honesty is essential in all our work, and especially when dealing with clients and with the public at large.
When I was an operating-systems and performance specialist for HP in the early 1980s, it always seemed wonderful to me that HP consistently published a complete list of all the known problems it had registered for its products. The “Systems Status Bulletin” was published quarterly, with biweekly updates; it was a compendium of all the problems that had been localized in every software product the company made, with patch numbers for those that were fixed, release numbers for patches that had been integrated into installation releases, and workarounds if possible for those problems that were not yet fixed.
I recommend this honest and complete approach for all companies, especially those working with security products.
Finally, users and specialists should understand that using the threat of publishing detailed exploits – or actually publishing them – is a crude, extreme and unprofessional approach to resolving a problem. Instead, try to build pressure using a graded series of actions instead of jumping to threats:
* Define a timetable for acceptable responses that takes into account the severity of the security hole, and don’t ask for instant repairs on a minor item.
* Contact higher levels of management at the vendor firm to discuss the issue.
* Get the cooperation of upper management in your own firms, if appropriate.
* Arrange for face-to-face meetings between the top managers of your firm and those of the vendor firm.
* Contact your professional colleagues for joint letters pressing for a solution.
* Raise the issues in professional forums (Usenet, mailing lists, professional association meetings) without giving enough details in public that would allow instant exploits by the black-hat crowd.
* Set up a birds-of-a-feather group at an upcoming meeting specifically to discuss solutions and workarounds to a longstanding or fundamental design problem.
* Look for alternative suppliers – and make sure that you do so openly by telling your supplier you are not satisfied with its product quality or its service.
* Contact certifying bodies to withdraw certification of products that remain unrepaired for a long time after notification.
* Get your corporate counsel involved to discuss possible legal action for breach of contract if possible.
* Publish information about the problem, again without giving away so much detail that you make the problem worse than it already is. The last thing you want is to give some twisted 10-year-old script kiddie (or a 20-year-old with the same level of moral development as a 10-year-old) a prefabricated attack script.
In summary, I think that a sound approach to preventing extortion in our business involves making it unnecessary. We should establish norms for professional, collaborative responses to reports of vulnerabilities. The other powerful tool we can use is peer pressure: let’s establish a consensus about not trying to extort compliance with our own priorities when we run into trouble with software and systems. But in any case, demanding money to avoid publication of a vulnerability is just plain sleazy.
In the world of information security, we need people who are the equivalent of blood donors, not blood suckers.
