SbD outlines the control responsibilities, the automation of security baselines, the configuration of security, and the customer audit of controls for AWS customer infrastructure, operating systems, services and applications running in AWS. This standardized, automated, prescriptive, and repeatable design can be deployed for common use cases, security standards, and audit requirements across multiple industries and workloads.
AWS recommends building in security and compliance into your AWS account by following a four-phase approach:
Phase 1 – Understand your requirements. Outline your policies, then document the controls you inherit from AWS. Next, document the controls you own and operate in your AWS environment, and decide what security rules you want to enforce within your AWS IT environment.
Phase 2 – Build a secure environment that fits your requirements and implementation. Define the configuration you require in the form of AWS configuration values, such as encryption requirements (for example, forcing server-side encryption for S3 objects), permissions to resources (which roles apply to certain environments), which compute images are authorized (based on the hardened images of servers that you have authorized), and what kind of logging must be enabled (such as enforcing the use of CloudTrail on applicable resources). AWS provides a mature set of configuration options with new services being released all the time, and AWS makes templates available for aligning your environment to security controls. These security templates (in the form of AWS CloudFormation Templates) provide a comprehensive rule set that can be systematically enforced. AWS has developed templates that provide security rules conforming to multiple security frameworks. For more information, see the Introduction to Security by Design whitepaper.
More help to create your secure environment is available from AWS experienced architects, AWS Professional Services, and AWS Partner Solutions. These teams can work alongside your staff and audit teams to help implement high-quality secure environments in support of third-party audits.
Phase 3 – Enforce the use of the templates. AWS Service Catalog allows you to require the use of your template in the catalog. This is the step that ensures the use of your secure environment in all new environments that are created, and prevents anyone from creating an environment that doesn’t adhere to the security rules of your secure environment. Requiring the use of your template in the catalog ensures that the remaining security configurations of controls are prepared for audit.
Phase 4 – Perform validation activities. Deploying AWS through Service Catalog and the secure environment templates helps to create an audit-ready environment. The rules you define 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 secure environment rules. By using secure read access permissions, along with unique scripts, you can enable audit automation for evidence collection. You can convert traditional manual administrative controls to technically enforced controls with assurance that, if they are designed and scoped properly, the controls are operating 100 percent at any point in time, which is not possible with traditional audit sampling methods or point-in-time reviews.
This technical audit can be improved by pre-audit guidance, such as support and training for your auditors to ensure that audit personnel understand the unique audit automation capabilities that the AWS Cloud provides.
The SbD approach can achieve the following:
- Creation of forcing functions that cannot be overridden by users who aren’t allowed to modify those functions.
- Establishing reliable operation of controls.
- Enabling continuous and real-time auditing.
- Technical scripting of your governance policy.
The result is an automated environment that enables the security, assurance, governance, and compliance capabilities of your environment. You can now execute reliable implementation of what was previously only written in policies, standards, and regulations. Additionally, you can create enforceable security and compliance, which in turn creates a functional, reliable governance model for your AWS environments.