What Microsoft can teach Apple about security response
Microsoft just released seven security updates to fix 23 vulnerabilities in Windows and other products. In February, Apple released a massive update that covered 51 vulnerabilities and also introduced an embarrassing security flaw. The contrast is striking.
Security vulnerabilities are a fact of life. Even the best-managed development processes will miss some attack vectors, leaving the software makers responsible for fixing the underlying vulnerabilities.
Speed of response is important. But equally important is how a software vendor communicates with its customers about those vulnerabilities.
This month, we have textbook examples of the right and wrong way to handle security flaws, courtesy of the two companies that together ship nearly 99% of all personal computers.
Let’s start with Microsoft.
Today is Patch Tuesday, the day Microsoft designates each month for delivery of security updates to customers.
I used to be a skeptic about the concept, but Patch Tuesday has proven itself over time. Microsoft still reserves the right to deliver an “out of band” security update in response to threats that are being actively exploited and can’t wait. But overall the system has worked well.
The level of transparency in Microsoft security bulletins is impressive. Today’s announcements included seven bulletins, each with details about the vulnerabilities it covers, the possible impact, and the urgency with which IT organizations should respond. Three of the seven bulletins are rated Critical. (ZDNet's Ryan Naraine has more details.)
Those seven updates address a total of 23 separate vulnerabilities. Bulletin MS12-030, for example, addresses seven vulnerabilities in Microsoft Excel. Bulletin MS12-034 closes nine security risks in a variety of Microsoft products, including the Microsoft .NET Framework, Silverlight, and Windows itself.
For each one of those exploits, the Microsoft Security team rates the likelihood that exploit code will be released. Six of seven bulletins this month earn a rating of "1 – Exploit code likely."
In addition, as is its custom, the Microsoft Security Response Center published a blog post today that goes into detail about the issues involved in these specific vulnerabilities. The post includes videos and deployment guidance. A separate post on the Microsoft Security Research & Defense blog addresses the technical issues involved in identifying vulnerabilities related to a patch first issued last year in response to the Duqu malware:
The Office document attack vector leveraged by the Duqu malware was addressed by MS11-087 – Duqu is no longer able to exploit that vulnerability after applying the security update. However, we wanted to be sure to address the vulnerable code wherever it appeared across the Microsoft code base. To that end, we have been working with Microsoft Research to develop a “Cloned Code Detection” system that we can run for every MSRC case to find any instance of the vulnerable code in any shipping product. This system is the one that found several of the copies of CVE-2011-3402 that we are now addressing with MS12-034.
If you are a consumer or a business user, you don’t need to know those details. You can install the updates and know that you’re protected from all the threats identified in those bulletins.
But if you’re an IT pro or a security researcher, those details are invaluable in helping you decide how to prioritize your testing and deployment plans for those updates.
Now, allow me to contrast that exhaustive security response and thorough communication strategy with the equivalent response from Apple, the developer of the world’s second most popular consumer operating system.
In February, Oracle issued a security patch to fix a critical Java vulnerability. Apple, which retains responsibility for delivering and maintaining Java SE Update 6, did not release their version of that patch until April 3, 49 days later.
During that seven-week window, more than 600,000 Apple customers were infected with malware simply by visiting a website they clicked in a list of Google search results. They did not indulge in unsafe behavior. They did not fall for social engineering or provide their administrator credentials. They did not know they had been infected, in fact. And now, by most estimates, several hundred thousand Mac owners are still infected with that malware, which contains a backdoor component that allows a remote attacker to download any software onto that Mac and to perform any action that the user can perform.
Apple, to this date, has acknowledged the existence of this malware only in a terse security bulletin, titled “About Flashback malware.” It has not explained how the malware works, nor how to remove it if one is running Mac OS X 10.5.
Another incident was less widespread but potentially more severe. Apple released update 10.7.3 to OS X Lion, its latest version, on February 1. That update addressed 51 separate vulnerabilities in OS X, of which 22 could result in “arbitrary code execution,” with one having the potential to execute arbitrary code with system privileges.
Given the sheer number of vulnerabilities fixed in that release, you’d be crazy to skip that update. But if you installed it, and you had previously encrypted your home directory using the version of FileVault included in Snow Leopard, a flaw in the update code would result in your system keeping a clear-text record of all login usernames and passwords in a file that any attacker could read with ease. The point of encryption is to prevent a thief from being able to access your data if he steals your computer. This blunder has the same effect as if you had written your PIN code on your ATM card and then had your wallet stolen.
And yet Apple remains silent. The company has not published a support document acknowledging the issue. It has not offered any advice for affected Apple customers on how to tell whether they are a victim of this bug and, if so, how they can remediate it.
More importantly, no one has explained how such a horrendous security gaffe could pass code review and make it into the public release of a crucial OS X security update. If this kind of mistake can happen, who knows how many smaller, potentially more serious mistakes might also have slipped in to what are supposed to be security updates? And what does that kind of boneheaded code mistake say about the quality of iOS?
With great fanfare, Apple hired Window Snyder more than two years ago, with the avowed goal of helping to secure the Mac ecosystem. Snyder worked for Microsoft for several years before moving to Mozilla to work on securing Firefox.
Despite that influx of talent, Apple in the past year has been hit with its two biggest malware attacks in history, and the company’s response has been weak and mostly ineffectual.
As far as I’m concerned, Apple has serious work to do to restore its customers’ confidence. That work needs to start with a competent Chief Security Officer and a commitment to communicate with its customers about security issues. And it needs to cooperate with independent security researchers and its competitors. And yes, that includes Microsoft, which has a tremendous amount of knowledge gathered over more than a decade.
Security response is a cost of doing business. With $100 billion of cash on hand, Apple could afford to attack the security problem head-on. Instead, the company seems to be sticking its head in the sand.