Government-ready OpenStack Update (May 2018)

During the OpenStack Summit in Sydney, Keith Basil (@noslzzp) and I gave a talk about how Red Hat is preparing our distribution of OpenStack to become compliant with regulatory frameworks. The aspiration is to be regulatory-ready out of the box; meaning the OpenStack installer will allow customers to select a security profile (e.g. FedRAMP, ANSSI, PCI-DSS) and OpenStack will configure itself accordingly.

It’s been six months since the OpenStack Sydney. Since that time Red Hat Summit has come and passed, OpenStack Summit Vancouver happening this week, and Red Hat publicly disclosed that OSP13’s release is scheduled for June. Time for a public update!

Where to Begin?

The global nature of OpenStack deployments places an incredibly diverse set of security requirements on Red Hat. Our approach has been to analyze the top compliance initiatives globally and then build a plan to address them in a cohesive and focused manner.

The Cloud Controls Matrix, produced by the Cloud Security Alliance, was used as a starting point. This matrix maps standards, regulations, and controls frameworks such as the ISO 27001, PCI-DSS, FedRAMP, and FISMA. By using the Cloud Controls Matrix we were able to prioritize security requirements to maximize the amount of regulatory compliance that could be achieved.

We found that addressing the FedRAMP Moderate requirements would satisfy ~80% of the requirements common across the many compliance regimes.

Planning the Plan

We needed a lightweight process that could help convert high-level FedRAMP requirements, such as “network traffic should be encrypted,” to engineering-level RFEs such as TLS enabling all API endpoints. Additionally we wanted to track completion percentage against FedRAMP control families. For example, what percent of auditing requirements are implemented? What about identity management?

In reviewing the NIST 800–53 control selections that compose a FedRAMP Moderate baseline, 341 were identified as applicable to OpenStack. Sometimes these were documentation requirements, operational capabilities/processes, and a separate bucket for technical features.

Entering 341 feature requests into the Red Hat BugZilla system would just annoy everyone. It also meant realizing a sense of accomplishment would take several sprints — implementing 100 new features, while representing thousands of labor hours, would only get us ~33% done!

The FedRAMP controls were decomposed into the various FedRAMP levels (low, moderate, high). We found that:

• 138 controls applied to OpenStack for FedRAMP Low
  96 were already satisfied and 42 required engineering focus.
• 203 additional controls applied to OpenStack for FedRAMP Moderate
  120 were already satisfied and 83 required engineering focus.
• 95 additional controls applied to OpenStack for FedRAMP High
  54 were already satisfied and 41 required engineering focus.

These breakouts allowed for the creation of feature requests, bucketed into consumable Epics of FedRAMP Low/Moderate/High. The feature requests were then placed into engineering’s backlog and are making their way through the development. Here’s the process:

Following standard Agile planning cycles, features have been moving from the backlog into development — and have now started shipping!

First Delivery: Red Hat OpenStack Platform 13

As mentioned earlier, Red Hat OpenStack Platform 13 is expected to be released in June 2018. This release reflects considerable focus on security-related features that originated with the FedRAMP readiness planning.

Keith Basil (OpenStack Security Product Manager, @noslzzp) and Nate Kinder (OpenStack Security Engineering Manager, @nate_kinder) shared OpenStack’s security roadmap at Red Hat Summit this May. In the first half Keith speaks to the pragmatic approach, afterwards Nate steps through technical features being released. The video is available on YouTube and covers a deep technical review of the roadmap and associated features.

A few minutes into the presentation Keith steps through the OpenStack Platform Security Roadmap. For those who haven’t seen it:

OSP13 ships many (most?) of the remaining technical features identified for FedRAMP Moderate. OSP13 brings Barbican; this subsystem delivers many encryption use cases such as keys, certificates, passwords, and SSH keys. Additionally the OpenStack Security and Hardening Guide was greatly expanded and refreshed (OSP12 edition here).

As engineering transitions focus from OSP13 to OSP14, I’d like to call out the “Compliance as Code” effort noted above. This initiative spans both OSP13 and 14 — with aspirations to be released as a tech preview in OSP14.

OSP 14: Compliance as Code [tech preview]

Many regulated industries, such as healthcare, telecommunications, and nearly all U.S. government agencies, have adopted the NIST Risk Management Framework. This framework first categorizes an information system based on levels of confidentiality, integrity, and availability. Categorization then drives requirement selections from an incredibly large catalog of security and privacy controls known as NIST 800–53. For example, a “low impact” system may have 115 security controls however a “high impact” system could have several hundred.

Information systems are composed of components — such as a virtualization or container platform, an operating system, and middleware components.

At the component level, the NIST Risk Management Framework is a reflection that many government agencies are moving away from static configuration baselines, such as those published by the Center for Internet Security or the DoD STIGs, and moving towards dynamically generated security baselines.

In the past it was sufficient for a vendor to create a generic “security configuration guide” for customers. These days, especially within the Government, customers are asking vendors to create a custom baseline that specifically aligns with their NIST 800–53 control selections.

This leads to an important question:

The U.S. Government created a control catalog. Why don’t we create a response catalog? Could customer-specific security guidance by dynamically generated?

The goal of the OpenStack ComplianceAsCode content, available on GitHub, is to look across relevant security frameworks and codify compliance. The project delivers as much technical and system level compliance as possible using OpenControl-formatted data schemas.

Initial Workflow

Currently the content repository itemizes NIST 800–53 control selections and provides technical and operational details needed to satisfy the control.

Sometimes that response identifies the NIST 800–53 control is not applicable to the configuration of OpenStack:

Other times it provides a control response:

Or identifies that a response is still needed, and where to help create one:

Or identifies a response is still needed, and where to help create one:

Certification profiles can be created — either selecting controls of known baselines, such as FedRAMP, or customer-specific selections, such as DHS 4300A:

The build system scans the OpenStack content repository for answers tagged with the corresponding NIST 800–53 controls. Once the responses are identified, the build system dynamically generates the auditor paperwork that details what controls were selected and how the component satisfies the selected controls (in Government, these are called System Security Plans and Requirement Traceability Matrixes).

For example, a quick status report against control selections:

Or the more detailed control response, rendered as a webpage:

Note how multiple components can be shown together — in this case, OpenShift, OpenStack, and IdM.

Future Plans

Today the OpenStack content is limited to generating documentation. In late Summer 2018 we plan to integrate the SCAP Security Guide Project, which will mean the build system will dynamically generate SCAP and Ansible content tailored to control selections.

For known baselines, such as FedRAMP or FISMA, Red Hat will be uploading the resulting artifacts (SCAP, auditor paperwork, Ansible playbooks, kickstarts) into the NIST National Checklist Program.

Interested in Collaborating?

The OpenStack content is being developed through the ComplianceAsCode project on GitHub → https://github.com/ComplianceAsCode/redhat-openstack-platform-13.

Guidance is broken down into three primary categories:

• FedRAMP Low
  https://github.com/ComplianceAsCode/redhat-openstack-platform-13/projects/1
• FedRAMP Moderate
  https://github.com/ComplianceAsCode/redhat-openstack-platform-13/projects/3
• FedRAMP High:
  https://github.com/ComplianceAsCode/redhat-openstack-platform-13/projects/4

Each project contains a Kanban-style board with outstanding NIST 800–53 controls that need responses.

For example, issue #308 requires that network ports, protocols, and (network) services be documented. Help is needed to document what network ports/protocols OpenStack services listen on.

Interested in using the content and need help? Open an issue at https://github.com/ComplianceAsCode/redhat-openstack-platform-13/issues/new.