New vulnerability guide shuns government
Connecting state and local government leaders
New guidelines could provide structure to the struggle between code-makers and code-breakers. But the guidance, released last month by the Organization for Internet Safety, gives the federal government no role in reporting and responding to software vulnerabilities.
New guidelines could provide structure to the struggle between code-makers and code-breakers. But the guidance, released last month by the Organization for Internet Safety, gives the federal government no role in reporting and responding to software vulnerabilities.'We specifically excluded government from the drafting process,' said Scott Blake, chairman of the communications committee for OIS, an alliance of software vendors and security experts. 'We felt that involving the government would limit the document's international appeal.'Blake, vice president of information security at BindView Corp. of Houston, spoke last month at the Black Hat Briefings security conference in Las Vegas.The voluntary guidelines, available at www.oisafety.org, could help users balance the public's right to know about possible problems against vendors' desires to correct flaws before they become public.The guidelines call for:
- Cooperation between the discoverer of a flaw and the affected vendor
- A waiting period, typically 30 days, to let a vendor correct the flaw before publicly announcing it
- Another 30-day grace period for users to apply the fix before any release of technical details that could aid attackers.
No new ground
Blake said the rules break no new ground. 'We're hoping to change the environment a little bit'codify what a lot of people are already doing,' he said.
Government officials, who have called it irresponsible to make vulnerabilities public before patches are available, believe government should have a role as arbiter and disseminator of information.
'We are positioning ourselves to be the central point of contact,' said Marcus H. Sachs, director of the National Cyber Security Division of the Homeland Security Department's Information Analysis and Infrastructure Protection Directorate.
Sachs, speaking with reporters at the briefings, said large software vendors do cooperate with the department. DHS in its short life has released a number of alerts about vulnerabilities and potential exploits.
But some hackers argue that the only way to make software makers fix problems is to expose them immediately.
'Historically, they have had a case,' Blake said. Much of the progress in software security has come about from hacker exposures, he said, and many software makers have fixed holes only when 'they got tired of being dinged by the press and by their customers.'
Vendors are now more responsible about patching software, Blake said, 'but the hackers have been slow to realize we've won.'
He gave leading software makers good grades for cooperation, although he said some resist public acknowledgement of flaws. A consensus has developed, he said, that makers should get a chance to fix problems before exposure.
Blake cited a buffer overrun, announced last month, in the Remote Procedure Call interface of Microsoft Windows operating systems. The Polish hackers who discovered the flaw contacted Microsoft privately and gave the company time to patch it before announcing it, he said.
But there is no agreement on how the cooperation should work. The OIS guidelines' 30-day grace period recommendation suggests that technical details be released 'only to people and organizations that play a critical role in advancing the security of users, critical infrastructures and the Internet.'
Many security experts object to this because it could put users at a disadvantage while details leak out.
Blake said it is probably a false idea that information released to a select group could be kept secret for too long. He cited last month's handling of a vulnerability in Cisco Systems Inc.'s Internetwork operating system. The San Jose, Calif., company announced the flaw and released the patch to backbone operators three days before it planned to make the flaw public, so they would have time to fix their routers.
Keeping secrets
'It leaked so much after the Tier 1 release that they moved up the public release by 24 hours,' Blake said. 'They discovered that 3,000 people can't keep a secret.'
Another issue inadequately addressed by the guidelines, he said, is how to deal with problems in multiple vendors' software incorporated into products.
'This is a major problem because it means a large prerelease community sharing complex and dangerous information,' he said. 'We have not come up with any brilliant solution, because I don't think there is a brilliant solution.'
Although OIS takes no position about the government's role, many vendors are hoping the guidelines will prevent government regulation, he said.
As for possible government involvement when the finder of a flaw disagrees with the software vendor, Blake said, 'Government parties have indicated a desire to have a role as coordinator or arbitrator. We would be happy to have anyone step into those roles, government included.'
NEXT STORY: A SoBig surprise this afternoon?