Security group issues compromise plan for vulnerability reporting

'I don't think it's going to be anything earth-shattering in the short term,' said Scott Blake, vice president of information security for BindView Corp. of Houston and chairman of the OIS communications committee. 'We're hoping to change the environment a little bit, codifying what a lot of people are already doing.'Blake was in Las Vegas to take part in a panel discussion of the new guidelines at the Black Hat Briefings security conference. Other participants were Scott Culp, senior security strategist for Microsoft Corp.; Andre Frech, X-Force research team lead at Internet Security Systems of Atlanta; Rajiv Sinha, manager of security compliance for Oracle Corp.; Vincent Weafer, senior director of Symantec Corp. of Cupertino, Calif.; and Chris Wysopal, director of R&D for @Stake Inc. of Cambridge, Mass.The issue of vulnerability reporting has been a contentious one in security circles. Hackers assert that the only way to ensure that software makers fix problems is to publicly expose them.'Historically, they had a case,' Blake said. Many software makers fixed holes only because 'they got tired of being dinged in the press and by their customers.' Much of the progress made in software security has been a result of hacker-exposed vulnerabilities. 'But the hackers have been slow to realize we've won. It's time to stop hitting them with the stick.'Blake gave major software makers good grades for their cooperation in fixing security problems, although some vendors still resist publicly acknowledging and addressing flaws. Over the past several years a consensus has developed that makers should be given a chance to fix problems before they are exposed.A case in point is a buffer overrun in the remote procedure call interface to Windows operating systems, which was announced earlier this month, Blake said. The Polish hacking group that discovered the problem contacted Microsoft privately and allowed the company to develop a patch before making the flaw public.But that does not mean the security-hacking community is in complete agreement on the process of notification. The OIS guidelines call for a 30-day grace period beginning with the release of the remedy, during which technical details are released 'only to people and organizations that play a critical role in advancing the security of users, critical infrastructures and the Internet.'Many in the community objected to what they see as favoritism that could put some users at a disadvantage because there is no way to ensure the details will not leak.'There are some who argue that giving out any information constitutes a public release,' Blake said. 'We tried, for the most part unsuccessfully, to avoid that criticism' in the guidelines, which allow but do not require the limited release of technical details. 'A lot of our critics ignore that distinction.'Blake said it is 'probably a false idea' that information released to a select group can be kept secret, citing the handling of the recent vulnerability in Cisco's Internetworking Operating System. Cisco announced the flaw and released the patch to Tier 1 backbone operators three days before it planned to announce the flaw publicly, to give them a chance to fix their systems.'It leaked so much after the Tier 1 release that they moved up the public release date by 24 hours,' Blake said. 'They discovered that 3,000 people can't keep a secret.'A related issue that Blake feels is inadequately addressed in the guidelines is how to deal with problems in software incorporated in products from many vendors.'This is a major problem in handling vulnerability information, because it means a large prerelease community sharing complex and dangerous information,' he said. 'We have not come up with any brilliant solution to this, because I don't think there is a brilliant solution.'One issue not addressed at all is the role of government in the vulnerability reporting and response process. Government advisers have called public release of vulnerabilities irresponsible. Some indicated that government should play a role as an arbiter and disseminator of information.'We specifically excluded government from the drafting process because we wanted to limit it to the finders and the vendors,' Blake said. 'We also felt that involving the U.S. government would limit the document's international appeal.'Although 'OIS takes no position on the government's role in the process,' many companies participated in creating the guidelines in the hope of avoiding government regulation, Blake said.A possible role for government is arbitrating disputes between the finder of a flaw and the software vendor when they disagree about the process to follow.'Government parties have indicated a desire to have a role as coordinators or arbitrators,' Blake said. 'We would be happy to have anyone step into those roles, government included.'