Tackling compliance with OpenControl



Placing information systems on government networks requires system owners to follow the NIST Risk Management framework, or an agency-specific tailored variant of it. Following this framework requires extensive documentation — even the government provided “Guide for Applying the Risk Management Framework to Federal Information Systems” is 102 pages long!

The OpenControl project was created to document security controls (whether Technical, Operational, or Management) in a standard way. OpenControl provides content schemas and tools to develop entire System Security Plans as code. The project is lead by 18F, a startup-style agency within the US Government delivering digital services and technology products.

Over the past month Red Hat Public Sector has been creating OpenControl content for OpenShift, our enterprise container platform. That code was developed and released on GitHub: https://github.com/opencontrol/RedHat/

I haven’t been this excited about fundamentally advancing compliance processes since beginning my work on OpenSCAP.  So, lets explore what this whole OpenControl capability is and how OpenControl, when combined with OpenSCAP, could potentially form the framework to fully realize compliance as code.

Start with Why: What’s the Problem?

Regulated industries have prescribed security processes. In addition to adhering to many technical controls, e.g. mundane things like password lengths, entire volumes of paperwork must be generated.

Regardless of industry, security paperwork boils down to three elements:

  1. System Security Plans (SSPs)
    Documents how the information system, as a whole, will be managed. Primarily procedurally focused: configuration management, contingency planning, incident response, etc. For U.S. Government agencies, the GSA publishes sample SSPs for cloud providers, available in Word format. The federal template is 316 pages. Completed editions often exceed 450 pages.
  2. Requirement Traceability Matrixes (RTMs)
    Information systems can be decoupled into a “bill of materials,” and upon doing so, each individual component needs to be properly configured against a specific set of standards. NIST has created a catalog of technical security controls known as “NIST 800-53: Security and Privacy Controls for Federal Information Systems and Organizations.” System owners receive a list of controls and must document, for each system component, how the component meets the security controls. This is generally done via spreadsheets that are 500+ rows.
  3. Security Assessment Plans (SAPs)
    Each system component needs to be properly configured and validated against compliance requirements. The Security Assessment Plans document the technical procedure to attest the configurations identified in the RTMs. For example, how exactly to verify your operating system is enforcing password complexity requirements. GSA publishes Excel templates for SAPs. If you haven’t been around Government for awhile, these were formerly known as Certification Test Plans, or CTPs.

Now pause and reflect about what’s needed to build a generic web app:

+ Networking Equipment
+ Compute and Storage Hardware
+ Hypervisor/Container Host
+ Operating System
+ Middleware
+ App

And of course, our long tail of peripheral software:

+ Authentication/Authorization provider (Active Director, LDAP, PKI…)
+ Backup software
+ Management tooling (Ansible, Chef, Puppet…)

The System Security Plan will be around 400 pages. Requirement Traceability Matrixes, one per component, are at least 100 pages. The Security Assessment Plans, also one per component, are at least 150-200 pages. You’re looking at minimally 3,000 pages of security paperwork. Created in Word and Excel. By hand. For a singe web app.

Can you blame everyone for loathing security? How can the Government take advantage of new computing models — in any form — when we must hit pause and update spreadsheets every time new capabilities are created?

Towards Automation

Security Assessment Plans, also known as Certification Test Plans (CTPs), are classically Word or Excel documents. They were printed and (literally!!) placed into three ring binders. Auditors, with their three ring binders, would login to the endpoint and perform several “type this command, look for this output” validations. They’d indicate if the control passed, lick the tip of their finger, and flip to the next page. The systems would get evaluated page by page, component by component. And this process took at least a week.

Here’s a snippet from the DoD Certification Test Plan for RHEL6 (pre OpenSCAP):

This particular Certification Test Plan is 125 pages long. For every RHEL instance that was created an independent auditor logged in, stepped through 125 pages of manual verification procedures, and indicated if the machine was acceptably configured. We’d seriously see the auditors walking down the hallway with multiple three ring binders overflowing from their arms. Heaven forbid if a page ripped out.

Clearly that process was terrible for everyone involved. Nobody wants to be that guy with the binders. Some people evolved to scripting their testing, using a language like Bash or Python. That approach had challenges. Auditors would make their own scripts and they would differ auditor-to-auditor. And people have different levels of scripting knowledge — who was reviewing for false positives? Or more importantly, false negatives?

The OpenSCAP project was created to provide automation tools and content that evaluate endpoints for configuration compliance (e.g. DoD STIGs) and known vulnerabilities (e.g. CVEs). This means that Security Assessment Plans, mentioned above, can be fully automated with OpenSCAP. No more three ring binders! Run a single command and get a well formatted HTML-based compliance report:

And those permission checks on /var/log/audit, shown in the manual DoD procedures? Now an automated pass/fail result:

Each configuration check embeds metadata on what regulations it helps to meet. For the U.S. Government, rules are mapped to NIST 800-53 and DISA STIGs. This means we can dynamically generate the Requirement Traceability Matrix documents:

The OpenSCAP project addresses automating the Requirement Traceability Matrix and System Assessment Plans. System owners must still author their overall System Security Plan and today these are 400+ page Word documents. This is where OpenControl fits.

(Side note: If you’re interested in OpenSCAP, the 2016 Red Hat Summit presentation with NSA and myself can be found on YouTube (https://youtu.be/xmTt0MvyYQ8).)

Introducing OpenControl

OpenControl gives us the ability to document controls (whether Technical, Operational, or Management) in a standard way.

Lets make this tangible.

There are hundreds of security compliance controls that Federal systems must adhere to. An arbitrary one is AC-17(2) from NIST 800-53, which reads:

The information system implements cryptographic mechanisms to protect the confidentiality and integrity of remote access sessions.

In the security templates provided by GSA, system owners must complete a form outlining how this control is met. They click a few checkboxes and enter free-form text on how the control was implemented:

… and there 316 pages of similar form sections that organizations must complete. Exacerbating the situation, completing this document requires input from multiple teams. Networking staff, insider threat, security operations, configuration management teams… they all have sections for their area of expertise. Because this is a Word document, multi-author collaboration is almost impossible. You enter another level of hell when this document starts getting EMailed around to a dozen or more team members, and your job is to track and merge everyones changes.

Converting development to OpenControl means easily developing security documentation as a software project: multiple authors working on the same code, at the same time, and a version control system taking care of the merges. Running the entire project on GitHub buys us standardized workflow (pull requests, tickets, versioning).

With OpenControl, form above becomes YAML. Most all developers are familiar with YAML, and if it is your first time seeing it, the syntax is easy to pickup. Modern editors from vim to Eclipse support creating YAML documents (greatly reducing/eliminating any learning curve).

So, for AC-17(2), a completed response for OpenShift would look like this:

- control_key: AC-17 (2)
  standard_key: NIST-800-53
  covered_by: []
  implementation_status: implemented
    - text: |
        'OpenShift uses the following cryptographic
        algorithms and ciphers to protect the confidentiality
        and integrity of remote access sessions:
                - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
                - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
                - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
                - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
                - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
                - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
                - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
                - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
                - TLS_RSA_WITH_AES_128_CBC_SHA
                - TLS_RSA_WITH_AES_256_CBC_SHA
                - TLS_RSA_WITH_3DES_EDE_CBC_SHA'

Documentation Reuse/Templating

I work at Red Hat. We deploy technologies to (almost?) all US Government agencies and each one typically has their own security documentation format. Imaging documenting 300+ security controls in the Army template, and when deploying the exact same technology to Navy, we copy/paste everything into theirs. Absolute time sync and unbelievably mundane.

We needed a “write once, transform into many” capability. OpenControl gives Red Hat, and our partner ecosystem, just that.

Two tools are used for this purpose:

  • ComplianceMasonry: Underneath the covers, ComplianceMasonry transforms the YAML into your choice of Gitbook or Docx. You can pass a Word template into ComplianceMasonry and ensure compliance responses are put into the right places of your customers documentation.
  • FedRAMP Templater: Takes the GSA-provided FedRAMP templates and inserts your OpenControl content into the correct places.

OpenShift deployments are generally considered cloud service providers for the sake of security accreditation. Most (all?) follow some variant of the FedRAMP controls. The next time I deploy OpenShift into a US Gov agency my process will work like this:

  1. Clone the latest OpenControl content for OpenShift:
    $ git clone https://github.com/opencontrol/RedHat/tree/master/OpenShift-v3
  2. Run “make” to generate a PDF of control mappings and insert the latest OpenShift content into the FedRAMP template:
    $ cd RedHat/OpenShift-v3
    $ make
  3. Review the generated file (e.g. exports/FedRAMP-Filled-v2.1.docx), fill in the missing pieces like system owner, program names, and network topology. And then I’m done!

The OpenControl content for AC-17(2) is now magically in the correct spot in your FedRAMP template:

Control Inheritance

Information systems are built in layers. For simplicity, lets say “network –> Infrastructure as a Service –> Platform as a Service –> App.”

For security accreditations, each incremental layer has inherited controls. The network provider may address of DDoS attack mitigation so you won’t have to. Your PaaS provider may perform automatic backups so you don’t have to address that within your application’s security paperwork.

System Security Plans must reflect all tiers of your system. OpenControl gives the ability to dynamically compose content and pull in pieces from service providers. For example, say I deployed OpenShift on RHEL7 VMs into Amazon EC2. I would create a file similar to:

schema_version: "1.0.0"
name: MyApp
  description: |
    'Security Plan for MyOpenShift.'
    - Shawn Wells (shawn@redhat.com)
  - ./RHEL7
  - ./OpenShift-v3
    - url: https://github.com/opencontrol/aws-compliance
      revision: master

And when I deploy to the next customer, who might desire on Azure instead of EC2? The dependencies gets updated to point to Azure OpenControl content.

Remaining Work

It’s not all roses. A few technical actions remain:

(1) Currently the OpenControl content for OpenShift contains entries for all FedRAMP security controls, not just technical controls specific to OpenShift. We’ll be splitting things out in the coming month.

(2) We’ve partnered with Microsoft to create OpenControl content for Azure. Code will be posted into a TBD project on OpenControl GitHub page (https://github.com/opencontrol).

(3) I’ll be working on packaging everything into EPEL. “Git clone” doesn’t mesh with some US Gov agencies and System Integrators. Early June.

Roadmap Teaser: OpenControl + OpenSCAP integration

This is where I think the value is.

The holy grail of security accreditation would be to feed a tool a list of security controls and dynamically generate paperwork, compliance automation content, and configuration management content. Integrating OpenControl with OpenSCAP gives us that capability. We’ll be able to feed a list of NIST 800-53 (or DISA STIG) controls into the tooling and generate OpenControl content for those controls, SCAP content for compliance scanning, and Ansible playbooks for configuration management.

The envisioned workflow looks likething like this:
Step 1) Create YAML file of NIST 800-53 controls you care about. Here’s a snippet for FedRAMP Moderate:

name: FedRAMP-med
    AC-1: {}
    AC-10: {}
    AC-11: {}
    AC-11 (1): {}
    AC-12: {}
    AC-14: {}
    AC-17: {}
    AC-17 (1): {}
    AC-17 (2): {}
    AC-17 (3): {}

ComplianceMasonry, one of the available OpenControl tools, has the ability to take that control listing and pull out any OpenControl content that matches the NIST 800-53 controls. Your OpenControl project file would look something like this:

schema_version: "1.0.0"
name: MyApp
  description: |
    'Security Plan for MyOpenShift.'
    - Shawn Wells (shawn@redhat.com)
  - ./RHEL7
  - ./OpenShift-v3
    - url: https://github.com/opencontrol/aws-compliance
      revision: master
    - url: https://github.com/opencontrol/FedRAMP-Certifications
      revision: master

And voilà! A System Security Plan was generated that neatly incorporates the AWS EC2, RHEL7, and OpenShift controls.

Step 2) All OpenSCAP content embeds metadata on what regulations each compliance rule helps satisfy. For example, a snippet of code from the content which evaluate if SELinux is Enforcing:

<Rule id="selinux_state" severity="high" prodtype="rhel7">
<title>Ensure SELinux State is Enforcing</title>
<description>The SELinux state should be set to Enforcing at
system boot time. In the file /etc/selinux/config, add or correct the
following line to configure the system to boot into enforcing mode:
<ref prodtype="rhel7" nist="AC-3,AC-3(3),AC-3(4),AC-4,AC-6,AU-9,SI-6(a)" disa="2165,2696" cis="1.4.2"
ossrg="SRG-OS-000445-GPOS-00199" stigid="020210" cui="3.1.2,3.7.2" />

Enabling SELinux helps satisfy the controls in the bolded nist="..." tag above. The next step will be to extend ComplianceMasonry to extract OpenSCAP containing corresponding references (e.g. NIST tags). This will build:

  • Custom SCAP profiles that contain the regulatory selections, in this case from NIST, that the customer identified as relevant;
  • Dynamically generate Requirement Traceability Matrixes from customer-selected controls; and
  • Dynamically generate Ansible playbooks

Most people don’t realize that OpenSCAP can embed bash scripts and Ansible playbooks for remediation capabilities. By integrating OpenControl with OpenSCAP, users can generate compliance paperwork, SCAP content, and Ansible playbooks, from one unified workflow.

Getting Involved!

Sound interesting? The OpenControl content for OpenShift can be found at https://github.com/opencontrol/RedHat/. Instructions on preparing a development environment can be found in the README.

Immediate areas that need help:

OpenControl Community

For now, use the GitHub issue tracker to communicate.

  • Testing: Do the instructions in the README work for you? What do you think of the workflow?
  • Content Development: OpenShift content maturing. Help is needed for everything else — RHEL7, JBoss, EC2, Azure.
  • Package Managers/Maintainers: Lets make OpenControl into EPEL RPMs for easier consumption.

OpenSCAP Community:

Communicate via the mailing list.

  • Ansible Playbooks: Help creating Ansible playbooks for both NIST 800-53 and STIG compliance. Content maturing for RHEL7 now, starting from scratch on OpenShift.
  • OpenShift STIG: Help create a STIG for OpenShift. We know the technical requirements, need to author specific implementation guidance.


Leave a Reply

Your email address will not be published. Required fields are marked *