Workload example: COTS software on Amazon EC2 - AWS Prescriptive Guidance

Workload example: COTS software on Amazon EC2

This workload is an example of Theme 3: Manage mutable infrastructure with automation.

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 and have SSM Agent, CloudWatch agent, and SELinux installed.

  • 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.

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 to allow traffic only on the ports that the workload requires.

  • The application team uses Patch Manager 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.

  • On the rare occasions when the application team needs direct access to an instance, they use Session Manager. This access approach uses federated identities and logs any session activity for audit purposes.

Restrict administrative privileges

  • The application team configures security group rules 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, 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 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.