Join Our Security Team at OWASP AppSec California 2016

Senior members of the Adobe corporate security team will be presenting at the upcoming OWASP AppSec California conference. This conference will be held this coming Monday through Wednesday, January 25 – 27th, in Santa Monica, CA. Adobe is a proud Premier corporate supporter of OWASP. If you are planning to attend this conference, we hope you will take the time to hear our team members in their sessions.

Leading off will be Peleus Uhley, our Lead Security Strategist. He will be presenting on “Design Approaches for Security Automation” on Tuesday, January 26, at 11:30 a.m. This presentation will discuss criteria for designing and evaluating security automation tools for your organization. Each of these tools have different goals and technologies that met their organizations needs. When it comes to your organization, how will you decide whether to build, buy, or borrow? What qualities make a good design for your environment? How do you ensure that your implementation will effectively enable teams versus creating more noise? Please  make sure to join Peleus for answers to these questions and more during his session.

Following Peleus our Director of Product Security Dave Lenoe will present on Wednesday, January 27th, at 2:00 p.m. about “10 Years of Working With the Community.” In this session Dave will talk about his over 10 years of experience working on incident response and product security sharing his perspective on the security landscape. He will also reflect on the evolution of response and application security and look at the ways that we all interact with each other now versus a decade ago. He’ll also look into the crystal ball just a bit to discuss what the future may bring.

We hope you will take the time during the conference to attend these sessions and meet our security team members.

Chris Parkerson
Senior Marketing Strategy Manager – Security

Community Collaboration Enhances Flash

With the December release of Flash Player, we introduced several new security enhancements. Just like the Flash Player mitigations we shipped earlier this year, many of these projects were the result of collaboration with the security community and our partners.

Adobe has spent the year working with Google and Microsoft on proactive mitigations. Some of the mitigations were minor tweaks to the environment: such as Google’s Project Zero helping us to add more heap randomization on Windows 7 or working with the Chrome team to tweak our use of the Pepper API for better sandboxing. There have also been a few larger scale collaborations.

For larger scale mitigations we tend to take a phased, iterative release approach. One of the advantages of this approach is that we can collect feedback to improve the design throughout implementation. Another advantage is that moving targets can increase the complexity of exploit development for attackers who depend on static environments for exploit reliability.

One example of a larger scale collaboration is our heap isolation work. This project initially started with a Project Zero code contribution to help isolate vectors. Based on the results of that release and discussions with the Microsoft research team, Adobe then expanded that code to cover ByteArrays. In last week’s release, Adobe deployed a rewrite of our memory manager to create the foundation for widespread heap isolation which we will build on, going forward. This change will limit the ability for attackers to effectively leverage use-after-free vulnerabilities for exploitation.

Another example of a larger scale mitigation this year was – with the assistance of Microsoft – our early adoption of Microsoft’s new Control Flow Guard (CFG) protection. Our first roll out of this mitigation was in late 2014 to help protect static code within Flash Player. In the first half of this year, we expanded our CFG usage to protect dynamic code generated by our Just-In-Time (JIT) compiler. In addition, Microsoft also worked with us to ensure that we could take advantage of the latest security controls for their new Edge browser.

Throughout 2015, vulnerability disclosure programs and the security community have been immensely helpful in identifying CVE’s. Approximately one-third of our reports this year were via Project Zero alone. Many of these were non-trivial as many of the reported bugs required significant manual research into the platform. With the help of the security community and partners like Microsoft and Google, Adobe has been able to introduce important new exploit mitigations into Flash Player and we are excited about what we are queuing up for next year’s improvements. Thank you to everyone who has contributed along the way.

Peleus Uhley
Principal Scientist

Better Security Through Automation

Automation Strategies

“Automate all the things!” is a popular meme in the cloud community. Many of today’s talks at security conferences discuss the latest, sophisticated automation tool developed by a particular organization. However, adding “automation” to a project does not magically make things better by itself. Any idea can be automated; including the bad ones. For instance, delivering false positives “at scale” is not going to help your teams. This blog will discuss some of the projects that we are currently working on and the reasoning behind their goals.

Computer science has been focused on automation since its inception. The advent of the cloud only frees our ideas from being resource bound by hardware. However, that doesn’t necessarily mean that automation must take up 100 scalable machines. Sometimes simple automation projects can have large impacts. Within Adobe, we have several types of automation projects underway to help us with security. The goals range from business-level dashboards and compliance projects to low level security testing projects.

 

Defining goals

One large project that we are currently building is a security automation framework focused on security assertions. When you run a traditional web security scanner against a site, it will try to tell you everything about everything on the site. In order to do that effectively, you have to do a lot of pre-configuration (authentication, excluded directories, etc.). Working with Mohit Kalra, the Sr, Security Manager for the ASSET security team, we experimented with the idea of security assertions. Basically, could a scanner answer one true/false question about the site with a high degree of accuracy? Then we would ask that one simple question across all of our properties in order to get a meaningful measurement.

For instance, let’s compare the following two possible automation goals for combating XSS:

(a) Traditional automation: Give me the location of every XSS vulnerability for this site.

(b) Security assertion: Does the site return a Content Security Policy (CSP) header?

A web application testing tool like ZAP can be used to automate either goal. Both of these tests can be conducted across all of your properties for testing at scale. Which goal you choose will decide the direction of your project:

Effort to implement:

(a) Potentially requires effort towards tuning and configuration with a robust scanner in order to get solid results. There is a potential risk to the tested environment (excessive DB entries, high traffic, etc.)

(b) A straight forward measurement with a simple scanner or script. There is a low risk to the tested environment.

Summarizing the result for management:

(a) This approach provides a complex measurement of risk that can involve several variables (reflected vs. persistent, potential value of the site, cookie strategy, etc.). The risk that is measured is a point-in-time assessment since new XSS bugs might be introduced later with new code.

(b) This approach provides a simple measurement of best practice adoption across the organization. A risk measurement can be inferred but it is not absolute. If CSP adoption is already high, then more fine grained tests targeting individual rules will be necessary. However, if CSP adoption is still in the early stages, then just measuring who has started the adoption process can be useful.

Developer interpretation of the result:

(a) Development teams will think in terms of immediate bugs filed.

(b) Development teams will focus on the long term goal of defining a basic CSP.

Both (a) and (b) have merits depending on the needs of the organization. The traditional strategy (a) can give you very specific data about how prevalent XSS bugs are across the organization. However, tuning the tools to effectively find and report all that data is a significant time investment. The security assertion strategy (b) focuses more on long term XSS mitigations by measuring CSP adoption within the organization. The test is simpler to implement with less risk to the target environments. Tackling smaller automation projects has the added value of providing experience that may be necessary when designing larger automation projects.

Which goal is a higher priority will depend on your organization’s current needs. We found that, in playing with the true/false approach of security assertions, we focused more of our energy on what data was necessary versus just what data was possible. In addition, since security assertions are assumed to be simple tests, we focused more of our design efforts on perfecting the architecture of scalable testing environment rather than the idiosyncrasies of the tools that the environment would be running. Many automation projects try to achieve depth and breadth at the same time by running complex tools at scale. We decided to take an intermediate step by using security assertions to focus on breadth first and then to layer on depth as we proceed.

 

Focused automation within continual deployment

Creating automation environments to scan entire organizations can be a long term project. Smaller automation projects can often provide quick wins and valuable experience on building automation. For instance, continuous build systems are often a single chokepoint through which a large portion of your cloud must pass before deployment. Many of today’s continuous build environments allow for extensions that can be used to automate processes.

As an example, PCI requires that code check-ins are reviewed. Verifying this process is followed consistently requires significant human labor. One of our Creative Cloud security champions, Jed Glazner, developed a Jenkins plugin which can verify each check-in was reviewed. The plugin monitors the specified branch and ensures that all commits belong to a pull request, and that the pull requests were not self merged. This allows for daily, automatic verification of the process for compliance.

Jed worked on a similar project where he created a Maven plug-in that lists all third-party Java libraries and their versions within the application. The plugin would then upload that information to our third-party library tracker so that we can immediately identify libraries that need updates. Since the plug-in was integrated into the Maven build system, the data provided to the third-party library tracker was always based on the latest nightly build and it was always a complete list.

 

Your organization will eventually build, buy or borrow a large scale automation tool that scales out the enumeration of immediate risk issues. However, before you jump head first into trying to build a robust scanning environment from scratch, be sure to first identify what core questions you need the tools to answer in order to support your program. You might find that starting with smaller automation tasks that track long term objectives or operational best practices can be just as useful to an organization. Deploying these smaller projects can also provide experience that can help your plans for larger automation projects.

 

Peleus Uhley
Principal Scientist

Improving Security for Mobile Productivity with Adobe Document Cloud

Recently Adobe announced that it is working with Microsoft to help improve security of mobile applications and productivity. We have integrated Adobe Acrobat Reader DC with Microsoft Intune, a solution for secure enterprise mobile application management. This gives I.T. management and security professionals more control over critical productivity applications deployed to their mobile device users. This functionality is currently available for Android devices and will soon be made available for iOS devices.

Our work with Microsoft is part of Adobe’s overall commitment to help keep our customers’ critical assets and data secure. We will continue to work with Microsoft and other security community partners to improve security across our products and services.

For more information about this solution, please see our post on the Adobe Document Cloud blog.

Bronwen Matthews
Sr. Product Marketing Manager, Security

Hacktoberfest 2015

Autumn has arrived, and National Cybersecurity Awareness Month with it. We wanted to celebrate and raise awareness about security at Adobe. What could be better than bringing hands on training, a capture the flag competition and beer together in a single day across the world? That is exactly what we did and we called it Hacktoberfest.

Around 160 people in the US, Europe and India came together on October 14th to take part in a full day focused on security. The day progressed from a broad, hands-on threat modeling training to learning tools like Burp Suite to a Capture the Flag event for prizes.

We saw a lot of new faces at this event; no doubt due to the prizes offered for the capture the flag. There was also a diverse skill set present in the room; from people in nontechnical roles to those that have a lot of experience pen testing internally. We learned that our community is hungry for training and a deeper understanding of security. All of the material, except for one training, was developed in-house.

When most people’s interaction with security training is spent with computer-based training, there is great value in bringing people together in a face-to-face event where they can interact not only with the trainers, but also with each other. While we’ve done smaller, more targeted trainings in the past, this was the first truly global event.

People really loved the hands on nature of the day, we had responses like: “I thought the capture the flag event was incredibly fun and engaging.” and “I liked the demonstration on how to use Burp Suite to attack a service/site.”

One of the unique aspects of the day was its global nature. Essentially two events were run, one in the US time zones and one in India. We did our best to create the same experience for the two groups while paying attention to their different content needs. All presentations were local and questions could be answered in real time.

Of course, the most popular event of the day was the Capture the Flag event. One of our researchers, took it upon himself to create an environment to host the game. It’s called WOPR and we will be providing more information on it soon. Two other researchers worked to create the challenges for the game.

There was quite a lot of energy in all of those conference rooms as people engaged with the training and the competition. The most important lesson we learned from this exercise is that people at Adobe, all around the world, care about securing our products.

 

Josh Kebbel-Wyen
Sr. Security Program Manager, Training

Meeting Compliance Challenges with Adobe CCF

The Adobe Common Controls Framework (CCF) enables clear guidance to all of our product and services teams on how to secure our infrastructure and applications. We analyzed the criteria for the most common security certifications and found a number of overlaps. As a result, we were able to take over 1000 requirements from relevant cloud security frameworks and standards and rationalize them down to about 200 Adobe-specific controls. Control owners know exactly what is required to address expectations of stakeholders and customers when it comes to implementing those controls. It also supports more efficient implementation by allowing teams to inherit control capabilities as they are completed throughout the organization.

Watch as Abhi Pandit, our Senior Director for Governance, Risk, and Compliance (GRC), walks through the Adobe CCF, how it is helping us meet the compliance challenges we face in adhering to multiple standards and regulations, and learn how you can use a framework like CCF in your organization to assist with your own compliance challenges. You can learn more about CCF and Adobe’s progress in meeting various standards and regulations across our product lines in our white paper.

Security Collaboration at Adobe

At Adobe we recognize that our customers benefit when we take a collaborative approach to vulnerability disclosure.  We pride ourselves on the symbiotic relationship we’ve cultivated with the security community and continue to value the contributions that security researchers of all stripes make to hardening our software.

As a measure of the value we place in external code reviews and security testing, Adobe interfaces with the security community through a spectrum of engagement models, including (but not limited to):

  • Traditional third-party code reviews and pen-tests
  • Crowd-sourced pen-tests
  • Voluntary disclosures to our Product Security Incident Response Team (PSIRT)
  • Submissions to our web application disclosure program on HackerOne

Code reviews and pen-tests

Before Adobe introduces a major upgrade or new product, feature or online service offering, a code review and pen-test is often performed by an external security company.  These traditional third-party reviews provide a layer of assurance to complement our internal security assessments and static code analysis that are part of our Secure Product Lifecycle (SPLC).

Crowd-sourced pen-tests

To benefit from a larger pool of security researchers, Adobe also uses crowd-sourced pen-tests in tightly scoped, time-bound engagements involving an elite pool of pen-testers targeting a single service offering or web application.   This approach has helped supplement the traditional pen tests against our online services by increasing code coverage and testing techniques.

Disclosures to PSIRT

The Product Security Incident Response Team (PSIRT) is responsible for Adobe’s vulnerability disclosure program, and typically responds first to the security community’s submissions of vulnerabilities affecting an Adobe product, online service or web property.  In addition to its role as conduit with external researchers, PSIRT partners with both internal and external stakeholders to ensure vulnerabilities are handled in a manner that both minimizes risk to customers and encourages researchers to disclose in a coordinated fashion.

Disclosures via HackerOne

In March 2015, Adobe launched its web application vulnerability disclosure program on HackerOne.  This platform offers researchers the opportunity to build a reputation and learn from others in the community, while allowing vendors to streamline workflows and scale resources more effectively.

As new bug hunting and reporting platforms enable part-time hobbyists to become full-time freelance researchers, we look forward to continuing a constructive collaboration with an ever-widening pool of security experts.

 

Pieter Ockers
PSIRT Security Program Manager

Disha Agarwal
Product Security Manager

Join Us at these Upcoming Security Events


On September 24 – 25, 2015, at the Hyatt Regency San Francisco, meet members of the Adobe security team at AppSec USA 2015, presented by the Open Web Application Security Project (OWASP). Rohit Pitke, one of our security engineers, will be speaking on the topic of “Continuous Cloud Security Automation” from 3 – 4 p.m. on Thursday, September 24. Our team will be in the primary booth area near the conference track rooms. We will have information available about our key security initiatives. Several of our recent blog posts, informative brochures, and cool giveaways are also available in our booth if you can stop by.

We are also sponsoring the upcoming Privacy.Security.Risk 2015 conference, presented by the International Association of Privacy Professionals (IAPP) and the Cloud Security Alliance), September 30 – October 1 at the Bellagio in Las Vegas. Our CSO Brad Arkin will be speaking in one of the breakout sessions on October 1 from 2:30 to 3:30 p.m. Make sure to join us for his informative talk.

In addition, Adobe is sponsoring the upcoming Information Security Executives (ISE) Northeast event at the Westin Times Square in New York City on October 8th. Members of our security team will be there and available to answer any questions you have about overall security of our offerings and our efforts in meeting important industry and regulatory standards. We will have information and brochures in our booth and will also be giving away an XBox One game console during the final prize draw at the end of the evening.

We hope to see you at these upcoming events.

Recap: BlackHat 2015 and r00tz@DefCon 2015

This year Adobe security team members were out in force attending BlackHat 2015 and – new this year – helping inspire the next generation of security professionals at the r00tz @ DefCon conference for kids. Adobe was a major sponsor of the r00tz conference this year helping to set up and run a 3D printing workshop and hackfest for the young attendees.

BlackHat brings together the top experts in the security field to discuss and expose current issues in the information security industry. While there were a variety of talks covering a wide breadth of topics, here are some talks that stood out to us during our time there.

In the discussion panel “Is the NSA Still Listening to Your Phone Calls?” Mark Jaycox from the Electronic Frontier Foundation (EFF) and Jamil Jaffer, former member of the House Permanent Select Committee on Intelligence (HPSCI), talked about government surveillance, and the tradeoffs between keeping our privacy and using surveillance to defend against current threats. It was interesting to see two people on opposite sides of the spectrum openly discussing this complex issue. I felt that by listening to the two parties discuss their points I was able to walk away with a more informed opinion on the current stance of government surveillance in the country today.

James Kettle from Portswigger talked about server side template injection and showed techniques to identify and exploit it on popular template engines such as FreeMarker, Velocity, Twig and Jade. This vulnerability occurs when users are allowed to edit templates or untrusted user input is embedded in the template. It was interesting to see how this vulnerability can be used to directly attack web servers and perform remote code execution instead of cross site scripting. The talk raised awareness on the damage one can do if an application is vulnerable to template injection. Our researchers and security champions will be able to apply the information gained from this talk to identify and mitigate template injection in Adobe products.

In “The Node.js Highway: Attacks are at Full Throttle” talk, Maty Siman and Amit Ashbel discussed the security issues and demonstrated new attack techniques against Node.js applications. The attack on pseudo random number generator in Node.js which allows an attacker to predict the next number given 3 consecutive numbers was quite interesting. This means an application generating password using PRNG might reveal the passwords of all the users. The talk educated our researchers and security champions on new vulnerabilities to look for while reviewing a Node.js application.

In addition to all of the great learnings and networking at BlackHat 2015, many from our team stayed around after BlackHat to attend DefCon and help out at the r00tz @ DefCon conference for kids. This was Adobe’s first year sponsoring the r00tz conference. With the help of our awesome Photoshop engineering teams, we were able to get kid-ready workstations set up with our creative tools and hooked up to cool MakerBot 3D printers. It was a lot of fun helping kids take all of the ideas in their heads and translate them into physical objects they could then take home with them – with, of course, a lot of hacking involved to get many of the ideas to work. In addition to our 3D printing workshop, there were other exercises including a capture the flag contest and robot building contest. It was very rewarding for all of us to sponsor and be a part of inspiring these kids to pursue careers in technology.

 

Tim Fleer
Security Program Manager

Karthik Thotta Ganesh
Web Security Researcher

Top 5 Things You Should Know About FedRAMP and Adobe’s Cloud Services for Government

In July, Adobe Experience Manager and Connect Managed Services received FedRAMP Authorization for its Cloud Services for Government. The Department of Health and Human Services (HHS) granted Adobe an Authority to Operate (ATO) for these specific cloud services run by Adobe Managed Services. Most importantly, this ATO can be leveraged government-wide, thereby decreasing the time and cost for other agencies and organizations as they adopt Adobe’s technology. So what exactly does this mean and why is it important? Here are the top 5 things you need to know:

1. What is FedRAMP?
The Federal Risk and Authorization Management Program (FedRAMP) provides a cost-effective, risk-based approach for the adoption and use of cloud services. It is a joint collaboration by the Department of Homeland Security (DHS), Department of Defense (DoD) and General Services Administration (GSA) as well as other working groups to assist agencies in meeting FISMA requirements for cloud systems. It provides a single, standard approach to security assessment, authorization and monitoring of cloud services.

2. Why Should I Care About FedRAMP?
According to the official FedRAMP site, FedRAMP is based upon the same set of security controls as documented in the Federal Information Security Management Act (FISMA) of 2001. These controls are outlined by the National Institute of Standards and Technology (NIST 800-53). Where FISMA exists as the approval process for on-premise programs, FedRAMP exists as the equivalent for cloud solutions. With recent legislation, all agencies seeking to use cloud services can only implement ones that are FedRAMP certified. More information about FedRAMP can be found here.

3. What does Adobe offer?
Adobe is the first FedRAMP cloud service provider (CSP) to deliver this combination of solutions:
• Web Content Management (WCM)
• Electronic Forms with eSignatures
• Documents Rights Management (DRM)
• Web-conferencing
• E-Learning (LMS)

These FedRAMP authorized solutions are supported by Adobe Products, run by Adobe Managed Services, from a specific region within the Amazon Web Services infrastructure.
i. Adobe Experience Manager Managed Services on Amazon GovCloud
ii. Adobe Connect Managed Services on Amazon GovCloud

4. What’s the big deal about FedRAMP Authorization ?
An agency authorized Authority To Operate (ATO) is the FedRAMP stamp-of-approval for federal agencies. It allows government entities (as well as commercial organizations) to more easily adopt Adobe’s FedRAMP certified cloud solutions. Approval from one agency means an approval for all agencies on the federal level – making an ATO extremely valuable for cloud service providers (CSPs).

Adobe partnered with the Department of Health and Human Services (HHS) to determine that Adobe’s approved cloud services comply with FedRAMP requirements. In working through the FedRAMP Security Assessment Framework (SAF), Adobe’s approved cloud services were first examined to be of FedRAMP standards and reviewed to ensure that solutions were properly documented. They then were evaluated by the Veris Group, a third party assessment organization (3APO) to make sure the software performs as documented, and had to pass 328 separate security controls in order to become FedRAMP authorized. The approval process is very intensive and takes anywhere from one to three years to complete. Accordingly, Adobe’s investment is significant and further demonstrates how Adobe stays ahead of the curve in terms of security and compliance.

5. Benefits of FedRAMP Certification for Cloud Based Solutions
In 2011 the U.S Federal Government released the Federal Cloud Computing Strategy that instituted a “Cloud First” policy emphasizing cloud services by requiring agencies to adopt a cloud solution if one exists. This strategy was developed as a result of three main benefits of cloud services: its deployment speed, minimal on-premise upkeeping, and constant stream of updates.
• Fast deployment speed – Hosted cloud solutions are typically already ‘up and running’ compared to on-premise solutions which can take months to implement. The beautiful part of the cloud is its scalability – it can be grow or shrink to suit the demands of the enterprise.
• Minimal on-premise housekeeping – in on-premise solutions, a lot of time is required of the security staff of individual agencies to set up servers, install software, manage patches and updates, performing backups and troubleshooting problems. With cloud solutions, there typically aren’t on-site servers, the software installs, patches and back up is the responsibility of the cloud service provider. This saves federal agencies time and money and allows the agency’s security team to focus on their core job.
• Always the newest version – Cloud solutions are constantly updated to provide new features or services and keep up to date with the changing security landscape. Cloud service providers also learn from the implementation of its software for one agency in order to improve the product to its other customers. These learnings help ensure that our customers are getting a secure and high quality service.

The US Government has clearly identified cloud solutions as the way of the future. With its recent FedRAMP authorization, Adobe seeks to be cemented as one of the leaders of cloud solutions in the public sector with its unique cloud service solutions.

You can learn more about how FedRAMP – and Adobe solutions – are helping to bring about the “consumerization of Government” in my other recent blog.

John Landwehr
Vice President & Public Sector CTO