Adobe Security Team Members Win Recent CTF Competition

Kriti and Abhiruchi from our corporate security team in Noida, India, were crowned the winners of the recent Winja Capture the Flag (CTF) competition hosted at the NullCon Goa security conference. Twelve (12) teams competed in this year’s contest. We would like to congratulate Kriti and Abhiruchi on their win. Adobe is an ongoing sponsor of the Nullcon conference. This competition was created by women to encourage their peers to enter the field of cybersecurity. It is a complete set of simulated web application security hacking challenges. Each challenge is separated into small tasks that can be solved individually by the competitors on each team. Each team works through the timed two (2) hour duration of the event in an attempt to attack and defend the computers and networks using prescribed tools and network structures.

Adobe is a proud supporter of events and activities encouraging women to pursue careers in cybersecurity. We are also sponsoring the upcoming Women in Cybersecurity conference March 31st to April 2nd in Dallas, Texas. Members of our security team will be there at the conference. If you are attending, please take the time to meet and network with them.

David Lenoe
Director, Product Security

New Security Framework for Amazon Web Services Released

The Center for Internet Security, of which Adobe is a corporate supporter, recently released their “Amazon Web Services Foundations Benchmark.” This document provides prescriptive guidance for configuring security options for a subset of Amazon Web Services with an emphasis on foundational, testable, and architecture agnostic settings. It is designed to provide baseline suggestions for ensuring more secure deployments of applications that utilize Amazon Web Services. Our own Cindy Spiess, web security researcher for our cloud services, is a contributor to the current version of this framework. Adobe is a major user of Amazon Web Services and efforts like this further our goals of educating the broader community on security best practices. You can download the framework document directly from the Center for Internet Security.

Liz McQuarrie
Principal Scientist & Director, Cloud Security Operations

RSA Conference 2016 Is Just Around the Corner 

It is that time of year again. The world’s largest security conference is descending on San Francisco next week, February 28th – March 4th. This year, myself and members of my team will be participating in the Executive Security Action Forum (ESAF) and speaking during track sessions of the main conference.

First up will be Mike Mellor, our Director of Security for Marketing Cloud, speaking on, “Security Monitoring in the Real World with Petabytes of Data.” This session will discuss how we use intelligent security monitoring to help safeguard our customers’ data. His session starts at 2:20 p.m. on Tuesday, March 1st, in the “Sponsor Special Topics” track in room North 131.

Later in the week will be Peleus Uhley, our Lead Security Strategist, speaking on, “Techniques for Security Scalability.” His session will discuss proper strategies and solutions for implementing security “at scale” in large organizations with diverse technology stacks. His session starts at 9:00 a.m. on Friday, March 4th, in the “Security Strategy” track in room West 3004.

As always, members of our security teams and myself will be attending the conference to network, learn about the latest trends in the security industry, and share our knowledge. Looking forward to seeing you.

Brad Arkin
Chief Security Officer

Marketing Cloud Gains New Compliance Wins

Over the past couple of years, we have developed the Adobe Common Controls Framework (CCF), enabling our cloud products, services, platforms and operations to achieve compliance with various security certifications, standards, and regulations (SOC2, ISO, PCI, HIPAA, FedRAMP etc.).  The CCF is a cornerstone of our company-wide security strategy. The framework has gained acceptance and visibility across our businesses leading to a growing roster of certifications.

Last week, Adobe Marketing Cloud became compliant with SOC2 -Type 1. This certification also enables our financial institution customers to comply with the Gramm-Leach Bliley Act (GLBA) requirements for using service providers.

In addition to SOC2 – Type 1, Adobe Experience Manager Managed Services (AEM MS) and Adobe Connect Managed Services (AC MS) have achieved compliance with ISO27001.  AEM MS has also achieved compliance with HIPAA, now joining AC MS in this designation.  This is in addition to the recently confirmed FedRAMP certification for both of these solutions, achieved in 2015.

During 2015, the Document Cloud eSign service implemented the CCF as well and became compliant with SOC2-Type 2, ISO27001, PCI, and HIPAA requirements. Please refer to the “Adobe Security and Privacy Certifications” white paper on Adobe.com for the most up-to-date information about our certifications across our products and services.

Over the past 3 years, we have made significant investments across the company to harmonize various security functions, compliance and governance processes, and technologies. These are major accomplishments and milestones for Adobe’s cloud services and products which will allow us to provide our customers with assurance that their data and applications are more secure.

We have also been out in the security and compliance community, talking with information security and compliance professionals about CCF. This has enabled further collaboration with industry peers in this area. This is a all part of our on-going commitment to help protect our customers and their data. We will update you in future posts on this blog as we achieve additional compliance milestones.

Abhi Pandit
Sr. Director – Risk Advisory and Assurance

 

Applying the SANS Cybersecurity Engineering Graduate Certification to Adobe’s Secure Product Lifecycle (part 2 of 2)

In the first part of this series I discussed how the SANS Cybersecurity Engineering Graduate Certificate helped me analyze the Heartbleed vulnerability and how it applied to static code analysis. This resulted in the paper “The Role of Static Analysis in Heartbleed.” Now I’ll focus on what was learned in the final part of the program and how we can apply this to our efforts here at Adobe.

The course on “Hacking Techniques and Incident Response” taught some of the techniques that attackers use to compromise systems. It also provided an overview of  the forensic tools that are used to detect those attacks. In addition to the labs, students were given access to the NetWars platform. NetWars is a simulated cyber range where you can practice offensive and defensive cybersecurity techniques against live systems. Practical hands on experience is key when doing incident response and the platform facilitates this learning. The highlight of the week was being able to use the NetWars system in a competition format solving real-world problems.

The final course on “Advanced Network Intrusion Detection and Analysis” started with “bit bootcamp” and explored the lower levels of the networking stack. We were taught how to decode packets and truly understand all of the network communication that is occurring on a given computing device. The second part of the class was focused on learning how to deploy network utilities like Snort, Bro, and Silk for network analysis. The SANS at Night talks were also very useful as they allowed me to hear about recent vulnerabilities faced by the security industry as a whole and discuss potential solutions.

There were numerous techniques taught in both of these classes and through Netwars that were directly relevant to working on Adobe Photoshop and our related Creative Cloud services. While I was familiar with Charles and BurpSuite to do web session debugging, these classes allowed me to truly understand how to use deeper features of these tools to determine types of traffic being sent across the network. They also helped me understand when and how to carve the network traffic in order to focus on a smaller set of packets which can then be manually inspected in tools like Wireshark. These tools are great for testing for accidental information disclosure as well as proper authorization checks on cookies.

Taking the techniques learned during professional development and applying them directly to a set of problems on the job is the best you can hope for in any training.  The tools and information  from these classes has already helped in our ongoing efforts to make Photoshop a more secure product.

Jeff Sass
Engineering Manager, Photoshop
GSEC, GCIH, GCIA

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