On Mar 5, 2007, at 9:30 PM, Gary McGraw wrote:
I think some vendors have come around to the economics argument. In every case, those vendors with extreme reputation exposure have attempted to move past penetrate and patch. Microsoft, for one, is trying hard, but (to use my broken leg analogy) they had a sever case of osteoporosis and must take lots of calcium to build up bone mass. The financial vertical, led by the credit card consortiums is likewise making good progress. Other vendors with less brand exposure (or outright apathy from users) are slower on the uptake.
Having spent several years on the incident handling side of this argument at CMU's CERT/CC, US. Dept. of Defense, etc., I thought I'd chime in here as well. It's encouraging to me to see that many vendors now recognize the reputation exposure and economics argument. I know that in my years at CERT (1989-1993), we were more than once threatened by uncooperative vendors, saying that they would sue us if we published information about their product's vulnerabilities. We spent years developing those vendor relationships and building up some level of mutual trust. It's not always an easy path.
In the "full disclosure" years, it's been my observation that many vendors get forced into publishing patches when the "vulnerability pimps" (as Marcus calls them) call them out in public. Without a doubt, that's lead many vendors to respond more quickly and more publicly than they otherwise might have. At the same time, (and to try to bring this thread back to *software security*) I'm concerned about the software security ramifications of being bullied into patching something too quickly. While a simple strcpy-->strncpy (or similar) src edit takes just moments, and shouldn't impact the functionality and reliability of any software, patches are rarely that simple. When software producers are forced to develop patches in unnaturally rushed situations, bigger problems (IMHO) will inevitably be introduced.
So, I applaud the public disclosure model from the standpoint of consumer advocacy. But, I'm convinced that we need to find a process that better balances the needs of the consumer against the secure software engineering needs. Some patches can't reasonably be produced in the amount of time that the "vulnerability pimps" give the vendors.
Cheers, Ken ----- Kenneth R. van Wyk SC-L Moderator KRvW Associates, LLC http://www.KRvW.com
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
