...that's the best approach. I do feel that it is happening less and that vendors are realizing that we don't want to work against them, but with them."
Cisco contends it doesn't have any beef with Lynn's discoveries, but instead the company is unhappy about the way he went about distributing the information to the public.
"This incident violated aspects of normal protocol for dealing with security flaws," said Bob Gleicoff, CTO for Cisco's Security Technology Group. "And we are real sticklers for protocol."
But it seems that there have been several instances where Cisco has had similar problems in its dealings with researchers.
Early in 2004, Paul Watson discovered a flaw in the TCP/IP protocol that could be exploited on a number of networking products, including Cisco's routers. Watson said he initially emailed two of Cisco's engineers, who responded promptly. They were helpful and even contributed some thoughts and ideas to his research, he said.
But once the issue was identified as a serious security risk by the legal team at Cisco, the tone of the communication changed, Watson said. Cisco still wanted information from Watson, but no longer responded to his queries. Watson provided Cisco with several possible methods to correct the problem.
Frustrated by the lack of communication with Cisco, Watson decided to present his research at the CanSecWest Security Conference in April 2004. In a scenario similar to that at Black Hat, Cisco and the US Department of Homeland Security asked the conference organiser to pull the talk. The request was denied.
The impending talk spurred the company into action. Fixes were released a few days before the conference. However, Cisco not only provided patches, it also patented a fix for the flaw. This raised fears that Cisco might charge for the fix, which also affected other vendors, although Cisco did not.
"I was shocked," Watson said in an e-mail. "It really broke my trust in them." Cisco, like other software makers, wants security researchers to report flaws privately and have time to patch before disclosure, but Cisco took advantage of this period to apply for a patent, he said.
Playing it smart
A similar situation played out about a year later. Cisco tried to patent a fix to a flaw in ICMP that was discovered by Fernando Gont. The researcher outsmarted Cisco by documenting his discovery and the fix, and also by sharing the information privately with the open source community and the Internet Engineering Task Force, a standards organization.
Mary Ann Davidson, chief security officer at Oracle, sees...
For more, click here...
Talkback
Vendors shouldn't lay down security related disclosure rules. Period.
When a researcher finds a flaw he/she should post it in full on a special members only disclosure list and 30 days after the same information should be posted on a public list by someone else. End of story.
That should motivate vendors and researchers alike to be very carefull as to what they publish (or sell on the markets). As well as making sure that they follow up with all required resources.
Don't like? Then make sure that, 1, you don't get posted or, 2, that if you get posted you can fix things within 30 days.
Nothing is perfect. We all know that. So make sure that you're prepared to handle inperfections in a timely matter. In fact, that aspect should have been part of the general design.
The only two constants in IT are: damage and change. So master that. The rest will be part of history sooner or later.
There's plenty of blame to go around.
The software makers are responsible for preventing and repairing issues with the software. This means they should keep any foreseeable holes out of there software and QUICKLY remove any that turn up despite their efforts to prevent them. Those that don't are the blame for making an insecure product; no more, no less.
The press and IT/security professionals are responsible for informing the software makers and computer users of any problems in such a way that does not compound the issue. Those that don't are the blame for reenforcing the problem by preventing appropriate communication.
The IT/security professionals and end users are responsible of understanding and applying the appropriate patches to already installed version of the software. Those that don't are the blame for leaving the issue in play.
The malicious hacker, are also the blame for exploiting these problems and actually aggravating them.