Software vulnerabilities and security incidents are certainly no chicken and egg riddle: You can't have an incident...
without a software vulnerability.
Reporting software bugs/holes/flaws/vulnerabilities and the incidents that result, however, is not as cut-and-dried.
For decades, companies from the largest enterprise environment to the tiny brick-and-mortar down the street have debated the merits of full disclosure and who should know about vulnerabilities first. Should software flubs be made public? Do you go first to the vendor and wait for a patch? Do you spill the beans to the industry through CERT, NIPC, Bugtraq or any other of a number of reporting agencies, all under the guise of doing so for the greater good?
Full disclosure is complicated and the lack of a standard reporting protocol doesn't help matters, according to Giga Senior Industry Analyst Michael Rasmussen.
"There are a lot of places people publicize vulnerabilities. It would be nice if there was one common reporting facility," said Rasmussen. "The generally accepted protocol, the unwritten rule, is if a company discovers a software vulnerability, report it to the vendor and wait 30 days for the vendor to patch it and make the public announcement."
The issue resurfaced recently when Oy Online Solutions clashed with Microsoft over an Internet Explorer flaw that could allow an attacker to steal log-on IDs and passwords stored in cookies. Nine days passed without acknowledgement of the hole from Microsoft, and Oy Online decided to go public with the details. Microsoft essentially went on to "shoot the messenger," when it subsequently criticized the company for going public before a Redmond-issued patch was available.
Microsoft software has been a perennial hacker target, especially its Web server software, Internet Information Services (IIS), which was the breeding ground for Code Red, Code Red II and Nimda this summer. More bad press hit Microsoft's beleaguered security division when it announced an initiative to create a standard reporting protocol, one that asked companies reporting vulnerabilities to hold onto the details for 30 days. The initiative touched off claims from the industry that Microsoft was merely trying to protect its image through the requirement of a month-long window.
Giga's Rasmussen doesn't believe a vendor should be the central reporting repository.
"It makes no sense that a vendor should hold that position, especially a vendor that has software with security vulnerabilities," he said.
Full disclosure opponents say that a free exchange of vulnerability details only serves to arm the crackers, while proponents, like searchSecurity member David J. Bianco, say that sharing security information with other professionals is an "absolute necessity," especially when it comes to knowing if a vendor patch solves the problem.
"No one person or company can have all the information they'd need in order to successfully minimize all threats," said Bianco, an independent security professional. "We must rely on the community of professionals to provide collective expertise, especially in times of great crisis."
Another searchSecurity user, James L. Black, called non-disclosure "security by obscurity."
"If a legitimate researcher or security expert can find a vulnerability, crackers can also find it," Black said. "Secrecy about vulnerabilities only creates a false sense of security. The full disclosure movement came about due to the lackadaisical attitude exhibited by many software companies toward reported security flaws."
Bill Unruh of the University of British Columbia puts the onus squarely on the vendor.
"While obscurity can be one line of defense, it is a very weak and porous one, and must be backed up by a corporate commitment to security," Unruh said. "It is like trying to rely on paint to keep the rain out -- as we in Vancouver have discovered, that is a very bad attitude if it is the only line of defense -- rot sets in, in secret, and when it is over you have millions of dollars worth of damage, which everyone, contractors and governments, disclaim responsibility for.
"In my opinion, if a company is going to keep its OS secret -- using that secrecy as the main line of defense -- they should be liable to any security breaches which do occur due to their bad coding. Crackers and hackers are a fact of life, and any company who does not take that into account in their design and manufacture of products is negligent."
Both Bianco and Black concur that vendors should be given a reasonable amount of time to respond with a fix.
"To assume that the White Hats will always beat (the Black Hats) to the punch is naive and unrealistic," Bianco said.