# Indicative case study for reaching Essential Eight maturity on AWS This chapter presents an indicative case study for a government agency targeting Essential Eight maturity on AWS. **Topics** + [ # Scenario and architecture overview ](scenario.md) + [ # Workload example: Serverless data lake ](serverless-data-lake.md) + [ # Workload example: Containerised web service ](containerised-web-service.md) + [ # Workload example: COTS software on Amazon EC2 ](cots-software.md) # Scenario and architecture overview The government agency has three workloads in the AWS Cloud: + A [serverless data lake](serverless-data-lake.md) that uses Amazon Simple Storage Service (Amazon S3) for storage and AWS Lambda for extract, transform, and load (ETL) operations + A [containerised web service](containerised-web-service.md) that runs on Amazon Elastic Container Service (Amazon ECS) and uses a database in Amazon Relational Database Service (Amazon RDS) + A [commercial off-the-shelf (COTS) software](cots-software.md) running on Amazon EC2 A *cloud team* provides a centralised platform for the organisation, running core services for the AWS environment. A cloud team provides core services for the AWS environment. Each workload is owned by a distinct *application team*, also known as a *developer team* or *delivery team*. ## Core architecture The cloud team has already established the following capabilities in the AWS Cloud: + Identity federation links AWS IAM Identity Center to their Microsoft Entra ID (formerly *Azure Active Directory*) instance. The federation enforces MFA, automatic expiry of user accounts, and the use of short-lived credentials through AWS Identity and Access Management (IAM) roles. + A centralised AMI pipeline is used to patch OSs and core applications with EC2 Image Builder. + Amazon Inspector is enabled to identify vulnerabilities, and all security findings are sent to Amazon GuardDuty for centralised management. + Established mechanisms are used to update application control rules, respond to cyber security events, and review compliance gaps. + AWS CloudTrail is used for logging and monitoring. + Security events, such as login of the root user, initiate alerts. + SCPs and VPC endpoint policies establish data perimeters for your AWS environments. + SCPs prevent application teams from disabling security and logging services, such as CloudTrail and AWS Config. + AWS Config findings are aggregated from across the whole AWS organization into a single AWS account for security. + The AWS Config [ACSC Essential 8 conformance pack](https://docs.aws.amazon.com/config/latest/developerguide/operational-best-practices-for-acsc_essential_8.html) is enabled across all AWS accounts in your organization. # Workload example: Serverless data lake This workload is an example of [Theme 1: Use managed services](theme-1.md). The data lake uses Amazon S3 for storage and AWS Lambda for ETL. These resources are defined in an AWS Cloud Development Kit (AWS CDK) app. Changes to the system are deployed through AWS CodePipeline. This pipeline is restricted to the application team. When the application team makes a pull request for the code repository, the [two-person rule](https://docs.aws.amazon.com/wellarchitected/latest/analytics-lens/best-practice-5.2---implement-least-privilege-policies-for-source-and-downstream-systems..html) is used. For this workload, the application team takes the following actions to address the Essential Eight strategies. *Application control* + The application team enables [Lambda Protection](https://docs.aws.amazon.com/guardduty/latest/ug/lambda-protection.html) in GuardDuty and [Lambda scanning](https://docs.aws.amazon.com/inspector/latest/user/scanning-lambda.html) in Amazon Inspector. + The application team implements mechanisms to inspect and [manage Amazon Inspector findings](https://docs.aws.amazon.com/inspector/latest/user/findings-managing-automating-responses.html#findings-managing-eventbridge-tutorial). *Patch applications* + The application team enables Lambda scanning in Amazon Inspector and configures alerts for deprecated or vulnerable libraries. + The application team enable AWS Config to track AWS resources for asset discovery. *Restrict administrative privileges* + As described in the [Core architecture](scenario.md#core-architecture) section, the application team already restricts access to production deployments through an approval rule on their deployment pipeline. + The application team relies on the centralised identity federation and centralised logging solutions that are described in the [Core architecture](scenario.md#core-architecture) section. + The application team creates an AWS CloudTrail trail and Amazon CloudWatch filters. + The application team sets up Amazon Simple Notification Service (Amazon SNS) alerts for CodePipeline deployments and AWS CloudFormation stack deletions. *Patch operating systems* + The application team enables Lambda scanning in Amazon Inspector and configures alerts for deprecated or vulnerable libraries. *Multi-factor authentication* + The application team relies on the centralised identity federation solution described in the [Core architecture](scenario.md#core-architecture) section. This solution enforces MFA, logs authentications, and alerts on or automatically responds to suspicious MFA events. *Regular backups* + The application team stores code, such as AWS CDK apps and Lambda functions and configurations, in a [code repository](https://aws.amazon.com/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/). + The application team enables versioning and Amazon S3 Object Lock to help prevent objects from deletion or modification. + The application team relies on built-in Amazon S3 durability rather than replicating their entire dataset to another AWS Region. + The application team runs a copy of the workload in another AWS Region that meets their data sovereignty requirements. They use Amazon DynamoDB global tables and Amazon S3 [Cross-Region Replication](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html#crr-scenario) to replicate data automatically from the primary Region to the secondary Region. # Workload example: Containerised web service This workload is an example of [Theme 2: Manage immutable infrastructure through secure pipelines](theme-2.md). The web service runs on Amazon ECS and uses a database in Amazon RDS. The application team defines these resources in an CloudFormation template. Containers are created with EC2 Image Builder and stored in Amazon ECR. The application team deploys changes to the system through AWS CodePipeline. This pipeline is restricted to the application team. When the application team makes a pull request for the code repository, the [two-person rule](https://docs.aws.amazon.com/wellarchitected/latest/analytics-lens/best-practice-5.2---implement-least-privilege-policies-for-source-and-downstream-systems..html) is used. For this workload, the application team takes the following actions to address the Essential Eight strategies. *Application control* + The application team enables [scanning for Amazon ECR container images in Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/user/scanning-ecr.html). + The application team build the [File Access Policy Daemon (fapolicyd)](https://github.com/linux-application-whitelisting/fapolicyd/blob/main/README.md) security tool into the EC2 Image Builder pipeline. For more information, see [Implementing Application Control](https://www.cyber.gov.au/resources-business-and-government/maintaining-devices-and-systems/system-hardening-and-administration/system-hardening/implementing-application-control) on the ACSC website. + The application team configures the Amazon ECS task definition to log output to Amazon CloudWatch Logs. + The application team implements mechanisms to inspect and manage Amazon Inspector findings. *Patch applications* + The application team enables scanning for Amazon ECR container images in Amazon Inspector and configures alerts for deprecated or vulnerable libraries. + The application team automates their responses to Amazon Inspector findings. New findings initiate their deployment pipeline through an Amazon EventBridge trigger, and CodePipeline is the target. + The application team enables AWS Config to track AWS resources for asset discovery. *Restrict administrative privileges* + The application team is already restricting access to production deployments through an approval rule on their deployment pipeline. + The application team relies on the centralised cloud team's identity federation for rotation of credentials and centralised logging. + The application team creates a CloudTrail trail and CloudWatch filters. + The application team sets up Amazon SNS alerts for CodePipeline deployments and CloudFormation stack deletions. *Patch operating systems* + The application team enables scanning for Amazon ECR container images in Amazon Inspector and configures alerts for OS patch updates. + The application team automates their response to Amazon Inspector findings. New findings initiate their deployment pipeline through an EventBridge trigger, and CodePipeline is the target. + The application team subscribes to Amazon RDS event notifications so that they are informed about updates. They make a risk-based decision with their business owner about whether to apply these updates manually or let Amazon RDS apply them automatically. + The application team configures the Amazon RDS instance to be a multi-Availability Zone cluster in order to reduce the impact of maintenance events. *Multi-factor authentication* + The application team relies on the centralised identity federation solution described in the [Core architecture](scenario.md#core-architecture) section. This solution enforces MFA, logs authentications, and alerts on or automatically responds to suspicious MFA events. *Regular backups* + The application team configures AWS Backup to automate backup of the data their Amazon RDS cluster. + The application team stores CloudFormation templates in a code repository. + The application team develops an automated pipeline to [create a copy of their workload in another Region and run automated tests](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/) (AWS blog post). After the automated tests run, the pipeline destroys the stack. This pipeline automatically runs once a month and validates the effectiveness of the recovery procedures. # Workload example: COTS software on Amazon EC2 This workload is an example of [Theme 3: Manage mutable infrastructure with automation](theme-3.md). The workload running on Amazon EC2 was created manually by using the AWS Management Console. Developers manually update the system by logging into the EC2 instances and updating the software. For this workload, the cloud and application teams take the following actions to address the Essential Eight strategies. *Application control* + The cloud team configures their centralised AMI pipeline to install and configure AWS Systems Manager Agent (SSM Agent), CloudWatch agent, and SELinux. They share the resulting AMI across all accounts in the organization. + The cloud team uses AWS Config rules to confirm that all running [EC2 instances are managed by Systems Manager](https://docs.aws.amazon.com/config/latest/developerguide/ec2-instance-managed-by-systems-manager.html) and have [SSM Agent, CloudWatch agent, and SELinux installed](https://docs.aws.amazon.com/config/latest/developerguide/ec2-managedinstance-applications-required.html). + The cloud team sends Amazon CloudWatch Logs output to a centralised security information and event management (SIEM) solution that runs on Amazon OpenSearch Service. + The application team implements mechanisms in order inspect and manage findings from AWS Config, GuardDuty, and Amazon Inspector. The cloud team implements their own mechanisms to catch any findings that the application team misses. For more guidance about creating a vulnerability management program to address findings, see [Building a scalable vulnerability management program on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/vulnerability-management/introduction.html). *Patch applications* + The application team patches instances based on Amazon Inspector findings. + The cloud team patches the base AMI, and the application team receives an alert when that AMI changes. + The application team restricts direct access to their EC2 instances by configuring [security group rules](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html) to allow traffic only on the ports that the workload requires. + The application team uses [Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html) to patch instances instead of logging in to individual instances. + To run arbitrary commands on groups of EC2 instances, the application team uses [Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html). + On the rare occasions when the application team needs direct access to an instance, they use [Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html). This access approach uses federated identities and logs any session activity for audit purposes. *Restrict administrative privileges* + The application team configures [security group rules](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html) to allow traffic only on the ports that the workload requires. This restricts direct access to Amazon EC2 instances and requires that users access EC2 instances through Session Manager. + The application team relies on the centralised cloud team's identity federation for rotation of credentials and centralised logging. + The application team creates a CloudTrail trail and CloudWatch filters. + The application team sets up Amazon SNS alerts for CodePipeline deployments and CloudFormation stack deletions. *Patch operating systems* + The cloud team patches the base AMI, and the application team receives an alert when that AMI changes. The application team deploys new instances by using this AMI, and then they use [State Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state.html), a capability of Systems Manager, to install required software. + The application team uses Patch Manager to patch instances, instance of logging in to individual instances. + To run arbitrary commands on groups of EC2 instances, the application team uses Run Command. + On the rare occasions when the application team needs direct access, they use Session Manager. *Multi-factor authentication* + The application team relies on the centralised identity federation solution described in the [Core architecture](scenario.md#core-architecture) section. This solution enforces MFA, logs authentications, and alerts on or automatically responds to suspicious MFA events. *Regular backups* + The application team creates an AWS Backup plan for its EC2 instances and Amazon Elastic Block Store (Amazon EBS) volumes. + The application team implements a mechanism to perform a backup restoration manually every month.