Improving Security Compliance in the Intelligence Community through Automation

From IC Insider Red Hat

For an Intelligence Community (IC) information technology system to gain authority to operate (ATO), a system security plan must be created, which, among other things, defines a set of policy controls from one or more compliance profiles that must be applied to the components of the system. The standard controls used within the IC are primarily defined in NIST Special Publication 800-53, Security and Privacy Controls for Federal Information Systems and Organizations, and implementing these controls is typically done by following DISA Security Technical Implementation Guides or STIGs. STIGs are available for many information technology (IT) system components, including operating systems, network devices, virtualization and cloud environments, container platforms, and numerous applications such as databases, web servers, application servers, and the like.

From a risk management perspective, STIGs are valuable tools that provide expert advice from product manufacturers as well as consistent baselines for compliance efforts across the IC. Beyond the STIGs, many agencies and organizations have additional internal security policies which also must be applied to IT systems, ranging from policies managing supply chain risk management to those aimed at mitigating insider threats. This varied set of security controls must be used for an IT system within the IC to gain ATO and go into production. Below, we will delve into these areas, but please feel free to download our white paper on this subject.

Compliance challenges

Once the necessary controls are identified, how are they applied to system components?  Depending on the individual implementers, this could be done by manually configuring each system component or using various checklists, scripts, or domain-specific or vendor-specific tooling.  If a system security plan covers components managed by separate teams – for example, network administrators and operating system administrators – different teams often take different approaches depending on the tools they are most familiar with.  These disparate approaches can present particular challenges to meeting the necessary security controls:

• The manual configuration approach is labor-intensive, prone to human error, and needs to scale better with large IT systems.
• Scripts can scale better than manual configuration but are usually limited to applying controls to operating systems or applications and may not be portable across these IT system components. They also require expertise in each scripting language and can be fragile if not written correctly, applying unintended configurations.
• Vendor-specific tooling typically only works with a single vendor’s products and requires specific expertise that may not extend to different vendor products. This can fragment efforts to achieve compliance and may require additional personnel with the needed expertise.

Added to these is the challenge of maintaining compliance over time.  While compliance is verified during the ATO process, re-verification often only takes place years later when the system ATO is renewed.  During the intervening period, mission requirements may dictate configuration changes with unintended consequences to compliance, or controls may be turned off during troubleshooting and never restored.

Overcome compliance challenges with automation

Like their civilian and industry counterparts, many Intelligence Community organizations are discovering the benefits of building a robust IT automation strategy to increase staff productivity and efficiency and improve the accuracy of IT system configuration at scale.  A strategic automation stance will enable existing personnel to focus less on day-to-day system maintenance and more on solving mission-critical problems.  When applied to compliance requirements, a holistic automation strategy using a foundational vendor-agnostic capability such as Red Hat Ansible Automation Platform provides a way to overcome the challenges discussed previously:

• Automating the implementation of a compliance control ensures that it is applied consistently at any scale, reducing or eliminating any errors that could be introduced using a repetitive manual configuration process.
• Scripts can be considered a type of IT automation, but they are often tactical: written by an individual or team for a specific need of a particular system. Writing automation content using a cross-platform tool introduces the opportunity to treat an automated task as a strategic asset that can be employed for consistent results by teams managing multiple IT systems.  Using a single automation platform reduces the need for various scripting languages and the expertise that may entail.
• A cross-platform automation capability also reduces reliance on vendor-specific tools for managing configuration or compliance. This opens up opportunities for more teams – including those without expertise using vendor-specific tools – to create helpful automation content that can be used strategically across different IT systems with the exact compliance requirements.

Automation is critical to taking a proactive approach to compliance over the lifecycle of an IT system.  Any automated control can easily be checked and reapplied on a regular cadence to minimize configuration drift.  Automation is specifically called out in NIST Special Publication 800-37, Risk Management Framework for Information Systems and Organizations: “Organizations should maximize the use of automation, wherever possible, to increase the speed, effectiveness, and efficiency of executing the steps in the Risk Management Framework (RMF). Automation is beneficial in assessing and continuously monitoring controls, preparing authorization packages for timely decision-making, and implementing ongoing authorization approaches—together facilitating a real-time or near real-time risk-based decision-making process for senior leaders.”  In other words, automation provides the underpinnings of a continuous compliance framework.

Automation and configuration-as-code

An advantage to using the Red Hat Ansible Automation Platform is that all automation tasks are captured in simple, human-readable artifacts called playbooks.  These playbooks can be treated as code and kept under source code control, meaning that the compliance state of an IT system can be captured in playbooks and managed using a typical developer pattern: intended changes can be added to a development version of the playbook, tested for accuracy, reviewed by approving authorities, committed to a production repository, and automatically applied to systems once committed.  Under this configuration-as-code paradigm, a change with unintended consequences can be rolled back using a previous playbook version retrieved from the code repository.

The configuration-as-code approach has additional benefits.  IC agencies have many IT systems in production, all of which require a system security plan defining the security controls that must be applied.  While the IT systems may be numerous, the infrastructure components that comprise those systems are finite – physical or virtual servers, operating systems, network devices, storage devices, and the like.  The controls applied to these components are primarily sourced from the same policies, meaning that different system owners use a standard set of controls for their systems.  In other words, there is much overlap among IT systems when implementing security controls.  A second-order effect of a configuration-as-code approach to compliance automation is that multiple system owners can reuse these configurations.  A repository of standard playbooks can be pre-approved by security auditors and made available to the enterprise. This enables any system owner to run one or more playbooks to apply well-known security controls across their entire system.

With Red Hat Ansible Automation Platform, the benefits of compliance automation to the Intelligence Community are clear: consistency and accuracy in implementing security controls, reduced effort across multiple IT systems of any scale, and reduced time to achieve an ATO.

To learn more about Red Hat’s work in the IC, see red.ht/icn.

Chris Edillon

Automation Specialist, National Security Programs, Red Hat

Chris is an Automation Product Specialist who supports North American public sector customers. He joined Red Hat in 2020 after 25 years as a defense contractor for the U.S. federal government, where he focused on large-scale infrastructure deployment and operations, system automation, and on-prem private cloud services.