Posts in Category "Uncategorized"

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

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.

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.

The Adobe Security Team is On the Road This Week

The Adobe Security team will be out in the community providing the latest information about our security initiatives and available to answer your questions at two major conferences this week. Members of our U.S. and European teams will be at the annual OWASP AppSec EU conference May 19 – 22 in Amsterdam. We will be in booth G5 at the conference and will be raffling off a new XBox One gaming system – all of those that stop by our booth are eligible for the raffle. Our U.S. team will also be at the Cloud Security World Conference May 19 – 21 in New Orleans, Louisiana. Abhi Pandit, our Sr. Director for Risk and Assurance, will be speaking at 9 a.m. on Wednesday, May 20th, on the topic of “Who Says Compliance in the Cloud is Just a ‘Documentation Effort?'” We hope that if you’re in New Orleans for this event you’ll take the opportunity to listen to his session. We look forward to meeting as many of you as we can at our events this week.

Adobe @ NullCon Goa 2015

The ASSET team in Noida recently attended NullCon, a well-known Indian conference centered around information security held in Goa. My team and I attended different trainings on client side security, malware analysis, mobile pen-testing & fuzzing, delivered by industry experts in their respective fields. A training I found particularly helpful was one on client-side security by Mario Heiderich. This training revealed several interesting aspects of browser parsing engines. Mario revealed various ways XSS protections can be defeated and how using modern JavaScript frameworks like AngularJS can also expand attack surface. This knowledge can help us build better protective “shields” for web applications.

Out of the two night talks, the one I found most interesting was on the Google fuzzing framework. The speaker, Abhishek Arya, discussed how fuzz testing for Chrome is scaled using a large infrastructure that can be automated to reveal exploitable bugs with the least amount of human intervention. During the main conference, I attended a couple of good talks discussing such topics as the “sandbox paradox”, an attacker’s perspective on ECMA-2015, drone attacks, and the Cuckoo sandbox. James Forshaw‘s talk on sandboxing was of particular interest as it provided useful knowledge on sandboxes that utilize special APIs on the Windows platform that can help make them better. Another beneficial session was by Jurriaan Bremer on Cuckoo sandbox where he demonstrated how his tool can be used to automate analysis on malware samples.

Day 2 started with the keynote sessions from Paul Vixie (Farsight Security) and Katie Moussouris (HackerOne). A couple of us also attended a lock picking workshop. We were given picks for some well-known lock types. We were then walked through the process of how to go about picking those particular locks. We were successful opening quite a few locks. I also played Bug Bash along with Gineesh (Echosign Team) and Abhijeth (IT Team) where we were given live targets to find vulnerabilities. We were successful in finding a couple of critical issues winning our team some nice prize money. :-)

Adobe has been a sponsor of NullCon for several years. At this year’s event, we were seeking suitable candidates for openings on our various security teams. In between talks, we assisted our HR team in the Adobe booth explaining the technical aspects of our jobs to prospective candidates. We were successful in getting many attendees interested in our available positions.

Overall, the conference was a perfect blend of learning, technical discussion, networking, and fun.

 

Vaibhav Gupta
Security Researcher- ASSET

Information about Adobe’s Certification Roadmap now available!

At Adobe, we take the security of your data and digital experiences seriously. To this end, we have implemented a foundational framework of security processes and controls to protect our infrastructure, applications and services and help us comply with a number of industry accepted best practices, standards and certifications. This framework is called the Adobe Common Controls Framework (CCF). One of the goals of CCF is to provide clear guidance to our operations, security and development teams on how to secure our infrastructure and applications. We analyzed the criteria for the most common certifications and found a number of overlaps. We analyzed over 1000 requirements from relevant frameworks and standards and rationalized them down to about 200 Adobe-specific controls.

Today we have released a white paper detailing CCF and how Adobe is using it to help meet the requirements of important standards such as SOC2, ISO, and PCI DSS among others. CCF is a critical component of Adobe’s overall security strategy. We hope this white paper not only educates on how Adobe is working to achieve these industry certifications, but also provides useful knowledge that is beneficial to your own efforts in achieving compliance with regulations and standards affecting your business.

Never Stop Coding

Several members of Adobe’s security team have taken to the media to offer career advice to aspiring security professionals (you can read more about that here, here, and here). For those interested in security researcher positions, my advice is to never stop coding. This is true whether you are working in an entry-level position or are already a senior researcher.

Within the security industry, it has often been said, “It is easier to teach a developer about security than it is to teach a security researcher about development.” This thought can be applied to hiring decisions. Those trained solely in security can be less effective in a development organization for several reasons.

Often, pure security researchers have seen only the fail in the industry. This leads them to assume vulnerable code is always the product of apathetic or unskilled developers. Since they have never attempted large-scale development, they don’t have a robust understanding of the complex challenges in secure code development. A researcher can’t be effective in a development organization if he or she doesn’t have an appreciation of the challenges the person on the other side of the table faces.

The second reason is that people with development backgrounds can give better advice. For instance, when NoSQL databases became popular, people quickly mapped the concept of SQL injection to NoSQL injection. At a high level, they are both databases of information and both accept queries for their information. So both can have injections. Therefore, people were quick to predict that NoSQL injection would quickly become as common as SQL injection. At a high level, that is accurate.

SQL injection is popular because it is a “structured query language,” which means all SQL databases follow the same basic structured format. If you dig into NoSQL databases, you quickly realize that their query formats can vary widely from SQL-esque queries (Cassandra), to JSON-based queries (MongoDB, DynamoDB), to assembly-esque queries (Redis). This means that injection attacks have to be more customized to the target. Although, if you are able to have a coding level discussion with the developers, then you may discover that they are using a database driver which allows them to use traditional SQL queries against a NoSQL database. That could mean that traditional SQL injections are also possible against your NoSQL infrastructure. Security recommendations for a NoSQL environment also have to be more targeted. For instance, prepared statements are available in Cassandra but not in MongoDB. This is all knowledge that you can learn by digging deep into a subject and experimenting with technologies at a developer level.

Lastly, you learn to appreciate how “simple” changes can be more complex than you first imagine. I recently tried to commit some changes to the open-source project, CRITs. While my first commit was functional, I’ve already refactored the code twice in the process of getting it production-ready. The team was absolutely correct in rejecting the changes because the design could be improved. The current version is measurably better than my first rough-sketch proposal. While I don’t like making mistakes in public, these sorts of humbling experiences remind me of the challenges faced by the developers I work with. There can be a fairly large gap between a working design and a good design. This means your “simple recommendation” actually may be quite complex. In the process of trying to commit to the project, I learned a lot more about tools such as MongoDB and Django than I ever would have learned skimming security best practice documentation. That will make me more effective within Adobe when talking to product teams using these tools, since I will better understand their language and concerns. In addition, I am making a contribution to the security community that others may benefit from.

At this point in my career, I am in a senior position, a long way from when I first started over 15 years ago as a developer. However, I still try to find time for coding projects to keep my skills sharp and my knowledge up-to-date. If you look at the people leading the industry at companies such as Google, Etsy, iSec Partners, etc., many are respected because they are also keeping their hands on the keyboards and are speaking from direct knowledge. They not only provide research but also tools to empower others. Whether you are a recent grad or a senior researcher, never lose sight of the code, where it all starts.

Peleus Uhley
Lead Security Strategist

More Effective Threat Modeling

There are a lot of theories about threat models. Their utility often depends on the context and the job to which they are applied. I was asked to speak about threat models at the recent BSIMM Community Conference, which made me formally re-evaluate my thoughts on the matter. Over the years I’ve used threat models in many ways at both the conceptual level and at the application level. In preparing for the conference I first tried to deconstruct the purpose of threat models. Then I looked at the ways I’ve implemented their intent.

Taking a step back to examine their value with respect to any risk situation, you examine things such as who, what, how, when, and why:

Who is the entity conducting the attack, including nation states, organized crime, and activists.

What is the ultimate target of the attack, such as credit card data.

How is the method by which attackers will get to the data, such as SQL injection.

Why captures the reason the target is important to the attacker. Does the data have monetary value? Or are you just a pool of resources an attacker can leverage in pursuit of other goals?

A threat can be described as who will target what, using how in order to achieve why.

We will come back to when in a moment. Threat models typically put most of the focus on what and how. The implicit assumption is that it doesn’t really matter who or why—your focus is on stopping the attack. Focusing on what and how allows you to identify potential bugs that will crop up in the design, regardless of who might be conducting the attack and their motivation.

The challenge with focusing solely on what and how is that they change over time. How is dependent on the specifics of the implementation, which will change as it grows. On the other hand, who and why tend to be fairly constant. Sometimes, focusing on who and why can lead to new ideas for overall mitigations that can protect you better than the point fixes identified by how.

For instance, we knew that attackers using advanced persistent threat (APT) (who) were fuzzing (how) Flash Player (what). To look at the problem from a different angle, we decided to stop and ask why. It wasn’t solely because of Flash Player’s ubiquity. At the time, most Flash Player attacks were being delivered via Office documents. Attackers were focusing on Flash Player because they could embed it in an Office document to conduct targeted spearphishing attacks. Targeted spearphishing is a valuable attack method because you can directly access a specific target with minimal exposure. By adding a Flash Player warning dialogue to alert users of a potential spearphishing attempt in Office, we addressed why Flash Player was of value to them. After that simple mitigation was added, the number of zero-day attacks dropped noticeably.

I also mentioned that when could be useful. Most people think of threat models as a tool for the design phase. However, threat models can also be used in developing incident response plans. You can take any given risk and consider, “When this mitigation fails or is bypassed, we will respond by…”

Therefore, having a threat model for an application can be extremely useful in controlling both high-level (who/why) and low-level threats (how/what). That said, the reality is that many companies have moved away from traditional threat models. Keeping a threat model up-to-date can be a lot of effort in a rapid development environment. Adam Shostack covered many of the common issues with this in his blog post, The Trouble with Threat Modeling. The question each team faces is how to achieve the value of threat modeling using a more scalable method.

Unfortunately, there is not a one-size-fits-all solution to this problem. For the teams I have worked with, my approach has been to try and keep the spirit of threat modeling but be flexible on the implementation. Threat models can also have different focuses, as Shostack describes in his blog post, Reinvigorate your Threat Modeling Process. To cover all the variants would be too involved for a single post, but here are three general suggestions:

  1. There should be a general high-level threat model for the overall application. This high-level model ensures everyone is headed in the same direction, and it can be updated as needed for major changes to the application. A high-level threat model can be good for sharing with customers, for helping new hires to understand the security design of the application, and as a reference for the security team.
  2. Threat models don’t have to be documented in the traditional threat model format. The traditional format is very clear and organized, but it can also be complex and difficult to document in different tools. The goal of a threat model is to document risks and plans to address them. For individual features, this can be in a simple paragraph form that everyone can understand. Even writing, “this feature has no security implications,” is informative.
  3. Put the information where developers are most likely to find it. For instance, adding a security section to the spec using the simplified format suggested eliminates the need to cross-reference a separate document, helping to ensure that everyone involved will read the security information. The information could also be captured in the user story for the feature. If your code is the documentation, see if your Javadoc tool supports custom tags. If so, you could encourage your developers to use an @security tag when documenting code. If you follow Behavior Driven Development, your threat model can be captured as Cucumber test assertions. Getting this specific means the developer won’t always have the complete picture of how the control fits into the overall design. However, it is important for them to know that the documentation note is there for a specific security reason. If the developer has questions, the security champion can always help them cross-reference it to the overall threat model.

Overall I think the concept of threat modeling still serves a valid purpose. Examining how and what can ensure your implementation is sound, and you can also identify higher level mitigations by examining who and why. The traditional approach to threat modeling may not be the right fit for modern teams, though teams can achieve the goal if they are creative with their implementation of the concept. Along with our development processes, threat modeling must also evolve.

Peleus Uhley
Lead Security Strategist

Join Us at CSA EMEA Congress November 19 – 20!

Adobe will be participating again this year in the Cloud Security Alliance (CSA) EMEA Congress event in Rome, Italy, November 19 – 20, 2014. This conference attracts senior decision makers in IT Security from a wide range of industries and governmental organizations. This event focuses on regulatory, compliance, governance, and technical security issues facing both cloud service providers and users of cloud services. We’re excited to be back at what promises to be another great event this year.

I will be presenting a keynote session entitled “Security Roadmaps and Dashboards, Oh My!” on Thursday, November 20th, at 9:40 a.m. A “good” security roadmap is going to come from an ear-to-the-ground approach to security across all teams. It should also reflect current security industry trends. This is essential in creating a multi-faceted, balanced security roadmap that actually drives teams to build security into everything they do. How do you build and keep a solid, adaptable security roadmap in place? By focusing on the right metrics to measure success against the roadmap and developing meaningful dashboards to communicate progress and success to management. This presentation will discuss how Adobe tackled this problem across its very large product, service, and I.T. organization and provide insights into how you might tackle this problem in your own organization. I will also be available in our booth to answer questions after the session.

Please make sure to follow @AdobeSecurity on Twitter for the latest happenings during CSA EMEA Congress as we will be live tweeting during the event – look for the hashtag #AdobeCSA.

 

David Lenoe

Director, Product Security