Brad Arkin here. In my role as the Director of Product Security and Privacy I’m responsible for the security of all Adobe products and services. In practice this means that I manage both the proactive work the Adobe Secure Software Engineering Team (ASSET) does as well as the reactive Product Security Incident Response Team (PSIRT) activities.
Back in December, Peleus Uhley kicked off this blog with the post, “We Care.” In that first post, he discussed how Adobe’s commitment to the security of our customers shows up in our process, our schedules, resourcing, and more. Since then we’ve talked publicly about Adobe’s overall approach to software security, our incident response process, and our support for more security tools for Adobe technologies. Today’s post shares some details about the software security activities underway with two of our best known and widely used products, Adobe Reader and Acrobat.
The recent JBIG2 vulnerability (CVE-2009-0658), the associated exploits, and Adobe’s response (APSB09-04) were the subject of much discussion in the security community in February and March. The JBIG2 issue also sparked a lot of conversation internally at Adobe from executives to testers and developers. What started out as a routine incident response expanded to a broader effort by Adobe Reader and Acrobat engineers, culminating in permanent changes to our software security approach for those products.
Since February, Adobe Reader and Acrobat engineers have been executing a major project focused on software security. Everything from our security team’s communications during an incident to our security update process to the code itself has been carefully reviewed. Security is an ongoing process, so while we believe our plan will eliminate or mitigate many potential security risks, we are also working to enhance our ability to respond to externally found vulnerabilities in Adobe Reader and Acrobat in the future.
In particular, we have focused this security effort in three major areas:
- Code Hardening – For the past several years all new code and features for Adobe Reader and Acrobat have been subject to our modern Secure Product Lifecycle (SPLC). The Adobe SPLC is similar to Microsoft’s Security Development Lifecycle (SDL). The Adobe SPLC integrates standard secure software activities such as threat modeling, automated and manual security code reviews, and fuzzing into the standard Adobe Product Lifecycle we follow for all projects.
The SPLC activities have been successful in mitigating threats in new code development, but did not fully address problems in the existing code base. Therefore, an initiative in the current security effort has been focused on hardening at-risk areas of the legacy code. We’ve applied the latest SPLC techniques against these prioritized sections of each application. Even in cases where no immediate vulnerability was identified, we have been strengthening input validation on a best-practice basis. (Experience shows such validation is a powerful tool in preventing as-yet unidentified security holes.)
- Incident Response Process Improvements – We’ve targeted several specific areas where we are improving our incident response process. We expect folks outside Adobe will see more timely communications regarding incidents, quicker turn-around times on patch releases, and simultaneous patches for more affected versions as we move forward.
This approach was tested sooner than we would have liked with CVE-2009-1492/1493. Although this incident fell in the middle of our security effort, we were encouraged by the progress our response demonstrated. We worked to communicate early and often via our PSIRT blog and two weeks later, on May 12, 2009, we simultaneously shipped 29 binaries to update 17 different versions of Adobe Reader and Acrobat covering 32 languages for the Windows, Mac, and UNIX platforms.
- Regular Security Updates – Starting this summer with the initial output of our security code hardening effort, we plan to release security updates for all major supported versions and platforms of Adobe Reader and Acrobat on a quarterly basis. Based on feedback from our customers, who have processes and resources geared toward Microsoft’s “Patch Tuesday” security updates, we will make Adobe’s quarterly patches available on the same days. (Although our March 10, 2009 and May 12, 2009 security patches landed on Patch Tuesday, the timing was coincidental. In both cases, we shipped the patches as soon as we finished testing them.)
Software security is a rapidly evolving field and we are always on the lookout for ways to best adapt to the changing threat landscape. In developing this new approach to product security for Adobe Reader and Acrobat we’ve leveraged lessons learned by our friends and partners in the community. We look forward to continuing the conversation in person at some upcoming security conferences.
Watch this blog for more details as work progresses.