ASSET

Flash content and the same-origin policy

2009-11-14T00:37:02Z

Peleus here. Research was recently published that makes several claims regarding Flash content on sites that allow end-user uploads that I would like to address. The topic raised is not news; it's something that has been understood and discussed by the security community for years. Most importantly, this is not a vulnerability in Adobe Flash Player. Web servers that choose to accept user-uploaded content also choose to accept the risks that go along with that functionality. Flash Player's behavior is consistent with other web technologies and the web browser security model. Several web technologies pose the same risk to servers that allow end-user uploads.

To really understand the issue, we need to take a step back and understand the same-origin policy. This policy basically states that two pieces of content hosted on the same domain and loaded by the same protocol trust each other. Conversely, two pieces of content hosted on different domains do not trust each other and cannot interact. The same-origin policy is enforced by the web browser, and all web content must follow it.

The researchers noticed that there are many web applications that allow end-users to upload their own content to the same domain as the web application itself. According to the same-origin policy, this means that the web application trusts the end-user's content in the same way that it trusts its own content. In most real world scenarios, this is not true. The web application does not trust end-user content and does not mean to grant end-user content any privileges on its domain. Quoting Law #4 of Microsoft's 10 Immutable Laws of Security, "If you allow a bad guy to upload programs to your web site, it's not your web site anymore." Microsoft originally published these laws in 2000 and TechNet Magazine revisited them in 2008 where they concluded, "Law 4, at least in spirit, still holds--in spite of some sites that are designed to permit people, bad and good, to upload programs to them."

When Flash content (SWF), as well as any other web content, is hosted on the same domain as the surrounding HTML, the same-origin policy defines a trust relationship between the two. Proposals have been made to have Flash content assume there is never any trust and therefore ask permission for each and every request that it makes. This would break all legitimate deployments of Flash content on the web and require all administrators to change their configurations in order to start supporting Flash again. It also would not solve the problem. Flash content is not the only content-type that can execute JavaScript when clicked on by a user. Law #4 still holds. The fundamental problem is that the site is not properly handling the upload of arbitrary active content. Attackers can still attempt to upload other forms of server-side or client-side code in an effort to exploit the server.

The web has already widely deployed much better solutions. Sites solve the problem by hosting untrusted content on a different domain. If a site developer wants to host arbitrary uploaded content on a site and does not want SWF content to execute on their site, the SWF can be served with headers, which instruct Flash Player to treat the file as an attachment. Flash Player will acknowledge that request and present an Open/Save/Cancel dialogue to the user rather than render the content. Developers may also choose to limit uploads to only the types of content that they plan to support. These steps to properly managing user-generated active content uploads may be challenging, but good web security requires vigilance against this type of risk alongside all the other familiar web threats like CSS, CSRF, ...

We understand that developers have many challenges when managing rich content, and we are working with the industry in discussing and supporting solutions (such as Content-Security Policies) to minimize the risks and educate the community. Our goal is to enable all of our customers (end-users, developers, and web site owners) with solutions that will protect them from the critical risks they face.

Securely deploying cross-domain policy files

2009-11-11T02:30:51Z

Peleus here. There has been a recent focus on cross-domain policy deployments in the media, so I thought this would be a good time to remind people of some best practices. Cross-domain security was a focus of my recent presentation at the Microsoft BlueHat conference. I have also covered this topic within my Creating More Secure SWF Web Applications article. With more plugin platforms adopting the format and similar controls being added to HTML5, it is becoming increasingly important to ensure the correct deployment of a cross-domain architecture. Here are five best practices that should be followed to ensure a secure deployment.

1. Avoid full wildcard permissions (domain="*", headers="*", to-ports="*"). There are only a small number of legitimate use cases for full wildcard (*) permissions. If granting full permission is absolutely necessary, then the best practice is to create a sub-domain on your site whose explicit purpose is to serve cross-domain data. Another option is to leverage Flash Player's support of per-directory cross-domain permissions and place the data and the full wildcard cross-domain policy within a sub-directory of the site dedicated for that purpose. Full wildcards on internal networks can also be dangerous since they can result in external content being granted access to internal resources. A full wildcard should also never applied to the headers attribute of the allow-http-request-headers-from element or the to-ports attribute of the allow-access-from element in production. Once a wildcard permission has been deployed, it can be very challenging to restrict permissions at a later date because there is no easy way to identify what content depends on that permission.

2. Don't use sub-domain wildcards (*.example.org) with domains that allow user-uploaded content. This issue has grown as an increasing number of sites on the web support hosting user generated content. Quoting Microsoft's 10 Immutable Laws of Security, "Law #4: If you allow a bad guy to upload programs to your website, it's not your website any more." Therefore, if you are granting cross-domain permission to *.example.org and upload.example.org hosts end-user content, then you are not trusting just example.org. You are also trusting all the users who are permitted to upload content to upload.example.org. An attacker can upload a malicious SWF to upload.example.org, use the *.example.org permission to retrieve sensitive data from your site and then pass that data back to the attacker's web site.

3. Avoid cross-domain permissions on sites that require authentication. Any data that requires authentication for access probably should not be available to third-party domains. Flash Player does not provide access to the header of an HTTP response. Therefore developers may assume that SWF content cannot gain access to the session information stored within the cookie headers. However, some architectures will add the session information as a parameter onto the end of a URL contained within the response body where an attacker can gain access to it. Once an attacker has access to the session information of the victim, they can impersonate that user.

4. Cross-domain policies require periodic maintenance. Your web site will grow and change over time and you will need to reevaluate the cross-domain permissions with respect those changes. If you are granting permissions to domains outside of your control, then keep in contact with that party to ensure that the permissions are still necessary and that they are still used within the same context. You can limit your risk by periodically removing excess permissions.

5. Cross-domain permissions are not the only method for sharing data between domains. Rather than using the client to bridge two domains, consider using server-side code to make the cross-domain request via a server-to-server channel. Server-side code can enforce stricter controls on the request and act as a proxy between the client and the second domain. This has the trade-off of increasing traffic to the server but may allow for a more controlled channel. Be sure to consider all of your options before determining the best solution.

Cross-domain policies are a part of the code that makes up your web application. Like any other code, they require periodic maintenance and review to ensure security. Cross-domain policies should follow the same principle of least privilege that you apply to code. Only the minimum permissions required for the architecture should be enabled. The best architectures are simple and straightforward. Creating a sub-domain whose explicit purpose is to host cross-domain content can prevent unintentional disclosure. Overall, approach cross-domain policies as you would any other code. Following these best practices can help you secure your cross-domain deployment.

For further information and best practice guidance, please see:

Cross-domain policy file specification: Describes the structure of the cross-domain policy file.
Cross-domain policy file usage recommendations for Flash Player: This article discusses some of the common security issues that you should consider when deciding how to use a cross-domain policy file on your server.
Flash Player 10 Security: This white paper provides a broad overview of the Flash Player security model including cross-domain policies.
Understanding the Flash Player Security Model: A video of Deneb Meketa's presentation from MAX 2008 which discusses cross-domain security.
Creating more secure SWF web applications : A Developer Center article on how to secure SWF content including cross-domain policies.
ActionScript Developer's Guide: This is the cross-domain policy section from the Flash CS4 Professional documentation.

AppSec DC

2009-11-11T00:47:40Z

Hello, my name is Kyle Randolph and I'm a Senior Security Researcher and the Technical Lead of the ASSET team. I will be attending OWASP AppSec DC this week as part of our security community outreach effects. If you are a security researcher or an Adobe customer who's attending the conference and interested in discussing Adobe security, please shoot me an email (krand at adobe dot com). Looking forward to discussing application security with other folks in the security community this week!

BlueHat

2009-10-19T20:28:12Z

Peleus here. As part of Adobe's Secure Product Life Cycle (SPLC) efforts, we are always looking ahead to determine the future of the threat landscape. My particular focus is researching threats to Adobe's Flash Platform products. This week, I will be co-presenting with Jesse Collins from Microsoft's Silverlight team at the Microsoft BlueHat conference. We will be combining our research so that we can create a more holistic view of the RIA threat landscape. This cooperation is complimentary to what David Lenoe and Jeremy Dallman discussed on the Microsoft SDL blog detailing how Adobe and Microsoft are working together to protect our customers.

As part of the lead up to the presentation, I posted a blog describing some of my research on cross-domain threats. During the conference, I will expand upon this research detailing how improperly combining different types and classifications of cross-domain permissions can lead to increased security risk. The research has already caught the attention of Bryan Sullivan of Microsoft's SDL team who assists in the development of Microsoft's cross-domain SDL requirements. I plan to meet up with Bryan at the conference to share ideas on advancing the cross-domain SDL.

One of the advantages of collaborating with the Microsoft Silverlight team is that it allows us to see the overall threat landscape from two different perspectives. A more accurate view increases the ability for all vendors to better protect our customers. The talk will also cover the commonalities and subtle differences between different RIA technologies. Demonstrating the commonalities between platforms makes it easier to communicate risks to developers who may be implementing a mix of technologies. Overall, this has been an interesting process and we will post additional information after the conference.

Adobe joins SAFECode

2009-09-29T15:25:23Z

We're happy to announce that Adobe has joined SAFECode (Software Assurance Forum for Excellence in Code), a non-profit organization focused on the advancement of effective software assurance methods. We're looking forward to sharing information on our software security process, learning from other SAFECode members, and helping to drive industry-wide software security initiatives. More information can be found here, and a Q&A with Adobe's Brad Arkin can be found on the SAFECode blog here.

Brad's BigFix Interview

2009-09-23T00:23:47Z

The first part of Brad Arkin's multi-part podcast interview with BigFix CTO Amrit Williams is now available. In his role as director of security and privacy, Brad guides Adobe's long term security strategy. Part 1 of the interview describes Adobe's current security focus and outreach efforts. It is a quick 9 minutes, check it out.

UPDATE: Part 2 and Part 3 are now available and complete the series. Part 2 touches on defense strategies and the internals of the PSIRT process, whereas Part 3 focuses on security during the product development cycle.

In a crisis, communication is key

2009-07-30T17:44:36Z

Peleus here. I focus most of my energy working with the Flash Player and AIR teams. The first half of the year had been fairly uneventful for Flash Player with only a small number of responsibly disclosed vulnerabilities reported over the last few months. The break was welcome and allowed us to focus on the more strategic security tasks that we don't always blog about, but are still important parts of the Adobe Secure Product Lifecycle.

Unfortunately, nothing lasts forever and the last few weeks have been very busy for the Adobe Secure Software Engineering Team. We had to snap back into action on July 10th to handle the first of two different externally reported vulnerabilities that we ended up patching in Flash Player on July 30th. First, Microsoft notified us of a flaw in their ATL library that had the potential to affect many of Adobe's products. The entire ASSET team mobilized to quickly identify which of Adobe's over 200 products might be vulnerable. Fortunately for us, the MSVR team at Microsoft was well organized. They were able to share info early on that helped to speed the triage effort inside Adobe. We were able to identify and fix two vulnerable products (Shockwave and Flash Player) and confirm that many other widely distributed products like Adobe Reader and Connect Pro were NOT vulnerable. We also provided continual feedback into the Microsoft process that they could then, in turn, share with other partners.

Once the triage process for the ATL vulnerability was well under way we received a sample of a new attack in the wild against the Flash Player library within Reader. Although there are reports Adobe had known about this bug for eight months, the reality is that the July 16th report to the Product Security Incident Response Team (PSIRT) was the first time Adobe evaluated the bug as a security issue. The 12/31/08 bug was not caught as a security bug, so our usual Incident Response process was never initiated.

Flash is at the core of many of Adobe's flagship products and this simultaneous patch effort required coordination between Reader, Flash Player and the AIR development teams. This is no small task when you consider that we need to distribute reliable patches to over 90% of the Internet and support multiple versions of each product across multiple versions of the Windows, Macintosh and UNIX operating systems. Granted, we have been doing this for some time so we have automation in place to make the technical processes efficient and accurate. However, we still needed the Flash team to coordinate the creation of the patch and provide guidance to the Reader and AIR teams on adopting the solution. One mis-step in coordination could mean that the testing process starts all over again for each of the products resulting in a delay in the patch for our customers.

Since some of these products are among the most widely distributed software on Earth we used every available resource to get software updates out as soon as we could. We managed to execute a plan for updating Shockwave, Flash Player, AIR, Adobe Reader and Acrobat, all before the end of the month.

In addition to the tremendous amount of internal coordination required, PSIRT also managed the external aspects of the Adobe response. This included communicating with CERTs and other partners in the security ecosystem, creating CVE's, issuing bulletins and advisories, and responding to customers and media inquiries. Each notification requires attention to detail so that we provide useful information, but not so much that we put more customers at risk. As with all major incidents, PSIRT is at the center of balancing the needs of Adobe's customers, security researchers, product teams, partners and Adobe as a whole.

I recently read a ZDNet Zero Day blog by George Stathakopoulos talking about coordination within the security community and it's a common theme in my conversations with friends in the security community. Our coordination with Microsoft on the ATL header vulnerability was definitely key to being ready in time for their release date. In addition, coordination within Adobe was critical to shipping four products within the same week, all while balancing the needs of both external and internal stakeholders. We hosted daily security meetings that leveraged Adobe Connect Pro as a 24/7 virtual war room where we could post the latest information, record IM conversations and track issues. We used Buzzword for collaborative authoring our PSIRT blog posts, Advisories, and Bulletins that are key to communicating our progress with customers and the security ecosystem. Overall, situations like these highlight the need for security professionals to truly be a community. With all the technological solutions and formal processes we have at our disposal for creating secure products, we sometimes forget how important the little things like communication are to security.

Co-authored blog with Microsoft

2009-06-17T18:01:12Z

We co-authored a blog post with Jeremy Dallman from Microsoft describing the collaboration between the security teams at both companies. Check it out here:
http://blogs.msdn.com/sdl/archive/2009/06/17/microsoft-adobe-protecting-our-customers-together.aspx

Adobe Reader and Acrobat Security Initiative

2009-05-20T19:59:21Z

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.

Brad’s Reality Check Interview

2009-04-03T20:15:05Z

Our own Director of Product Security and Privacy, Brad Arkin, was recently interviewed by Gary McGraw in Cigital’s Reality Check Podcast series. From our Secure Product Livecycle to training and certification, the conversation touches on various aspects of software security and provides an overview of ASSET’s strategies to continuously enhance the security of Adobe’s products. Check it out!

Investing in the community

2009-03-26T23:23:13Z

Peleus here. Within Adobe, we do all that we can to secure our products, however, we can't do everything on our own. Cooperation with the security community is essential to ensuring secure deployment of our products by our customers. Over the last year, Adobe has taken several measures to better interact with the security ecosystem including assisting groups such as OWASP, sponsoring conferences such as ShmooCon and CanSecWest, and building relationships with vendors and consultants. Our recent work with vendors to supply solutions for deploying SWF content securely is one example of these projects.

Coming out of the consulting world, I understood the challenges in analyzing a web site based on the Flash Platform. Although there were some basic tools and a handful of people with the appropriate knowledge, it was clear that more could be done. To solve this multi-faceted issue Adobe would need the assistance of the security community. From our end, we have been increasing our security documentation for developers, such as our Creating more secure SWF applications article, however, documentation can only go so far. We also needed to build alliances with vendors in the industry to help deliver the tools necessary to analyze production code.

This week, HP has stepped up to assist Flash developers by providing a free static analysis tool called SWFScan. SWFScan is able to perform static analysis on SWF content to identify common coding errors that can lead to vulnerabilities once the SWF is deployed. This allows developers to identify vulnerabilities earlier in the development cycle. Consultants who do not have access to source code can also leverage SWFScan to perform offline analysis of content by using it to decompile SWFs. SWFScan will work with ActionScript 2.0 and ActionScript 3.0 code and is free for everyone to use.

Last month, IBM launched AppScan 7.8 which can dynamically evaluate SWF content and perform penetration testing on a web site. Their tool is targeted at enterprise customers and allows users to enumerate flaws during the quality assurance phase of development. While static analysis can find many flaws, it is also important to analyze a SWF within the full context of its deployment. AppScan can monitor the SWF as it executes to identify flaws within the SWF's run-time interactions with existing content as well as server communications through protocols such as AMF.

Both tools fit together nicely by allowing for security analysis at both the implementation and quality assurance phases of development. With these tools from HP and IBM, in addition to the work that Adobe does to help secure Flash Player and improve security documentation, our customers now have a more complete solution for deploying SWF content securely.

Within ASSET, we always try to examine the security of our products from as holistic a view as possible. Therefore, Adobe will continue to work with these and other vendors in the security community to bring together solutions that will help customers safely deploy our products and allow end-users to safely interact with them.

Adobe Sponsors ShmooCon 2009

2009-02-04T01:30:22Z

Hello All! This is Dimitri writing here. I am happy to say that Adobe is sponsoring ShmooCon 2009 as part of our security community outreach efforts. We want to help the security community exchange ideas and develop secure software practices.

Senior Security Researcher Peleus Uhley and I will be roaming the conference floors and would be most interested in talking to other security researchers about the security of Adobe products. So, if you will be in Washington D.C. attending the conference at the end of this week, come say hi! I don’t bite and neither does Peleus!

Adobe PSIRT Process

2009-01-28T16:27:07Z

Following on Peleus’ ‘We Care’ post, we thought this would be a good place to give a more thorough description of Adobe’s Product Security Incident Response Team (or PSIRT) process. Much of the work ASSET does is on the proactive side, preventing software vulnerabilities before a product ships. Adobe’s PSIRT is the part of the ASSET organization that responds to security issues that are discovered by external security researchers, partners, customers and others after a product ships. Here’s a step-by-step description of our process; note that some of these steps overlap and happen in parallel:

Step 1

Adobe PSIRT receives information about security vulnerabilities through numerous channels, including (but not limited to):

Email from security researchers, partners, or customers, via our feedback web form or directly to PSIRT@adobe.com
Public posting (Bugtraq, VulnDev, etc.)
Adobe Support
Internal notification (usually from Adobe’s Engineering teams, Quality Engineering teams, or ASSET)

Adobe PSIRT responds to the person who reported the issue (let’s call them the ‘researcher’), acknowledging the report and asking for a proof-of-concept file to demonstrate the vulnerability, if applicable.
Adobe PSIRT logs the issue in the Incident Response Database for tracking purposes. An Incident ID is automatically generated at this point, and passed along to the researcher.

Step 2

Adobe PSIRT sends the report to the relevant product team's PSRT (Product Security Response Team) for verification. The product team's PSRT includes a collection of Development, Quality and Program Managers, along with Developers, Quality Engineers and Product Managers.
ASSET helps reproduce the bug and assists the product team with severity analysis. If reproducible, the product team (or ASSET, if appropriate) logs an internal Adobe bug for the issue.

Step 3

The product team investigates the issue and develops a fix, or workaround. ASSET helps to verify the fix.
Any fix will be ported to all supported versions, as well as any version(s) currently under development.

Step 4

Adobe PSIRT responds back to the researcher, informing them that the issue has been reproduced and a fix is being investigated
As soon as possible, Adobe PSIRT communicates a proposed timeline for a patch to the researcher.
Adobe encourages the responsible disclosure of vulnerabilities in our products, so the researcher is asked to keep the vulnerability confidential until a fix is available. Our goal is to keep our customers as secure as possible, so we want to keep the vulnerability information from malicious hackers.

Step 5

The product team produces patches for all supported product versions, as quickly as possible. Adobe PSIRT passes along any relevant status updates to the researcher and answers any questions they may have.
Adobe PSIRT produces a Security Bulletin draft for the issue. The Security Bulletin text is reviewed by internal Adobe stakeholders.

Step 6

Adobe PSIRT passes the patch to the researcher for verification, if possible.
Adobe PSIRT sends the Security Bulletin text to the External Security Researcher for review; the Security Bulletin includes an acknowledgment to the researcher thanking them for their help with the issue.
Adobe PSIRT works with MITRE Corporation to generate CVE identifiers for any relevant issues.

Step 7

The Security Bulletin is posted to http ://www .adobe.com /support/security/ along with the product patch(es).
Adobe PSIRT posts a link to the Security Bulletin on the PSIRT blog (http ://blogs.adobe.com /psirt /) to inform customers who have subscribed to the RSS feed. Customers are encouraged to sign up for the RSS feed by clicking on the link towards the bottom on the right side of the landing page for the most timely notification for security issues.
Adobe PSIRT coordinates a notification e-mail, sent to customers who have signed up for bulletin notification e-mails.
Customers update their product installations, and the researcher posts their own advisory, if applicable, once the patch is available for customers.

And that is how our PSIRT process works! It can be a complicated process, and we really appreciate the help of all of the security researchers who have cooperated with us, and been patient with us over the years as we fine-tune it. If you have any questions about the process (or, of course, any security vulnerabilities to report to us), please don’t hesitate to contact PSIRT@adobe.com.

We Care

2008-12-10T22:03:58Z

Recently, when speaking with a few researchers about why they did not report vulnerabilities to Adobe, we have heard a few variations of, "I didn't think Adobe would care." Those responses were disappointing to the Adobe Secure Software Engineering Team (ASSET) and it was clear that Adobe needed to do more to reach out to security community and be transparent in our efforts to protect customers. ASSET strives to improve the Secure Development Lifecycle within Adobe for all products, coordinate the Adobe Product Security Incident Response Team (PSIRT) and perform security community outreach activities. Those comments indicated that Adobe needed to do more with regards to communicating the activities of ASSET to the external community. This blog is one of the methods we will use to achieve that goal.

Adobe has taken significant proactive measures to improve the security of our products over the last few years and we plan to continue to build upon that foundation moving forward. Through this blog we hope to communicate what we have achieved and where our customers can expect us to be in the future. We will be providing specific details on the current status of our individual security programs within Adobe in upcoming posts. However, to set the scene, let's take a quick look back on the last year that led to where we are today.

First, it is very clear to Adobe that we are receiving increased attention from the security community. Adobe has been responding to this increased attention over the course of the last year by proactively investing in both internal and external security measures to further protect our customers. We have added several new people to our team including Brad Arkin who recently joined Adobe in the new role of Director of Product Security and Privacy within Adobe. For additional support internally, we have increased our efforts in disseminating security information, tools and resources to the individual product teams. One example of this effort includes our recent initiative to expand the library of online security training modules as part of a broader set of education programs for developers and quality engineering. For the external community, we have also contributed towards making more security information available to the customers who deploy our products in order to assist developers and administrators in implementing best practices with our software.

The current focus on Adobe products from the security community has also lead to an increased number of reported security issues. To that end, Adobe has become more aggressive in responding to external security incidents. One recent example was the clickjacking issue reported to us by Robert Hansen and Jeremiah Grossman. Adobe responded by implementing a cross-platform, cross-browser patch within weeks of notification. And while the complexities of the many environments our products run on can sometimes prevent us from responding as quickly to other reported issues, this specific example helped to raise the bar for what we can achieve and what we want to work towards in the future. For researchers who find issues with our products, you should know that Adobe follows industry standard responsible disclosure practices and we will give credit to all researchers who follow that process when reporting vulnerabilities.

These are just a few of the steps that Adobe and ASSET has taken to improve the security of our products and services. This blog will help describe in more detail how moving forward we plan to improve in each area of the security lifecycle. By publishing information on our security development lifecycle, we hope to convey to our customers Adobe's efforts to ensure the security of their infrastructures. In addition, it is our hope that the information we provide about the lessons we’ve learned during these processes can help to further the industry. In short, we care.

Welcome!

2008-12-10T21:53:07Z

The Adobe Secure Software Engineering Team (ASSET) is pleased to announce this new blog!

Since we care about the security and privacy of our products and we want to share our company knowledge and efforts with the security community, we are starting up this new blog. Topics may range from Adobe’s experience implementing a secure product lifecycle to new security initiatives in our products. We will most likely not dive deep into individual Adobe products here, but instead focus on more general issues. If you are interested in what Adobe is doing to improve the security of its products, read on.

For the latest information on security bulletins or advisories, please go to our PSIRT blog.