If you work for the government or are familiar with TLA (Three Letter Acronyms, i.e. FBI, CIA, WTF. etc.) then you know what this blog is about. If not, it is about automating your deployment to the cloud and knowing there is some level of security applied to the instance and your data is encrypted.
To set the stage, let’s define the TLAs in the title:
- STIG: The Security Technical Implementation Guides (STIGs) are the configuration standards for DOD IA and IA-enabled devices/systems. Since 1998, DISA has played a critical role enhancing the security posture of DoD’s security systems by providing the Security Technical Implementation Guides (STIGs). The STIGs contain technical guidance to “lock down” information systems/software that might otherwise be vulnerable to a malicious computer attack. https://iase.disa.mil/stigs/Pages/index.aspx
- SCAP: The Security Content Automation Protocol (SCAP) is a synthesis of interoperable specifications derived from community ideas. Community participation is a great strength for SCAP, because the security automation community ensures the broadest possible range of use cases is reflected in SCAP functionality. This Web site is provided to support continued community involvement. From this site, you will find information about both existing SCAP specifications and emerging specifications relevant to NIST’s security automation agenda. You are invited to participate, whether monitoring community dialog or leading more substantive activities like specification authorship. https://scap.nist.gov/
- AWS: Amazon Web Services (AWS) is a secure cloud services platform, offering compute power, database storage, content delivery and other functionality to help businesses scale and grow. Explore how millions of customers are currently leveraging AWS cloud products and solutions to build sophisticated applications with increased flexibility, scalability and reliability. https://aws.amazon.com/what-is-aws/
Securing to a standard
When a secure and compliant (to NIST and DISA standards) instance of Linux is desired in AWS, it can be a challenge knowing where to start. The standard encompasses filesystem layout, default configuration of the operating system, permissions on files and other bits. Below is one way to accomplish the task for CentOS or Red Hat Enterprise Linux (RHEL). This should work for other distributions with minor changes.
How to Succeed
For STIG compliance, the file system needs to meet a specific layout. Luckily there is a public image (search for Public Images “spel-minimal-centos-7”; ami-a6ffeddc as of March 2018) that meets the requirement. There is a cost to use the image; you have been advised. You can instantiate the amazon machine image (AMI), modify the instance, save it and use that as base image for your secure instances.
The public AMI is a good starting place, but you may want to have an AMI in your account with an encrypted disk. This requires launching the public AMI, stopping it, converting to an AMI in your account and then encrypting the disk and saving as another AMI. I have included a bash script (provided by Jared Short) to automate the creation of an AMI with an encrypted in your account.
CODE SNIPPET GOETH HERE
I use ansible to provision and configure my AWS instances. The playbooks use the ec2 module to deploy from the AMI and other modules to install and configure software. For instance I might install apache and pull a website from a source code management (SCM). After configuring the instance, I use an ansible role to apply the STIG. There are two roles available:
I currently use the MindPointGroup role. You can change the level of compliance you desire and if you want the role to apply changes. By default, the role audits and corrects CAT I, II and III findings. When the role completes, you have an instance that is providing the desired functionality and is STIG compliant to CAT I, II and III.
To check SCAP, there are tools provided by Red Hat that are easy to use on RHEL and CentOS. It requires installing two packages with their dependencies and running a command with options. The output can be saved as HTML and viewed interactively to determine compliance. The HTML page allows you to filter and see what failed and how to remediate. My experience is there are false positives, so please run the test to see if it is an error or not.
SECOND CODE BLOCK WUZ HEER
The file scan-xccdf-report.html is an interactive webpage to see the results of the security compliance scan.
I hope you find this a concise document on how to deploy an instance in AWS that meets STIG compliance.
I’m glad you like the MindPoint Group role. Not sure if you’re aware but that role is a part of a larger effort under an umbrella project called ansible-lockdown https://github.com/ansible/ansible-lockdown. We even have CIS in there.
I’ve been using the MindPoint Group roles for RHEL (their Windows one is apparently innoperable) but doesn’t it make a lot more sense to use the OSCAP tool to generate the complete set of tests and remediation actions? For example:
oscap xccdf generate fix –fix-type ansible –result-id xccdf_org.open-scap_testresult_xccdf_org.ssgproject.content_profile_stig-rhel7-disa –output stig-playbook-result.yml results.xml