Over the past few weeks we've seen significant developments, both positive and negative, in how Apple approaches security. On the negative side is Apple's laggard response to providing a patch for a nine-month-old Java vulnerability that was fixed on other major platforms six months ago - and which the company finally fixed today (see "Protect Yourself from the Mac OS X Java Vulnerability," 2009-05-20, and "Apple Patches Nine-Month Old Java Vulnerabilities," 2009-06-15). On the positive side is Apple's recent decision to hire Ivan Krstic, the engineer behind the well-respected security architecture for the One Laptop Per Child (OLPC) program.
These developments seem almost contradictory, on one side failing to manage one of the most basic security issues faced by a software vendor, and on the other hiring a leading mind in engineering software security. It's clear that Apple considers security important, but that the company also struggles to execute effectively when faced with security challenges.
With the impending release of the next versions of both Mac OS X and the iPhone operating system, it seems a good time to evaluate how Apple could improve their security program. Rather than focusing on narrow issues of specific vulnerabilities or incidents, or offering mere criticism, I humbly present a few suggestions on how Apple can become a leader in consumer computing security over the long haul.
Appoint and Empower a Chief Security Officer (CSO) -- Apple currently lacks both a public face for their security efforts and a single internal executive dedicated to security. But two positions aren't necessary: a Chief Security Officer (CSO) at a major software vendor like Apple can be both external evangelist and internal security manager, so Apple should hire such a person right away.
Apple's CSO would play a number of roles, including communicating about Apple's security efforts externally, directing responses to new vulnerabilities and other security issues, coordinating internal secure development efforts, and participating in product development to ensure security is appropriately considered and integrated into new products.
None of this will work if the CSO is merely a figurehead, and this must be an executive management position with the budget, staff, and authority to get the job done. Ideally, the CSO will be a member of the inner circle of Apple executives that drives the company forward, so as to avoid the position becoming marginalized in company politics.
Adopt a Secure Software Development Program -- Software is surprisingly difficult to design and program securely. Modern software is rarely built completely from scratch, relying heavily on various frameworks, code libraries, and third-party components. Even when software is designed from the ground up, few developers focus on security or have extensive secure development training. And even when you have well-trained developers, human error ensures they will never produce a perfectly secure product.
In response to these challenges, some software vendors have adopted special security development programs and processes (often called "secure software development" or the "secure software development lifecycle"). These techniques are extremely effective at reducing the number and severity of bugs that result in security vulnerabilities, and they are slowly becoming standard practice throughout large organizations and product vendors. Security development programs usually have the added benefit of improving overall software quality and reducing the number of costly patches a vendor releases.
Based on a variety of sources, we know that Apple does not have a formal security program, and as such fails to catch vulnerabilities that would otherwise be prevented before product releases.
To address this lack, Apple should integrate secure software development into all internal development efforts. This includes programmer training, development standards, design requirements, threat modeling, code review, use of security testing tools, specialized pre-release testing, and root cause analysis for post-release bugs.
Establish a Proactive Security Response Team -- Although Apple does have dedicated security engineers, and a small product security team, there is no public security response team to manage externally reported vulnerabilities or other security issues in a consistent and coherent fashion. Based on public handling of certain security issues it appears that the current product security team lacks sufficient resources or influence to effectively manage all Apple security issues in a consistent and coherent fashion.
An enhanced Apple security response team would manage communications with external researchers reporting vulnerabilities and the internal developers that develop the fixes. Since Apple relies so much on third-party software, much of it open source, the security response team would also track and coordinate security responses for these products. This could enable Apple to manage security issues like the recent Java and DNS flaws proactively, so Apple users are no longer exposed even after these components have been fixed by their programmers.
Having spent years working with both researchers and vendors, I've learned that a communicative security response team typically generates goodwill with researchers reporting bugs, and is more likely to avoid messy disclosure situations that place users at risk.
Manage Vulnerabilities in Included Third-party Software -- As I've mentioned multiple times, one of Apple's most significant security problems lies with patching versions of third-party software (much of it open source) included in Apple products. Apple has a history of patching these components long after fixes are released on other platforms (examples include Java, Samba, Apache, and DNS, and even Apple's own open-source WebKit and mDNS).
This is more than merely a roadmap for an attacker, it's an unimpeded highway straight to your Mac. For example, the world's most popular free penetration testing (hacking) tool, Metasploit, can now target Mac OS X specifically, and functional attacks (for any platform) are typically available for Metasploit only hours or days after new patches are released.
As the barriers to exploiting new vulnerabilities continue to drop, Apple absolutely can't afford to leave its customers exposed. The solution to this is a formal program to track vulnerabilities reported in third-party components, and to work with internal development teams to integrate fixes as they become available. Apple's CSO and security response team would become responsible for actively engaging with these external developers, and for ensuring Apple is able to release fixes in a timely manner.
Complete the Implementation of Anti-Exploitation Technologies -- With the release of Mac OS X 10.5 Leopard, Apple began to include a collection of what are known as "anti-exploitation technologies." Even if Apple adopts all of my suggestions above, that still won't eliminate all security vulnerabilities in our systems. Heck, even if all Apple software is perfectly secure, we'll still see vulnerabilities in the non-Apple software we purchase for our Macs and iPhones.
Anti-exploitation technologies assume that vulnerabilities are inevitable, and try to prevent attackers from taking advantage of them to hurt our systems. Sandboxing, library randomization, no-execute flags (which tie to special hardware hooks inside our Intel-based Macs), and stack protection are all partially implemented in Mac OS X, but these implementations are either incomplete or flawed in ways that nearly eliminate their security advantages.
As Microsoft is learning, it's also important to enforce these controls in individual applications, not just the operating system, so a single Web browser plug-in like Flash or Java can't circumvent anti-exploitation technologies. Apple is in a stronger position to enforce these rules than Microsoft, thus better protecting Mac and iPhone users. Rumor is we may see some of these advances in the upcoming Snow Leopard release of Mac OS X, which would be a positive development.
It's inarguable that using Apple products today is currently a relatively safe experience, but there are early signs that if Apple doesn't start to do a better job with security policies and architecture, we customers may be at greater risk down the road. I didn't write this article because I'm worried about the security of all seven of my Macs this week, but because I'd like to continue to enjoy safe computing for the foreseeable future. By following these suggestions Apple could extend its current (if not entirely deserved) reputation for security to become a long-term leader in consumer computing security.