Posts tagged "standards"

Developing an Amazon Web Services (AWS) Security Standard

Adobe has an established footprint on Amazon Web Services (AWS).  It started in 2008 with Managed Services, and expanded greatly with the launch of Creative Cloud in 2012 and the migration of Business Catalyst to AWS in 2013. In this time, we found challenges in keeping up with AWS security review needs.  In order to increase scalability, it was clear we needed a defined set of minimum AWS security requirements and tooling automation for auditing AWS environments against it.  This might sound simple, but like many things, the devil was in the details. It took focused effort to ensure the result was a success.  So how did we get here?  Let’s start from the top.

First, the optimal output format needed to be decided upon.  Adobe consists of multiple Business Units (BUs) and there are many teams within those BUs.  We needed security requirements that could be broadly applied across the company as well as to acquisitions. so we needed requirements that could not only be applied to existing services and new services across BUs; but also be future-proof. Given these constraints, creating a formal standard for our teams to follow was the best choice.

Second, we needed to build a community of stakeholders in the project. For projects with broad impact such as this, it’s best to have equally broad stakeholder engagement.  I made sure we had multiple key representatives from all the BUs (leads, architects, & engineers) and that various security roles were represented (application security, operational security, incident response, and our security operations center).  This led to many strong opinions about direction. Thus, it was important to be an active communication facilitator for all teams to ensure their needs are met.

Third, we reviewed other efforts in the security industry to see what information we could learn.  There are many AWS security-related whitepapers from various members of the security community.  There have been multiple security-focused AWS re:Invent presentations over the years.  There’s also AWS’s Trusted Advisor and Config Rules, plus open source AWS security assessment tools like Security Monkey from Netflix and Scout2 from NCC Group.  These are all good places to glean information from.

While all of these varied information sources are fine and dandy, is their security guidance relevant to Adobe?  Does it address Adobe’s highest risk areas in AWS?  Uncritically following public guidance could result in the existence of a standard for the sake of having a standard – not one that delivered benefits for Adobe.

A combination of security community input, internally and externally documented best practices, and looking for patterns and possible areas of improvement was used to define an initial scope to the standard.  At the time the requirements were being drafted, AWS had over 30 services. It was unreasonable (and unnecessary) to create security guidance covering all of them.  The initial scope for the draft minimum security requirements was AWS account management, Identity & Access Management (IAM), and Compute (Amazon Elastic Compute Cloud (EC2) and Virtual Private Cloud (VPC)).

We worked with AWS stakeholders within Adobe through monthly one-hour meetings to get agreement on the minimum bar security requirements for AWS and which were to be applied to all of Adobe’s AWS accounts (dev, stage, prod, testing, QA, R&D, personal projects, etc).  We knew we’d want a higher security bar for environments that handle more sensitive classes of data or were customer facing. We held a two-day AWS security summit that was purely focused on defining these higher bar security requirements to ensure all stakeholders had their voices heard and avoid any contention as the standard was finalized.

As a result of the summit, the teams were able to define higher security requirements that covered account management/IAM and compute (spanning architecture, fleet management, data handling, and even requirements beyond EC2/VPC including expansion into AWS-managed services such as S3, DynamoDB, SQS, etc.).

I then worked with Adobe’s Information Systems Security Policies & Standards team to publish an Adobe-wide standard.  I transformed the technical requirements into an appropriate standard.  This was then submitted to Adobe’s broader standards’ teams to review.  After this review, it was ready for formal approval.

The necessary teams agreed to the standard and it was officially published internally in August 2016.  I then created documentation to help teams use the AWS CLI to audit for and correct issues from the minimum bar requirements. We also communicated the availability of the standard and began assisting teams towards meeting compliance with it.

Overall the standard has been well received by teams.  They understand the value of the standard and its requirements in helping Adobe ensure better security across our AWS deployments.  We have also developed timelines with various teams to help them achieve compliance with the standard. And, since our AWS Security Standard was released we have seen noted scalability improvements and fewer reported security issues.  This effort continues to help us in delivering the security and reliability our customers expect from our products and services.

Cynthia Spiess
Web Security Researcher

Scaling Security Controls Across the Enterprise

Adobe is changing the world through digital experiences. We do that in an incredibly creative and innovative environment where we also take our customers’ data security and privacy very seriously.  As a large and growing cloud company, achieving these things at the same time takes a sound strategy focused on two key pillars:

  • Establish Effective, Enforceable Security Standards
  • Implement and Adopt Simple, Scalable Security Services

Establish Effective, Enforceable Security Standards

The Common Controls Framework (CCF) is a comprehensive set of simple control requirements, rationalized from the alphabet soup of several different industry information security and privacy standards. To help ensure that our standards effectively meet our customers’ expectations, we are constantly refining this framework based on industry requirement changes, customer asks, and internal feedback.

In a recent update, Abhi Pandit (Adobe’s Sr. Director of Risk Advisory & Assurance Services) stated that “[Adobe] has made significant investments across the company to harmonize various security functions, compliance and governance processes, and technologies.” The CCF is the backbone of our corporate security policies and standards.

Implement and Adopt Simple, Scalable Security Services

With a common vision for customer data security and privacy set, we can look to our talented engineers to develop and implement the solutions that help meet our objectives.  Engineering teams collaborate to develop scalable solutions that implement the CCF requirements in the most efficient and elegant way possible. Other teams leverage those services and help improve them over time.

A common pitfall seen with initiatives like the CCF is that teams may try to implement all of the standards on their own with little or no reliance on cross-functional services. Not only does this undermine the entire purpose of a common standard, it can often result in some undesirable outcomes. Examples include:

  • Team resources overwhelmed by compliance initiatives and ability to deliver on product features may be hindered.
  • Standalone compliance initiatives only partly address requirements and security may be compromised.
  • Exhausted team resources lead to operational failure of compliance responsibilities and security may be compromised.

At Adobe, we make a concerted effort to help product teams use simple, scalable services to help prevent these undesirable outcomes. These services are a combination of internally developed services and reliable third party tools. Teams focus their effort on adopting those security services helping to free up their time to focus more on features that deliver a delightful, more secure user experience.

Practical Example of Implementation

Adobe uses four different types of control “roles” to organize our compliance efforts to meet the CCF standards: Driver, Subscriber, Contributor, and Standalone.

A driver is ultimately responsible for developing a service, including controls, that will mitigate a particular risk associated with a process and address the CCF requirements. For example, a driver implements a robust Identity Management system that can provide automated workflows for logical access control.

A subscriber is responsible to integrate their systems and processes in a way that will take advantage of the driver’s service. Continuing with the example above, a subscriber makes sure the only way to access their system is through the driver’s identity management system. As long as this continues, they share the risk with the driver.

A contributor is like a subscriber, integrated with a driver’s solution, but they may have a more active role in executing the control. A great example is a periodic access review. The driver’s identity management system gives contributors a notification that it’s time to review the access privileges in their respective groups so that they can certify the access is appropriate. They use a tool that makes it easy and effective—much easier and effective than a manual process that leverages a ticket or email.

If a team decided to tackle these problems as a standalone, they would need to set up their own identity management system or manual procedures to handle logical access control. These tend to be more manual and at a higher risk for control failure. The advantage of the CCF framework is these necessary core services and controls are provided and teams do not need to tackle these issues on their own, helping to lessen the overall risk.

The table below outlines a summary of these different roles and how they are currently viewed at Adobe.

Adobe CCF Control Roles

Role Business Objective Risk Responsibility
Driver Implement robust service for all teams to satisfy control requirements. Reduce instances of services to the minimum possible and improve the services over time. Mitigate
Subscriber Adopt robust service provided by Driver Transfer/Share
Contributor Leverage robust service provided by Driver and work with them to meet requirements Transfer/Share
Standalone Implement a process to satisfy control requirements. Reduce instances to the minimum possible. Mitigate

Conclusion

As Adobe grows, it is the hope that the number of compliance procedures should not grow at the same rate. The simple concepts explained in this post make up some of the secret sauce of how to leverage a compliance program to more effectively mitigate information security and privacy risk in a scalable way.

Kenny Scott
Manager, I.T. and Information Security, Risk Advisory and Assurance Services

Updated Security Information for Adobe Creative Cloud

As part of our major release of Creative Cloud on June 16th, 2015, we released an updated version of our security white paper for Adobe Creative Cloud for enterprise. In addition, we released a new white paper about the security architecture and capabilities of Adobe Business Catalyst. This updated information is useful in helping I.T. security professionals evaluate the security posture of our Creative Cloud offerings.

Adobe Creative Cloud for enterprise gives large organizations access to Adobe’s creative desktop and mobile applications and services, workgroup collaboration, and license management tools. It also includes flexible deployment, identity management options including Federated ID with Single Sign-On, annual license true-ups, and enterprise-level customer support — and it works with other Adobe enterprise offerings. This version of the white paper includes updated information about:

  • Various enterprise storage options now available, including updated information about geolocation of shared storage data
  • Enhancements to entitlement and identity management services
  • Enhancements to password management
  • Security architecture of shared services and the new enterprise managed services

Adobe Business Catalyst is an all-in-one business website and online marketing solution providing an integrated platform for Content Management (CMS), Customer Relationship Management (CRM), E‐Mail Marketing, ECommerce, and Analytics. The security white paper now available includes information about:

  • Overall architecture of Business Catalyst
  • PCI/DSS compliance information
  • Authentication and services
  • Ongoing risk management for the Business Catalyst application and infrastructure

Both white papers are available for download on the Adobe Security resources page on adobe.com.

 

Chris Parkerson
Sr. Marketing Strategy Manager

Straight Talk about PDF & Digital Signatures – ISSE 2009

Jim King, PDF Architect, senior principal scientist at Adobe and one of the key drivers behind the PDF format and its adoption and continuing development by ISO as a standard (ISO 32000), recently delivered a keynote presentation to the ISSE (Information Security Solutions Europe) 2009 Conference in The Hague, Netherlands.  He discussed the evolution of the PDF format and standard, and spent most of his talk introducing the new PAdES signature standard and what it encompasses.

During that conference, Jim sat down with Roger Dean, executive director of eema UK, for a conversation about PDF, the need for digital signatures, challenges of communicating the benefits of digital signatures, and finally a description of the PAdES standard.  This interview is now available below (and here)…enjoy!