Security Management Strategies for the CIO
Requires Free Membership to View
|  | ||||||||||||||||
| |||||||||||||||||
Stanley represents the often overlooked voice in vulnerability disclosure debates -- the customer. Too often these debates are viewed only from the researcher or vendor perspective, but a panel discussion at RSA Conference 2010 today brought in Stanley, a big Microsoft and Adobe customer, and put him on the same dais. Stanley wasted little time making his displeasure known; he was quick to toss cold water on some opening remarks from Metasploit creator HD Moore on the exposure timeframe from the discovery of a bug to when a patch is released, as well as some points from Microsoft senior security strategist Katie Moussouris on the importance of constant communication between vendors and researchers.
"I love the love-fest between the vendors and researchers, but quite honestly, I don't give a hoot," Stanley said. "I'm the consumer, the guy who paid for the product that I expect to be correct in the first place. I'm perturbed with the relationships going on. Microsoft knows about a bug, the researchers know about a bug, but I'm the guy who paid for the software. When am I gonna know?"
"The issue becomes a matter where the people paying for the product need to be better represented in this process," Stanley said.
 |
||||
|
|
|||
|
||||
Moore, for example, called responsible vulnerability disclosure a misnomer -- a vendor creation. As a researcher reporting bugs to a vendor, he said he's at the vendor's mercy. Because the vendor controls the patch cycle, he said, the vendor determines when his work becomes public.. "If you have evidence that something is being exploited in the wild and a vendor has not patched it," Moore added, "at that point is the vendor irresponsible or you for not reporting?"
Brad Arkin, director of product security and privacy for Adobe, said that bugs reported from outside the company on its ubiquitous Flash and Reader products are given higher priority. Arkin said his teams first try to reproduce the problem and then measure its risk to users based on the level of detail publicly available.
"If it comes in with full details made public, it will get patched quicker," Arkin said. "We do things to get the vulnerability window narrowed, but at a greater expense. We're then slower fixing other bugs."
|
||||
|
|
|||
|
||||
"When a researcher reports a vulnerability, it's not the full body of work our resources are dedicated to fixing," she said. "For example, if a critical vulnerability is found outside Microsoft, it may be harder to exploit than something we know about internally that's higher in the queue. Vendors need to communicate that to researchers to say we're working on your issue, but we've found some testing regression or variants, and we've got other things in the queue earlier."
Microsoft's Security Development Lifecycle (SDL) has become an industry standard in many ways for the introduction of security into software design and testing efforts. Windows security has tightened in successive iterations of the operating system, and its scheduled patch releases have simplified planning for IT shops worldwide. It's a far cry from the days when Microsoft would release security updates as they were available, essentially outsourcing QA testing to its customers, as Moussouris said.
"Some updates were issued over and over because they broke common installed environments," Moussouris said, looking at Stanley. "You don't care about resource allocation pain points we may have, but I would wager that you do care about the stability of your systems."
Join the conversationComment
Share
Comments
Results
Contribute to the conversation