Over the past few years Red Hat's Ansible has taken the IT automation world by storm. For sure there are other automation technologies that are better or more performant within certain niches. As a general-purpose, one-size-fits-most automation solution, Ansible is the dominant technology.
One area where Ansible is underrated is in the world of compliance. Many controls within the various regulatory and compliance bodies such as HIPAA, PCI, SOC2, FedRAMP, and others demand certain ‘things’ to be true in a technical sense. These technical controls can be mostly or entirely resolved by Ansible depending on the nuances of a particular environment.
What is FedRAMP?
For the uninitiated, FedRAMP is a compliance standard that applies to cloud service providers (CSPs), think *aaS, that wish to solicit business from Federal agencies. To give an example, suppose you make a really spectacular To-Do list application that is provided as a SaaS. Now imagine that you want the fine folks at NASA to be able to use your application…all you have to do is get through a FedRAMP audit. Keep in mind, FedRAMP is probably the most challenging (and expensive) compliance standard to adhere to, with over 400 unique controls and a multi-step process to make sure all of your ducks are in a row. If you really want to learn more about FedRAMP you can do so on the official FedRAMP website.
How does Ansible Fit?
Before we get into a detailed example, let’s talk about how to identify places where Ansible can fit into your solution for a given control. The entire list of controls for what is called a ‘Moderate’ system can be found in the FedRAMP System Security Plan Template. For many controls there are keywords that are very strong indicators that Ansible will be able to help, in part or in whole, to satisfy the control. For example, words like ‘automatically’ or ‘configuration’ are strong indicators that Ansible would be a good fit. Let’s take a look at the literal text of one control.
Baseline Configuration | Automation Support for Accuracy / Currency
The organization employs automated mechanisms to maintain an up-to-date, complete, accurate, and readily available baseline configuration of the information system.
Supplemental Guidance: Automated mechanisms that help organizations maintain consistent baseline configurations for information systems include, for example, hardware and software inventory tools, configuration management tools, and network management tools. Such tools can be deployed and/or allocated as common controls, at the information system level, or at the operating system or component level (e.g., on workstations, servers, notebook computers, network components, or mobile devices). Tools can be used, for example, to track version numbers on operating system applications, types of software installed, and current patch levels. This control enhancement can be satisfied by the implementation of CM-8 (2) for organizations that choose to combine information system component inventory and baseline configuration activities.
Related to: CM-7, RA-5
For those already well grounded in Ansible-land, the text is a given. The control is, in layman’s terms, mandating that the baseline for information systems (operating systems, network devices, laptops, etc.) are applied and maintained in an automatic fashion. Further distilling this into Ansible terms, by having Ansible content (playbooks, roles, vars) that strictly define the baseline configuration for all of the information systems that are to be audited, you have effectively satisfied this control (sans documentation).
The best part is that since Ansible can effectively also be the tool that tracks and manages your inventory, you are already in the running to at least partially satisfy control CM-8 (2) which deals with system inventory management.
This isn’t magic, it’s simply mapping what the text of the compliance body says with the capabilities that are already available to you via Ansible.