Obsolescence of ATO Pathways

As Red Hat is modernizing our approach to Compliance as Code, we are making some changes to better provide our customers with the most accurate information available. One of the recent changes involved “ATO Pathways” — the website previously hosted at https://atopathways.redhatgov.io. We’ve removed the content and instead have posted links directing people to alternate sources of information to provide our customers with the best paths forward. We explore those paths in this article.

Why did this happen?

The bottom line upfront is that ATO Pathways diverged from the overall direction of Compliance as Code and did not share the same source of truth.

For context, you need to understand what was hosted in the repository that ATO Pathways drew its data from (ComplianceAsCode/redhat), how ATO Pathways was used and how that content related to ComplianceAsCode/content, which serves as the source of truth for Red Hat product compliance automation.

What was in the ComplianceAsCode/redhat repository?

The data in the repository is an OpenControl-formatted alignment of Red Hat products and their security features and configurations to NIST SP 800-53. We’re going to talk about one control for the most part as an example: OpenShift Container Platform 4, Access Control. Let’s look at what it looks like when defined in code:

- control_key: AC-2 standard_key: NIST-800-53 covered_by: [] implementation_status: not applicable narrative: - key: a text: | AC-2(a) is an organizational control outside the scope of OpenShift configuration. - key: b text: | AC-2(b) is an organizational control outside the scope of OpenShift configuration. - key: c text: | AC-2© is an organizational control outside the scope of OpenShift configuration. - key: d text: | AC-2(d) is an organizational control outside the scope of OpenShift configuration. - key: e text: | AC-2(e) is an organizational control outside the scope of OpenShift configuration. - key: f text: | AC-2(f) is an organizational control outside the scope of OpenShift configuration. - key: g text: | AC-2(g) is an organizational control outside the scope of OpenShift configuration. - key: h text: | AC-2(h) is an organizational control outside the scope of OpenShift configuration. - key: i text: | AC-2(i) is an organizational control outside the scope of OpenShift configuration. - key: j text: | AC-2(j) is an organizational control outside the scope of OpenShift configuration. - key: k text: | AC-2(k) is an organizational control outside the scope of OpenShift configuration.

OpenControls content attempts to mirror the structure of the document itself. This poses several challenges. You can review the current release of the document for this specific component and head to numbered page 19 (PDF page number 46) to see the control it purports to align to.

First, notice that there is an additional section in the document compared to the OpenControl format component. Since this was prepared, the publication had a new revision, and there’s no good way to track those revisions in the existing OpenControl format. Additionally, note that there’s very little context provided. When rendered into the old site for ATO Pathways, this section indicated that it was not applicable, but did helpfully break out the definitions of the keys in the narrative above — if you drill into some submenus.

The misalignment between the OpenControls content and the publication revisions might be remedied by better maintenance of the content, including information about the revision for which it is authored, and more obvious alignment between the controls called out by the publication and the narratives provided. This isn’t the main part of the problem, but a symptom of a bigger problem.

In later OpenControl definitions, additional narratives break out details of what the publication calls “Control Enhancements.” These are “implied tasks” that are derived from the explicit tasks in the main controls. The discussion embedded in NIST SP 800-53’s AC-2 control family definition, if followed to its logical end, leads to the enhancements as “emerging behaviors” of the broad application of the AC-2 control family. Some other enhancements discuss or clarify edge cases in application of the control family.

The narrative in ComplianceAsCode/redhat for the AC-2 (1) enhancement declares that OpenShift cannot meet the intent of the control, and that it needs to be delegated to some third party Identity Provider (IdP). It then links to the documentation for OpenShift to describe how to configure an external IdP. The narrative has some exposition on the kinds of configurations that may or may not be compliant with the control.

Overall, this means that ComplianceAsCode/redhat is aligning product features and documentation to NIST SP 800-53 control families, and providing links that may describe parts of how to go about bringing a system into compliance. This makes a human-readable description of all of the kinds of configuration necessary to configure a compliant platform.

How ATO Pathways was used

Within the U.S. federal government specifically, there is a collection of documentation that needs to be packaged up and submitted for an Approval/Authority/Authorization To Operate (ATO). This package is called an Authorization Package consisting of a Security Assessment Report (SAR), System Security Plan (SSP), and Plan of Action & Milestone (POA&M). The SSP is the plan for the information system’s security posture and must describe the risks of implementing an Information System (IS), the controls being put in place, the references for those controls and describe the residual risk that remains after controls have been implemented. NIST SP 800-18 describes SSPs and defines their content.

The section that ATO Pathways was attempting to help address in an SSP is referred to as the “Minimum Security Controls.” NIST SP 800-18 covers how to select and document controls in sections 3.13 and 3.14 (available starting on PDF page 31). The control classes that NIST SP 800-53 control families belong to are broken down into three categories: Management, Operational, and Technical. The majority of the kinds of controls that might relate to the configuration or use of Red Hat products are Technical or Operational, but some Management controls bleed through into configuration with technical controls as well.

The OpenControls source data was structured to align with the control families defined in NIST SP 800-53. The point of structuring this data this way, and the point of using it to build ATO Pathways, was to provide a single location through which a consumer of the content (and indeed a Red Hat customer) could look up how to go about configuring their product to come into compliance with a controls framework that they were required to follow.

ATO Pathways was intended to serve as a “blueprint” for the Minimum Security Controls section of an SSP, allowing a customer to define how they would make relevant configurations on an IS that included Red Hat products to mitigate risks.

How OpenControl content on ComplianceAsCode/redhat, and therefore ATO Pathways, related to automation built from ComplianceAsCode/content

OpenControl format was designed to be a one-stop-shop for SSP building. SSPs were designed to be human-readable documents that an Approving/Authorizing Official (AO) would read to understand the risks and mitigations for a given IS. They would approve the SSP package (which included some things that could have been templated in from OpenControls, or copied and pasted from ATO Pathways).

Most organizations have moved towards the Information Security Continuous Monitoring (ISCM) process for their ATOs. This is not universal, but is what happens at most federal organizations. ISCM is documented in NIST SP 800-137. ISCM leverages the Risk Management Framework as a way to structure continuous authorization and assessment. It strongly relates to many of the other NIST publications and workflows, but instead of describing a start-to-end process, it describes a continuous process that helps keep systems compliant, bring systems further into compliance (raising the rate of not-a-finding), and better understand and manage residual risk over time. There are six steps in the process and they start similar to what was described in NIST SP 800-18:

1. Categorize the Information System

2. Select security controls

3. Implement security controls

4. Assess security controls

5. Authorize the Information System

6. Monitor security controls

From there, the steps repeat at defined intervals, with step 6 being applied continuously.

ATO Pathways would, for its intended purpose, still help with step 2 of this process. The emerging reality, however, is that this continuous monitoring, repeated assessment and authorization life cycle described by the RMF process requires more holistic automation. That is, you should not just be automating the checks and remediations in accordance with your SSP, but should rather automate the SSP generation, the control selection, the control remediations and the full lifecycle of control assessments.

A living document that describes the plan includes measures for how to implement the plan and contains a record of when and how the plan’s effectiveness was assessed, what the results were and what types of measures are being implemented to continuously monitor the plan, with deviations recorded as events. This is the impetus for the creation of OSCAL, which is the new standard being used or explored for future use by many federal organizations:

• Using the FedRAMP OSCAL Resources and Templates

• Cyber Security Controls: Data Portability between vendor tools using NIST OSCAL

• GitHub - Open Security Controls Assessment Language (OSCAL)

OSCAL will (likely) become the language in which the U.S. federal government writes SSPs, as a machine-readable (rather than human-readable) language that can facilitate a linkage between what controls were initially selected, how they are applied to an IS, how the assessments have gone and are going and what the residual risk of an information system looks like (especially as it relates to the risk posture of an organization or system).

This discussion brings us to ComplianceAsCode/content. This repository serves as the source of truth for Red Hat product compliance automation. In other words, this is how we define what controls should be measured, enforced (via technical controls) and reported. The source code that defines the control we started discussing above is available on GitHub. As retrieved on May 23, 2022, some relevant lines look like this:

prodtype: ocp4 title: “Configure An Identity Provider” […] description: |- <p> For users to interact with OpenShift Container Platform, they must first authenticate to the cluster. The authentication layer identifies the user associated with requests to the OpenShift Container Platform API. The authorization layer then uses information about the requesting user to determine if the request is allowed. […] references: […] nist: AC-2,AC-2(1),AC-2(2),AC-2(3),AC-2(4),AC-2(5),AC-2(6),AC-2(7),AC-2(8),AC-7,IA-2(8),IA-2(9) […] template: name: yamlfile_value vars: ocp_data: ‘true’ filepath: /apis/config.openshift.io/v1/oauths/cluster yamlpath: “.spec.identityProviders[:].type” entity_check: “at least one” values: - value: “.*” operation: “pattern match”

This is a non-standardized format used by the ComplianceAsCode project to form the basis of how compliance automation content is generated. It is an “internal API” used to describe security control implementations. The noted sections include:

• A description of the control as it relates to product features

• Alignment of the control against NIST SP 800-53 control families

• The template for how to check the state of this control

That template, in the internal ComplianceAsCode API, relates to this directory. The OVAL template provided is a way of generating XML-formatted OVAL language to describe how to perform an automated check for the implementation of a technical control, in this case parametrized to check for OpenShift configuration in YAML-format Kubernetes API definitions. OVAL is a specification in the Security Content Automation Protocol (SCAP).

ComplianceAsCode/content is primarily designed to produce SCAP content for consumption by OpenSCAP for the measurement and remediation of compliance controls. In our six-phase RMF process, this means that it has a place in steps three and four, and when wrapped with some higher-level tooling has a place in the continuous step six as well. Other ComplianceAsCode/content rules leverage other templates or manual definitions for formats other than OSCAL, including (most commonly) Ansible and Bash snippets.

What’s next for organizations seeking an ATO?

ATO Pathways and the OpenControl format can’t address the complete lifecycle needs of modern ATOs. ComplianceAsCode/content can’t either, but there are some very important differences between the two:

• ATO Pathways was unsupported, and simply contained pointers to product documentation where it might be relevant

• ComplianceAsCode/content is used to build the supported compliance automation components of shipped products

Organizations are not able to use either directly in actual SSPs, as a large amount of the SSP is organizationally defined based on risk profile. And building an SSP by hand using copy-and-paste artistry from unsupported sources does nothing to align that plan with the actual implementation of controls. ComplianceAsCode/content already has a large number of regulatory framework control references embedded — far more frameworks and schemes than ATO Pathways did. Look at this rule definition to understand how much more flexible this architecture can be.

In the long run, robust OSCAL generation is needed to facilitate the entire RMF lifecycle that works with government standards — not just internal standards or open standards. Defining and maintaining the source of truth about whether a control is or is not applicable or covered by the product in two separate places with two separate perspectives is not useful or helpful to our customers. Red Hat is taking the ComplianceAsCode towards tighter alignment between the regulatory frameworks and the control implementation to pave the way for that robust OSCAL generation.

There is an example of the proto-SCAP format available on GitHub. This is the same kind of content in OpenControls format, but extended to include the automation definitions themselves. We are now working to bring that new controls format into the existing SCAP profile generation. Further, the compiled profile is the SCAP content that is shipped with the OpenShift Compliance Operator today, with metadata aligning it to the NIST control families directly.

What now?

If you are looking for the latest source of truth for compliance framework alignment of Red Hat products, that metadata may be embedded in the supported compliance automation shipped with that product. If it’s not, check the upstream source code that’s building that content in the controls folder of ComplianceAsCode/content. As ComplianceAsCode/redhat is no longer actively maintained, it is inaccurate and likely to become less accurate over time.

If you need a compliance framework mapped to a product covered in any of the above, open a ticket at the customer support portal and put together a Request for Enhancement (RFE) so that we can help.

Ready to get involved? Visit the Compliance as Code content repository. Contact [email protected] for questions.

Also, check out how we are extending compliance automation for process improvement with Compliance as Code.