Security-Driven Cloud Acceleration (SDCA) is a security solution built on infrastructure-as-code (IaC) templates that embeds core Amazon Web Services (AWS) security earlier in the customer journey into any workload, program, and industry solution in alignment with the AWS Cloud Adoption Framework, AWS Well-Architected Framework, and AWS Security Best Practices.
The goal of SDCA is to help reduce friction for customers to “shift-left and automate” with strong security earlier in their journey. SDCA simplifies improving security posture by applying the minimum AWS security to accelerate a secure-by-design, defense-in-depth strategy across any workload, program or industry solution. SDCA can be used by customers and partners to create a secure landing zone during migrations and/or be secure foundation for cloud native development. By making it easier, faster, and less expensive to automate security posture improvements while embedding this with core workload services, SDCA will further increase customer confidence that AWS is the most secure cloud for innovation.
SDCA is an embeddable set of free-to-use IaC templates for CISOs, security teams, software developers, solutions architects, infrastructure teams, and partners to increase security posture, simplify and accelerate the implementation of core AWS security services and automate their best practices, helping customers save time, money, and frustration. The templates are built upon the continuously improving AWS Security Reference Architecture (SRA), a stable, proven and comprehensive library of AWS security best practices. They simplify the usage to just the minimum recommended security services for any workload, any account, and any customer. By leveraging infrastructure as code, customers benefit from faster time-to-market, time-to-value, automating security policy-as-code into their devops lifecycles, increasing governance and observability into their security posture and policies, simplifying audits and compliance, and reducing costs, time, and risk associated to security events.
The primary deliverable of SDCA is a set of infrastructure-as-code (IaC) templates available in both AWS CloudFormation and HashiCorp Terraform formats, the two most popular formats for automating security policy as code. These templates are available for free on the AWS Samples GitHub account. These templates can be embedded into any other CloudFormations or Terraform offerings to allow customers to consistently automate security best practices in workloads and DevOps pipeline. Estimated time to complete ranges from 15-45 minutes depending on workload and configuration complexity. Once implemented, customers can automate Git pulls of the latest code updates and security best practices of the AWS SRA.
The following AWS services and best practices are the primary focus of the SDCA program:
- AWS Security Hub for cloud security posture management (CSPM) to perform security best practice checks, aggregate alerts, and enable automated remediation.
- Amazon GuardDuty (including optional protections for S3, EKS, RDS, Malware, and Lambda) for intelligent threat detection that continuously monitors your AWS accounts and workloads for malicious activity and delivers detailed security findings for visibility and remediation.
- Amazon Key Management Service (KMS) for creating, managing, and controling cryptographic keys across your applications and AWS services.
- AWS Shield Advanced for managed DDoS protection that safeguards applications running on AWS.
The following services and solutions may used in the provisioning and usage of SDCA, but are not primary focus of the program.
- AWS Security Reference Architecture (SRA) (as the engine of security best practices recommendations and configurations)
- AWS CloudFormation and/or HashiCorp Terraform IaC formats (the two most popular IaC formats)
- AWS Config (for Conformance Packages)
- AWS CloudTrail (for logging and GuardDuty threat detection analysis)
- AWS CodeBuild (for automated building of the SDCA stack and Security Reference Architecture code)
- AWS Control Tower (optional for customers who want to consistently apply SDCA to all or mutliple accounts in their organization)
- AWS Lambda (for automated building of the SDCA stack and Security Reference Architecture code)
- Amazon S3 (used to create a staging bucket and for configuring logs)
The following AWS services are NOT enabled by the SDCA sample code, but are included in the price of AWS Shield Advanced. These may be enabled in the future by the SDCA templates, but for now must be done manually in AWS Console or AWS CLI.
The following AWS services are strongly encouraged for use in parallel:
- AWS Trusted Advisor
- AWS Well-Architected Tool with AWS Trusted Advisor integration
The IaC template is built upon the AWS Security Reference Architecture (SRA), and consists of a modular bundle of five configuration files, one for each of the four core security domain services, plus one main configuration file. In the main file, customers can configure high-level setting such as whether they want this to run on a single workload, account, or entire organization (optionally, AWS Control Tower can be used), what AWS region(s) they would like this to run in, and which AWS Config Conformance Packs they would like to apply (such as CIS AWS Foundations, NIST 800-53 rev 5, HIPAA, FedRamp Moderate, NIST Privacy Framework v1.0, European Union Agency for Cybersecurity (ENISA) Cybersecurity Guide for SMEs, and many more) together. Any additional configuration parameter entered in the Cloudformation or Terraform templates will override the default settings, which makes these templates an platform for customers to start to adopt and adapt security policy-as-code throughout their organization.
Detailed instructions coming soon!
As with most other AWS solutions, customers only pay for what they use. To further make it easier for customers to adopt SDCA as a starting point for their security journey, there is no cost to use the CloudFormation or Terraform scripts. The AWS services enabled by default in the scripts offer free tiers and trials for 30 days, with the exception of AWS Shield Advanced has a different pricing model, and is therefore disabled by default until customers are ready to try it or commit. Additionally, ask your Account Manager about the "AWS Shields Up!" promotion which can help offset the cost and commitment of AWS Shield Advanced for up to 60 days. Customers should use the AWS Pricing Calculator to estimate the costs for their individual workloads prior to enablement. NOTE: AWS Shield Advanced comes with DDoS cost protection to safeguard against scaling charges resulting from DDoS-related usage spikes on protected Amazon EC2, AWS Elastic Load Balancer (ELB), Amazon CloudFront, AWS Global Accelerator, and Amazon Route 53 resources, which may offset other costs. If any of these protected resources scale up in response to a DDoS attack, you can request Shield Advanced service credits through your regular AWS Support channel.
A: To get the maximium benefits for SDCA, it should be applied as early as possible in the design, architecture for any "shift-left" and secure-by-design initiative. It can, however, be added to existing workloads without impacting functionality or performance.
- Customers should strongly consider first performing a threat modeling exercise to identify and evaluate vulnerabilities, threats, and risks, identify the likelihood that each threat will succeed, and assesses the organization’s ability to respond to each identified threat. Consider enrolling your team in AWS's "Threat Modeling The Right Way For Builders" course for free on SkillBuilder.
- Customers should then baseline their current security posture with tools such as AWS Trusted Advisor and AWS Well-Architected Tool (with AWS Trusted Advisor integration).
- Then use SDCA templates as part of the design, architecture, provisioning, and any corrective actions phases to provide the minimum security coverage across the core AWS Security domains of data protection, network and application protection, threat detection and incident response, and privacy and governance.
- Reassess the security baseline for security posture score improvements and further security findings.
- Continue to increase the security posture through incremental iterative improvements based on security findings in AWS Security Hub, AWS Trusted Advisor, and AWS Well-Architected Tool.
- Repeat regularly.
A: To provide an effective defense-in-depth strategy, customers must employ multiple layers of security controls to help protect data and workloads. In the event that a security threat bypasses or compromises one layer of security, another layer of independent protection helps guard against potential threats, ensuring that at least two or more controls must fail before a system is compromised. This can deter or slow down a threat actor, buying time to isolate the threat and remediate vulnerabilities to minimize risk and damage. When used in conjunction with fine-grained least-privledge access policies with AWS Identity and Access Management (IAM), each of these core security services represent the minimum security recommendations from AWS Security across the core security domains of Data Protection (Amazon Key Management Service (KMS)), Network & Application Protection (AWS Shield Advanced), Threat Detection & Incident Response (Amazon GuardDuty), and Privacy & Governance (AWS Security Hub). Additionally, when customers opt-in to enable AWS Shield Advanced, they get AWS WAF and AWS Firewall Manager included in the price, which provides additional defense-in-depth functionality, cost protections, and cost savings for the Network & Application Protection domain.
A: Customers can measure the impact of using Security-Driven Cloud Acceleration through a variety of metrics such as:
- Increased customer security posture through measuring AWS Trusted Advisor scores and reduced AWS Security Hub alert severity and volumes.
- Reduction in time and costs associated to account and service provisioning, data and infrastructure protection, Mean Time To Detection (MTTD) and Mean Time To Respond (MTTR), Mean Time To Contain (MTTC), and Mean Time To Recover (MTTR) through cloud security automation.
- AWS Shield Advanced comes with DDoS cost protection to safeguard against scaling charges resulting from DDoS-related usage spikes on protected Amazon EC2, AWS Elastic Load Balancer (ELB), Amazon CloudFront, AWS Global Accelerator, and Amazon Route 53 resources.
- Compression of migration timelines, account creation, service activation, development and testing cycles, and security best practices enablement through cloud security automation.
A: The proof-of-concept (POC) was released on August 17th, 2023. It includes 87.5% of the functionality intended as it is still missing the CloudFormation templates for automating AWS Shield Advanced, but all functionality for Terraform is avialable today. These will be available in the General Availability (GA) release at the end of January 2024 with the completion of the AWS Shield Advanced module for CloudFormation, however if customers want to enable AWS Shield Advanced today for CloudFormation-driven workloads, they can still do so manually in AWS Console and AWS CLI. Customers can begin testing with the current version today to get familiar with the process and to adapt the templates to their workloads and organizational needs. Now also includes option to use AWS Control Tower or not, providing maximum flexibility on deploying to a single workload or across an entire organization.
- AWS Shield Advanced for CloudFormation is not yet complete. We are anticipating this to be ready by 1/31/2024. In the meantime as a workaround, customers can manually subscribe to AWS Shield Advanced in the Console and choose the workloads that they would like to be protected. Once this is available in CloudFormation, it will automatically enforce any configuration settings that may already exist.
- The AWS Config module for SRA is not yet complete. When it launches, it will only support a single conformance package. A feature request has been submitted to supporrt multiple conformance packages. In the menatime as a workaround, customers can manually configure these once in AWS Config in the AWS Console, and Security Hub will automatically begin to enforce it.
A: Yes! If you have feedback and suggestions for how to further improve these templates, fork the repo and submit a pull request. All submissions will be reviewed and evaluated by the AWS Security Reference Architecture team. Read the AWS contribution guidelines for this project.
For further information and to stay informed of general availability releases, contact Christopher Rae (xrae@amazon.com), Principal Worldwide Security GTM Specialist at Amazon Web Services.