Patch Your S_it with Amazon Systems Manager

You can patch your EC2 systems and run SSM in a few easy steps.

But first, why should you use SSM?

1. ‍It’s a fully managed service
2. ‍It’s integrated with IAM and Cloudtrail provides access control and auditing.
3. It provides hooks to Lambda enabling integration with incident management solutions such as JIRA or Service Now.
4. There is no cost to the customer.

SSM provides a range of helpful features, but today, we are going to focus on State Manager, which is a sub component of SSM, simple to use and enables you to patch hosts in AWS.

To get started with State Manager you need to do the following:

For Redhat Enterprise Linux (RHEL) users start at Step 1. For those using Amazon Linux or Windows, step 1 has already been done by Amazon so start at Step 2.

Step 1)  You need to install the agent as per Manually Install SSM Agent on RHEL Linux Instances.

Step 2)  Configure your EC2 host with an IAM instance profile as per Create an Instance Profile for Systems Manager.

Step 3)  Deploy the following cloudformation template to configure State Manager.

Description: This deploys SSM State Manager which updates SSM agent/patch baseline based on tags.

Resources:

PatchBaselineScan:
Type: “AWS::SSM::Association”
Properties:
AssociationName: PatchBaselineScan
Name: AWS-RunPatchBaseline
Parameters:
Operation:
– “Scan”
ScheduleExpression: rate(30 minutes)
Targets:
– Key: “tag:PatchBaseline”
Values:
– “scan”

PatchBaselineInstall:
Type: “AWS::SSM::Association”
Properties:
AssociationName: PatchBaselineInstall
Name: AWS-RunPatchBaseline
Parameters:
Operation:
– “Install”
ScheduleExpression: rate(30 minutes)
Targets:
– Key: “tag:PatchBaseline”
Values:
– “install”

UpdateSSMAgent:
Type: “AWS::SSM::Association”
Properties:
AssociationName: UpdateSSMAgent
Name: AWS-UpdateSSMAgent
Parameters:
allowDowngrade:
– “false”
ScheduleExpression: rate(30 minutes)
Targets:
– Key: “tag:UpdateSSMAgent”
Values:
– “true”

Note: To use the SSM service your EC2 Instances will need access to the internet, either via NAT a using a proxy server.

Once you have followed these steps you should see some EC2 Instances appear in the inbuilt inventory as per the diagram below.

EC2 Managed Instances

At Versent, our preference is to opt-in using tags on our EC2 Instances which tell State Manager to patch these hosts.

Once you have applied some tags to your EC2 Instances, this is what you should see.

EC2 SSM Tags Assigned to Instance

If you have followed these steps correctly, after a short delay (up to 30 minutes) you should see your EC2 Instances are now patched and compliant.

EC2 Inventory

Note: Based on the default baselines, patches for Windows and RHEL have an approval rule applied which holds back patches for 7 days, which is recommended by Amazon. Custom baselines with their own approval rules can be implemented if you have existing policies.

Systems Manager makes patching your systems simple and is provided FREE by Amazon.

If you need help implementing AWS SSM, or just want to have a chat about patching your S_it, drop us a line info@versent.com.au.

Further reading for those interested:

1. Enable SSM for on premise servers to enable assessment prior to migration.
2. Add SSM associations to deploy and run Amazon Inspector.
3. ‍Configure Guardduty to provide insights into external/internal threats to your EC2 hosts.

Mark ‘Wolfie’ Wolfe is the Practice Director for Cloud at Versent in Melbourne. He has worked in operations and development on the AWS cloud platform for five years. His expansive career has seen him wear the hat of CTO, developer, DBA and network engineer in a range of consulting and start-up companies. When he’s not building applications in or on AWS, you can probably find him working on his endless self-driving car project or riding his mountain bike out in the Dandenongs.