Amazon Web Services Feed
Quickly build STIG-compliant Amazon Machine Images using Amazon EC2 Image Builder

In this post, we discuss how to implement the operating system security requirements defined by the Defence Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs).

As an Amazon Web Services (AWS) customer, you can use Amazon Machine Images (AMIs) published by AWS or APN partners. These AMIs, which are owned and published by AWS, are pre-configured based on a variety of standards to help you quickly get started with your deployments while helping you follow your required compliance guidelines. For example, you can use AMIs that have been preconfigured for you per STIG standards. You can also use Amazon Elastic Compute Cloud (Amazon EC2) Image Builder to automate configuration of any custom images imported from an on-premises system.

Organizations of all sizes are moving more and more of their workloads to AWS. In most enterprises and organizations, often starting with an AMI with a known configuration is the best way to address the organization’s security requirements for operating system configuration. You can take advantage of the tools available in AWS to ensure this is a consistent and repeatable process.

If you want to use your own custom AMI, you can follow the steps in this post to see how to build a golden Windows operating system image that follows STIG compliance guidelines using Amazon EC2 Image Builder.

Image Builder

We understand that keeping server images hardened and up to date can be time consuming, resource intensive, and subject to human error if performed manually. Currently, customers either manually build the automation scripts to implement STIG security measures to harden the server image, or procure, run, and maintain tools to automate the process to harden the golden image.

Image Builder significantly reduces the effort of keeping images STIG-compliant and updated by providing a simple graphical interface, built-in automation to match the STIG requirements, and AWS-provided security settings. With Image Builder, there are no manual steps needed to update an image, nor do you have to build your own automation pipeline.

Customers can use Image Builder to build an operating system image for use with Amazon EC2, as well as on-premises systems. It simplifies the creation, maintenance, validation, sharing, and deployment of Linux and Windows Server images. This blog post discusses how to build a Windows Server golden image.

Image Builder is provided at no cost to customers and is available in all commercial AWS regions. You’re charged only for the underlying AWS resources that are used to create, store, and share the images.

What is a STIG?

STIGs are the configuration standards submitted by OS or software vendors to DISA for approval. Once approved, the configuration standards are used to configure security hardened information systems and software. STIGs contain technical guidance to help secure information systems or software that might otherwise be vulnerable to a malicious attack.

DISA develops and maintains STIGs and defines the vulnerability Severity Category Codes (CAT) which are referred to as CAT I, II, and III.

Severity category code DISA category code guidelines
CAT I Any vulnerability, the exploitation of which will directly and immediately result in loss of confidentiality, availability, or integrity.
CAT II Any vulnerability, the exploitation of which has a potential to result in loss of confidentiality, availability, or integrity.
CAT III Any vulnerability, the existence of which degrades measures to protect against loss of confidentiality, availability, or integrity.

For a complete list of STIGs, see Windows 2019, 2016, and 2012. How to View SRGs and STIGs provides instructions for viewing the lists.

Image Builder STIG components

To make your systems compliant with STIG standards, you must install, configure, and test a variety of security settings. Image Builder provides STIG components that you can leverage to quickly build STIG-compliant images on standalone servers by applying local Group Policies. The STIG components of Image Builder scan for misconfigurations and run a remediation script. Image Builder defines the STIG components as low, medium, and high, which align with DISA CAT I, II, and III respectively (with some exceptions as outlined in Windows STIG Components).

Building a golden Windows Server image using STIG-compliance guidelines

Image Builder can be used with the AWS Management Console, AWS CLI, or APIs to create images in your AWS account. In this example, we use AWS console that provides a step-by-step wizard covering the four steps to build a golden image that follows STIG compliance guidelines. A graphical representation outlining the process is provided below, followed by a description of the steps to build the image.
 

Figure 1: Image Builder Process

Figure 1: Image Builder Process

Step 1: Define the source image

The first step is to define the base OS image to use as the foundation layer of the golden image. You can select an existing image that you own, an image owned by Amazon, or an image shared with you.

Define image recipe

Open the console and search for Image Builder service. Under EC2 Image Builder, select Recipe on the left pane. Select the Create recipe button on the top right corner. Enter a Name, Version, and Description for your recipe, as shown in Figure 2.
 

Figure 2: Name and describe the image recipe

Figure 2: Name and describe the image recipe

Select source image

Select a source image for your golden image.

  1. Under Source image, select Windows as the image operating system.
  2. For this example, choose Select managed images. A managed image is an Image-Builder-managed image created by you, shared with you, or provided by AWS.
  3. Select Browse images to choose from available images. In the screenshot below, I’ve selected a Windows Server 2016 image provided by AWS.

 

Figure 3: Select source image

Figure 3: Select source image

Step 2: Build components

You can create your own components using scripts to add or remove software or define the OS configuration along with the required answer files, scripts, and settings from registered repositories and Amazon Simple Storage Service (Amazon S3) buckets. AWS provides pre-defined components for regular updates as well as security settings: for example, STIG, Amazon Inspector and more.

Select Browse build components and then select the STIG component that has the latest version or the one that meets your requirements. You can choose more than one component to perform the desired changes to your golden image as shown in the screenshot below.
 

Figure 4: Select build components

Figure 4: Select build components

Step 3: Select tests

You can define your own tests based on the level of the compliance required for your specific workload. You can also use AWS-provided tests to validate images before deployment. At the time of writing this blog AWS-provided tests do not include pre-canned tests to validate STIG configuration. For Windows, custom tests are written in PowerShell. In the screenshot below, I’ve added an AWS-provided test to validate Windows activation.
 

Figure 5: Select tests

Figure 5: Select tests

Once done, select Create Recipe.

Step 4: Create pipeline and distribute images

The last step triggers creation of the golden image and distributes the output AMI to selected AWS Regions and AWS accounts.

Create pipeline

  1. Select the recipe that we just created and select Create pipeline from this recipe from the Actions menu in the upper right corner.
     
    Figure 6: Select create pipeline from Actions menu

    Figure 6: Select create pipeline from Actions menu

  2. Enter a pipeline Name and Description. For the IAM role, you can use the dropdown menu to select an existing IAM role. The best practice is to use an IAM role with least privileges necessary for the task.
     
    Figure 7: Pipeline details

    Figure 7: Pipeline details

    If you don’t want to use an existing IAM role, select Create new instance profile role and refer to the user guide to create a role. In the screenshot below I’ve defined a custom policy called ImageBuilder-S3Logs for Amazon S3 to perform limited operations. You can use an AWS managed policy to grant write access to S3 or customise the policy to fit to your organisation’s security requirements. If you choose to customize the policy, the instance profile specified in your infrastructure configuration must have s3:PutObject permission for the target bucket. A sample Amazon S3 policy that grants write access to imagebuilderlog bucket is provided below for your convenience. Please change the bucket name if you are going to use the sample policy.
     

    Figure 8: IAM Policy for SSM

    Figure 8: IAM Policy for SSM

    
    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": [ "arn:aws:s3:::imagebuilderlog/*", "arn:aws:s3:::imagebuilderlog" ] } ]
    }
    
  3. Build a schedule to define the frequency at which the pipeline produces new images with the specific customisation defined in steps 1 through 3. You can either choose to run it manually or define a schedule using schedule builder or CRON expression in the Create Pipeline wizard.
  4. Infrastructure Settings will allow Image Builder to launch an Amazon EC2 instance to customise the image. This is an optional step; however, it’s recommended to configure the infrastructure settings. If you don’t provide an entry, AWS chooses service specific defaults. Infrastructure setting allows you to specify the infrastructure within which to build and test your image. You can specify instance type, subnet, security group to associate with the instance that Image Builder uses to capture and build the image.

    Image Builder requires communication with AWS Systems Manager (SSM) Service endpoint to capture and build the image. The communication can happen over public internet or using a VPC endpoint. In both cases, the Security Group must allow SSM Agent running on the instance to talk to Systems Manager. In this example, I’ve used SSM endpoint for the Image Builder instance to communicate with Systems Manager. This article provides details on how to configure endpoints and security group to allow SSM Agent communication with Systems Manager.
     

    Figure 9: Optional infrastructure settings

    Figure 9: Optional infrastructure settings

Distribute image

Image distribution is configured in the Additional Settings section of the wizard which also provides options to associate license configuration using AWS License Manager and assign a name and tags to the output AMI.

To distribute the image to another AWS Region, choose the target Region from the drop-down menu. The current Region is included by default. In addition, you can add AWS user account numbers to set launch permission for the output AMI. Launch permissions allow specific AWS user account(s) to launch the image in the current Region as well as other Regions.
 

Figure 10: Image distribution settings

Figure 10: Image distribution settings

Optionally, you can leverage AWS License Manager to track the use of licenses and assist in preventing a licensing breach. You can do so by associating the license configuration with the image. License configuration can be defined in License Manager. Finally, define the output AMI details.

Select Review to review the pipeline configuration, and then select Create Pipeline to create the pipeline.
 

Figure 11: Review pipeline configuration

Figure 11: Review pipeline configuration

Once the pipeline is created you can create the golden image instantly by selecting Run Pipeline under Actions. You could also configure a schedule to create a new golden image at regular time intervals. Scheduling the pipeline allows Image Builder to automate your ongoing image maintenance process, for example, monthly patch updates.

Optionally, you can select an Amazon Simple Notification Service (Amazon SNS) topic in the configuration section of the pipeline. This way you can get automated notification alerts on progress of your build pipeline. These notification enables you to build further automation in your operations. For example, you could trigger automatic redeployment of application using the most recent golden image.
 

Figure 12: Run pipeline

Figure 12: Run pipeline

Summary

In this post, we showed you how to build a custom Windows server golden image that you can leverage to follow STIG compliance guidelines using Amazon EC2 Image Builder. We used the EC2 Image Builder console to define the source OS image, define software and STIG component, configure test cases, create and schedule an image build pipeline and distribute the image to AWS user and region. Alternatively, you can leverage AMI published by AWS or APN partners to help meet your STIG compliance standards. More details on AWS published AMIs can be found in this link.

Image Builder is a powerful tool that is offered at no cost, other than the cost of the underlying AWS resources used to create, store, and share the images. It automates tasks associated with the creation and maintenance of security hardened server images. In addition, it offers pre-configured components for Windows and Linux that customers can leverage to meet STIG compliance requirements.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the Amazon EC2 forum or contact AWS Support.

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.

Author

Sepehr Samiei

Sepehr is a Senior Microsoft Tech Specialized Solutions Architect at AWS. He started his professional career as a .Net developer, which continued for more than 10 years. Early on, he quickly became a fan of cloud computing and he loves to help customers use the power of Microsoft tech on AWS. His wife and daughter are the most precious parts of his life.

Author

Garry Singh

Garry Singh is a solutions architect at AWS. He provides guidance and technical assistance to help customers achieve the best outcomes for Microsoft workloads on AWS.