"A YAML-powered antidote to bureaucracy"
Any software used for government, financial or safety critical applications typically cannot be deployed without a system security plan (SSP). A SSP is essentially a book that contains the safety-critical compliances and controls that the system must have in place to be granted an Authority to Operate (or ATO). This makes the adoption of agile methodologies impossible; while software is rapidly updated, it is bottlenecked by the SSP.
OpenControl is designed to automate compliance report production. Compliances are written in a standardised YAML schema. Schemas are validated using kwalify - a parser and data binder for YAML and JSON.
Example schema from OpenControl Github:
schema_version: "1.0.0" # 1.0.0 is the current opencontrol.yaml schema version name: Project_Name # Name of the project metadata: description: "A description of the system" maintainers: - firstname.lastname@example.org components: # A list of paths to components written in the opencontrol format certifications: # An optional list of certifications standards: # An optional list of standards dependencies: certifications: # An optional list of certifications stored remotely - url: https://github.com/18F/GSA-Certifications revision: master systems: # An optional list of repos that contain an opencontrol.yaml stored remotely - url: https://github.com/18F/cg-compliance revision: master standards: # An optional list of remote repos containing standards info that contain an opencontrol.yaml - url: https://github.com/opencontrol/NIST-800-53-Standards revision: master
YAML for each compliance or control is merged using a separate tool called Spruce before being passed into a command line interface known as Compliance-masonry. More research required into the inner workings of Compliance-masonry - hopefully this should be updated before or shortly after the webinar on 07/10/16. Compliance-masonry constructs certification documentation from the merged YAML files, which can then be converted to PDF via gitbook. Also produces openscap/CIS benchmark audit file, which can be passed into Nessus (vulnerability assessment software).
source:Compliance Masonry Github
Importantly, OpenControl uses gap analysis to also generate a list of waivers - compliances that the software does NOT support. The need for a waiver list is almost ubiquitous in any safety-critical system, and an auditor will decide whether to sign off or not dependent on whether the level of risk that the omissions present is acceptable. This is done using the compliance-masonry CLI by running the diff command:
compliance-masonry diff <certification>. This will then produce a list like the example below (sourced from the compliance-masonry repo)
# Example $ compliance-masonry diff FedRAMP-moderate Number of missing controls: 5 NIST-800-53@CP-7 (1) NIST-800-53@PS-2 NIST-800-53@PS-3 (3) NIST-800-53@MP-5 NIST-800-53@PS-7
When NIST (or any other regulatory agency) update a standards list, they publish the changes on their git repo. Concourse ( a Pivotal project which facilitates CI with dependency injection) then rebuilds the docs and determines which waivers are required for the current build, producing a versioned artifact of the SSP for the user. (It appears that Concourse is not connected with OpenControl, but is simply a CI tool that it has been designed to be compatible with; similarly with NESSUS.)