Levvel Blog - Don’t Let Fear Rule Your Enterprise – Part 3

Don’t Let Fear Rule Your Enterprise – Part 3

The last post in this series gave an introduction to specific security best practices within AWS. The second complaint given by IT organizations about cloud infrastructure is they can not meet the stringent compliance requirements for “our industry.” This post will expand on the compliance capabilities of AWS.

AWS has, but is not limited to, the following compliance certifications available to your organization:

  • PCI DSS Level 1
  • SOC 1, SOC 2, SOC 3
  • ISO 9001
  • ISO 270001
  • ITAR
  • DoD SRG Levels 2 and 4
  • MPAA

The previous post discussed the shared security responsibility model for AWS. In order to adhere to compliance standards in the AWS cloud, it is important to realize that the same shared responsibility model paradigm exists for compliance. Simply pushing an application that collects credit card data to Elastic Beanstalk and RDS does not mean you are PCI compliant. There are very strict requirements around storing protected personal information. AWS claiming they are PCI compliant simply means the Global infrastructure, firewalls, and data storage mechanisms are PCI compliant. However, every application must pass an external audit to claim true PCI compliance. The AWS FAQ states: “All merchants manage their own PCI certification. For the portion of the PCI cardholder environment deployed in AWS, your QSA can rely on our PCI compliance, but you will still be required to satisfy all other PCI compliance and testing requirements, including how you manage the cardholder environment that you host with AWS.” Much like security, the shared responsibility model gives enterprise organizations the flexibility they need to create compliant applications, but does not require enterprises to build PCI compliant data centers. If you would like to know more about creating PCI compliant applications please see this AWS whitepaper. AWS provides many other white papers for specifics on adhering to specific compliance regulations within their shared responsibility model.

In order to create a network infrastructure that adheres to so many compliance certifications and regulations, AWS follows a “Security by Design (SbD)” methodology. This methodology also functions as a checklist for enterprise organizations to begin the process of becoming compliant. According to AWS SbD “formalizes AWS account design, automates security controls, and streamlines auditing.” This simply means that AWS is proactively builds in security measures throughout their management process rather than retroactively performing security audits. SbD utilizes a four phased approach to adhere to various security, compliance, and regulatory standards across a multitude of industries. The four phases are:

  1. Understand your requirements
  2. Build a “golden environment” that fits your requirements and implementation
  3. Enforce the use of the templates
  4. Perform validation activities.

Phase 1 simply states that the enterprise organization should document all controls that AWS manages and document all controls managed by the organization. This documentation will flesh out the shared responsibility model and give enterprises the functional requirements needed to meet their compliance goals. Phase 2 is an implementation step wherein the enterprise will create a “golden environment” inside the AWS infrastructure. Once the infrastructure is created a Cloud Formation template can be constructed that will give enterprises a JSON script that allows them to spin up environments that are guaranteed to adhere to their functional requirements. If you have not see CloudFormation, check out AWS’ documentation here. Once your template is created the final phase in SbD is to validate your template. According to their documentation for SbD “The rules you defined in your template can be used as an audit guide. AWS Config allows you to capture the current state of any environment, which can then be compared with your ‘golden environment’ rules.”

The SbD approach is meant to achieve the following:

  • Creation of forcing functions that cannot be overridden by those users that are not allowed to modify these functions.
  • A JSON script that represents your governance policy.
  • Enabling continuous and real-time auditing.
  • Operation of control is established reliably.

The result is an automated environment enabling the security assurance, governance, security, and compliance capabilities of your environment. Customers can now execute reliable implementation of what was previously written in policies, standards and regulations. Additionally, enterprise organizations can create enforceable security and compliance rules.

This portion of the blog series highlighted the requirements needed for creating compliant applications utilizing AWS. The shared responsibility model was expanded upon from the previous security post, and you learned more about how this affects compliance. Security and compliance go hand in hand in the AWS cloud because AWS gives you a solid baseline for these requirements to reduce duplicate efforts, but also gives enterprise organizations the tools necessary to adhering to any future changes in these requirements or industry specific regulations. Finally, the Security by Design methodology was described in order to understand how to move forward with your enterprise compliance needs. Check back soon for our post on reducing costs by moving to a cloud infrastructure.

Keith LaForce

Keith LaForce

SVP of Capabilities

I have been in the software industry for over 10 years. I am passionate about designing large scale system architectures, data science, and solving problems that no else wants to consider. I have extensive experience with PHP, .NET, NodeJS, and front-end Javascript.

Related Posts