|
Software vendors and vulnerability policies
Software vendors and vulnerability policies
<p>It is pretty much an accepted fact that vulnerabilities are everywhere these days. They can affect every piece of software available, whether it is from major vendors (Microsoft, Cisco, etc.) or if it has been written by hobbyist programmers (those building a Web app, for example). These vulnerabilities can surface on the public landscape in a wide range of situations; from zero-day attacks, all the way over to the other side of the spectrum with responsible disclosure. However, the responsibility does not rest solely on the shoulders of the vulnerability researchers—vendors should (and do, in most cases) have an obligation to be responsible as well. The bottom line is, software vendors should hold some responsibility for their customer’s computer security. If a vendor’s software somehow threatens a user’s security by containing a vulnerability, the vendor should take responsibility for it and do what they can to protect the user.</p>
<p>In light of this, I believe that Apple Computer’s actions surrounding the potential vulnerability in Apple’s wireless security technology that was exposed by Johnny Cache and David Maynor (at Black Hat in August) could be brought into question. Following the presentation, Apple declined to directly acknowledge the potential vulnerability. Their public announcements seemed to only focus on <a href="http://www.macworld.com/news/2006/08/17/wirelesshack/index.php">debunking the research</a>. They didn’t release an advisory, or any sort of public notification that outlined advice on safe wireless use while they attempted to verify and fix, if necessary, the potential vulnerability. Additionally, they didn’t announce that they would start their own research and notify their users of problems if and when they were found. Apple’s actions made it seem that they believed that their product was not flawed; therefore, they may have put their users at potential risk—if indeed their wireless software did contain a security flaw.</p>
<p>As a consequence, Apple’s response prompted a number of technically unqualified bloggers within the Apple “community” to attack the Black Hat researchers with impunity. The number of articles and blogs that condemned the researchers out of hand was quite astounding. It was astounding, not only because of their zeal, but also because of the context of computer security in this day and age. After such major events as Code Red and Slammer (to name but two), we should all realize that highly critical vulnerabilities are common and deserve proper attention! This is compounded by the fact that Apple has released a steady flow of responsible security fixes over the last few years on a regular basis. In this context, I wish that Apple’s reaction had been more appreciative and inquisitive, instead of how it came across: apparently trying to sweep a potentially critical issue “under the carpet.”</p>
<p>Even more surprising is the fact that Apple released multiple security patches for their wireless technology shortly after the Black Hat presentation. Apple still seemed unwilling to acknowledge any suggestion that the security patches were related to Cache and Maynor’s presentation; however, they did admit that the vulnerabilities were found after an internal audit was launched, <em>because</em> of Cache and Maynor’s presentation. So, albeit indirectly, I think Maynor and Cache should be credited with those findings. Also, Apple is now working directly with Maynor’s company (SecureWorks) and although the nature of that relationship is currently undisclosed, it will likely expose more vulnerabilities. However, Apple still denies that there may be a critical vulnerability in their software, which I think continues to put their users in a potential risky situation.</p>
<p>So, what actions should Apple (or any software vendor) take when faced with potential security risks? An advisory should be made, stating that there is a possibility of a critical vulnerability. Tips for users on safe computing habits (specifically designed to defend against the potential vulnerability) should be posted until further information becomes available, and then updated with any new remediation advice once that information is compiled. The vendor should also publicly initiate an internal audit and invite any researchers along that could make a positive contribution. In a case such as this, upon finding a vulnerability it should be disclosed publicly and the vendor can shortly follow up with a patch. I believe that is the responsible route to take. I can only hope that going forward, Apple, as well as all software vendors will learn from this and continue to move away from denial and towards acceptance, followed by swift remediation. Ultimately, vendors will become more confident in taking responsibility for their vulnerable code when the need arises.</p>
http://www.symantec.com/enterprise/security_response/weblog/2006/10/software_vendors_and_vulnerabi.html
http://www.symantec.com/enterprise/security_response/weblog/2006/10/software_vendors_and_vulnerabi.html
Fri, 27 Oct 2006 07:00:00 -0800
|