Reinterpreting the Essential Eight strategies for the cloud

The following are the original Essential Eight mitigation strategies that were designed for Microsoft-based internet-connected networks:

It is important to reiterate that the Essential Eight framework is not designed for cloud environments. However, the underlying principles are applicable, and there is overlap between the Essential Eight strategies and AWS Well-Architected Framework best practices.

Various cloud-native approaches can improve security and dramatically reduce your compliance burden. In on-premises environments, you are responsible for all aspects of security, and there are no inherited controls. When running workloads in the cloud, AWS is responsible for protecting the infrastructure that runs our services. You can also reduce your compliance burden by using automation and managed services. Managed services, also known as abstracted services, are AWS services for which AWS operates the infrastructure layer, the operating system, and platforms, and you access the endpoints to store and retrieve data. Amazon Simple Storage Service (Amazon S3) and Amazon DynamoDB are examples of managed services. For more information, see the Theme 1: Use managed services section in this guide.

Therefore, some reinterpretation is required to make the Essential Eight strategies appropriate for workloads on AWS. This guide converts the Essential Eight strategies into AWS themes.

Using the themes

This guide is divided into eight themes. Each Essential Eight strategy is mapped to one or more of the following themes, and each theme is mapped to one or more best practices in the AWS Well-Architected Framework:

Each theme includes an overview of the topic, related AWS Well-Architected Framework best practices, and instructions for how to achieve Essential Eight maturity and monitor compliance. The instructions provide manual steps or help you configure automations by using AWS Config rules. Manual steps require mechanisms to make sure that findings are addressed. For more information, see Theme 8: Implement mechanisms for manual processes. AWS Config rules require similar oversight or automation in order to remediate noncompliant resources. By following the guidance aligned with these themes, you can reach Essential Eight maturity with an approach that also maximises cloud benefits.

Reinterpreting the Essential Eight strategies for the cloud

Because the Essential Eight framework is not designed for cloud environments, it is essential to take a cloud-native approach when addressing the underlying principles of each Essential Eight strategy. The approach varies depending on two key questions.

Which services are you using?

The AWS shared responsibility model can help relieve your compliance and operational burdens. Managed services shift more responsibility to AWS for maintaining the availability, performance, and security optimisation of the deployed service. Managed services also remove the operational and administrative burden of maintaining a service, providing more time to focus on innovation.

Managed services include serverless services, such as Amazon API Gateway, AWS Lambda, and DynamoDB. A database on Amazon Relational Database Service (Amazon RDS) requires less operational responsibility than a database on Amazon Elastic Compute Cloud (Amazon EC2).

For example, if you're adapting the Patch operating systems Essential Eight strategy for the cloud, you need to consider which services you are using and whether you're responsible for patching those resources. AWS is responsible for patching fully managed services, such as Lambda and DynamoDB. For other services, such as Amazon RDS or Amazon Redshift, you might need to manage patches during maintenance windows.

What deployment model are you using?

Is your organization using a mutable or immutable infrastructure approach?

The mutable infrastructure model updates and modifies the existing infrastructure for production workloads. This was the standard deployment method before the cloud, when replacing server infrastructure was so costly and time-consuming that the most practical approach was to apply changes to servers already in production. An example of a mutable approach in the cloud is deploying application changes directly onto running EC2 instances, either manually or by using a software deployment service, such as AWS Systems Manager Run Command or AWS CodeDeploy.

The immutable infrastructure model deploys new infrastructure for production workloads instead of updating, patching, or modifying the existing infrastructure. An example of an immutable approach is defining an application stack in AWS CloudFormation or AWS Cloud Development Kit (AWS CDK). You can use these services to deploy an application stack through continuous integration and continuous delivery (CI/CD) pipelines. This approach uses deployment methods such as rolling or blue/green. For more information about this approach, see the Deploy using immutable infrastructure best practice in the AWS Well-Architected Framework.

For example, if you're adapting the Patch operating systems Essential Eight strategy for the cloud, you need to consider how patching applies to the deployment model. For mutable infrastructure, you can manually patch resources or could improve operational efficiency through automation. If you're using immutable infrastructure, then you'd use a CI/CD pipeline to deploy new infrastructure with the latest version of the operating system. In fact, the term patching is a misnomer under this model because the infrastructure would be replaced rather than patched.