We spend a lot of money on external researchers helping us to improve our software. Rather than some type of bug bounty, what we've chosen to do is to look at a potential consulting engagement if someone comes forward with an idea to make our software security better. The effectiveness of the experience and skills that the researcher brings is so much higher when they are able to access the engineers who are directly working on the product and all the internal documents to help them do a full white box assessment. It's much harder to do that externally. Things are changing fast in the industry, though, so we're always paying attention to see if these other approaches [such as bug bounties] may work in our environment. Since Adobe has gone to a quarterly patch cycle for Reader and Acrobat, you've had some out-of-band updates. Is that because those applications are targeted so much?
The quarterly updates are for things where there's no urgent need to get it out any sooner. We have to balance getting protections out as soon as we can to customers with the cost of disruption to the workflows of deploying a patch. No matter how hard we work to make it an effortless process, anything multiplied by hundreds of millions of machines is going to be really expensive. This is a really tough balance for us, because we can ship a lot of patches, which will help people defend against the latest things that have been reported, but at the same time, there is a great expense in keeping those machines up to date. Talk about sandboxing and why it is needed.
When we looked at Reader and all the different ideas to make Reader more secure against this new type of threat we're seeing, we had to balance all of these ideas against the fact that there's hundreds of millions of people that use Reader in a particular way today. They don't want to have to change. So how can we make them safer and not change how they interact with the product? Sandboxing is one of the things that made it through the initial process. We've made a big investment to implement this. We started with this in the summer of 2009, and then we made the announcement that we are going to put sandboxing in the next major version of Adobe Reader. The first release is going to be write-only. The sandbox will run Reader in a low-rights process. If an attacker found a vulnerability that today might allow him or her to take over a computer, in the future he or she would be stuck in the sandbox. You're addressing Reader and Acrobat, what can you do to address Flash issues?
Flash Player is installed on a lot of machines. For a couple of years now, Flash Player has opted into Internet Explorer protected mode if you are running IE7, IE8 or later, and using Windows Vista or later. Similar to what we did for Reader, Flash Player runs in low-rights and uses a broker process if you need to do something requiring higher rights. We have a lot of other things that we're working on with Flash Player as well. In the 10.1 version that just shipped, Flash Player now hooks into the privacy mode settings for the browser. If you are doing incognito mode or privacy mode, Flash Player is able to tap into that and respect those settings. One of the announcements at Black Hat is that Adobe is joining the Microsoft Active Protections Program. Why join the program, and what does it mean for the security vendors in the program?
We've been looking for ways to get this actionable, detailed technical information out to the security vendors, so they can protect our mutual customers against these types of attacks that were possible. The feedback that we got was that the MAPP was the right way to do it. Rather than reinventing the wheel, we're working together with Microsoft so that product security information is going to get through to the participants in the MAPP program. There are 65 participants. Adobe is not becoming the 66th, but rather the second software maker that is sharing product vulnerability information. Is embracing Microsoft's software development lifecycle processes relatively new for Adobe?
Not really. Microsoft's SDL is something they have been working on for 10 years or so. The Adobe secure product lifecycle (SPLC) has its roots in the Macromedia work that was started in January 2004. So they had somewhat of a head start. Anytime Microsoft makes documents and resources available, we always look at them with great interest, and anytime there's a great idea, we'll adopt that and put it into the way we do things. How do you expect bug hunters to disclose bugs? What is Adobe's responsible disclosure policy?
Any time a researcher identifies a vulnerability in an Adobe product, we're thrilled to hear that research. You can contact us through email@example.com. We triage through that email list for anything that has any chance of having technical merit, and we try to initiate contact with the person who reported it to us. If we get the same results that the researcher saw, we work with our product team. The product team works on creating the patches, doing the testing to make sure the patches fix the vulnerability, and then the end result is eventually a security update that will ship. There is a small group of researchers that we have very sensitive relationships with and work with a lot, and then there's always someone who we may not have worked with before, but we may know them in the security community. Our goal is to always make sure to communicate how appreciative we are when they take the time to share this information with us, and we do everything we can to keep them up to date with what's happening.
Dig Deeper on Securing Productivity Applications