Skip to content

Commit

Permalink
add Masonry for the Compliance Literate doc
Browse files Browse the repository at this point in the history
  • Loading branch information
afeld committed Oct 18, 2016
1 parent d30ae01 commit b71b49b
Show file tree
Hide file tree
Showing 5 changed files with 57 additions and 1 deletion.
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@

Compliance Masonry is a command-line interface (CLI) that allows users to construct certification documentation using the [OpenControl Schema](https://github.com/opencontrol/schemas). See [Benefits](#benefits) for more explanation, and learn more [in our blog post about Compliance Masonry](https://18f.gsa.gov/2016/04/15/compliance-masonry-buildling-a-risk-management-platform/). If you're interested in working on the code, see [our developer documentation](CONTRIBUTING.md#development).

![screen shot 2016-04-12 at 12 22 02 pm](https://cloud.githubusercontent.com/assets/4596845/14469165/5d27495c-00b1-11e6-9d28-327938463adf.png)
![screen shot 2016-04-12 at 12 22 02 pm](docs/assets/data_flow.png)

## Quick start

Expand Down
Binary file added docs/assets/data_flow.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/assets/workflow.png
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
4 changes: 4 additions & 0 deletions docs/assets/workflow.svg
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
52 changes: 52 additions & 0 deletions docs/masonry-for-the-compliance-literate.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
# Compliance Masonry for the Compliance Literate

This is a blog post that describes the project at a high level:

https://18f.gsa.gov/2016/04/15/compliance-masonry-buildling-a-risk-management-platform/

---

## Summary

Compliance Masonry is a set of tools that restructure the process of writing, updating, and reviewing compliance documentation. This tooling enables teams to work faster and cheaper since it reduces repetitive and labor-intensive work. The core innovations are:

* It separates information from presentation: teams can collaborate on documentation as structured data and then automatically format it in multiple ways useful to teammates and compliance reviewers, rather than the traditional approach of manually managing large static Word and Excel documents that conflate information and style.
* Compliance information underlying systems can be inherited by the system, reducing repetitive writing/copying-and-pasting in creating a System Security Plan.

## Step by step

Teams write control justifications as structured data in YAML files, like so:

https://github.com/opencontrol/schemas#components

The control justifications are then grouped into "components" (representing the parts of a system that deal with specific security requirements), which Compliance Masonry merges together to represent the overall system. cloud.gov, for example, reuses open source code from the Cloud Foundry and Concourse open source projects, so cloud.gov is writing many control statements that explain security measures in Cloud Foundry and Concourse. The cloud.gov team publishes those component-specific control statements as structured data that other CSPs using one or both of those open source components can adapt for their control documentation. Systems deployed to cloud.gov can then import cloud.gov’s full set of control descriptions, bringing along the control justifications for everything below.

Componentizing of compliance information also means that any other systems built on top of AWS, for example, could inherit those same control justifications, without needing to re-write them. Furthermore, if something compliance-related changes at the AWS level, this can be updated in one place, and automatically propagate out to the compliance documentation for the downstream systems.

Compliance information now can be stored alongside code, thus making it easier to update alongside relevant changes, in a big step towards continuous compliance.

Once the data is all pulled together, Compliance Masonry could render the data in any format useful to the team or reviewers, such as:

* The complete FedRAMP-templated System Security Plan Word document
* The Control Implementation Status (CIS) spreadsheet file with automatically up-to-date summary info about controls
* The Policies and Procedures summary document with the contents of all the -1 control statements
* A web site, for quick reference, mobile viewing, etc.

Being able to render to the official SSP documents means that the cloud.gov team can collaborate on compliance documentation through GitHub, and automatically generate the Word document to send to the reviewers as needed. If FedRAMP were to update their SSP Template, we could update the Compliance Masonry rendering logic, and then everyone using Compliance Masonry could generate a new document with the new formatting. This means saving every team using Compliance Masonry the painstaking effort of copying and pasting content between hundreds of pages of Word documents.

![workflow diagram](assets/workflow.png)

_Figure: A visual representation of the Compliance Masonry workflow._

While these are major benefits for the productivity of teams producing compliance documentation, there are also major potential benefits for compliance reviewers:

* Compliance Masonry could automatically generate reports about the completeness of the compliance information.
* Having the CIS generatable at any moment means the team can easily keep it up-to-date and accurate for compliance reviewer evaluation.
* As authors update control statements, Compliance Masonry could generate reports for compliance reviewers that list all changed information between specified dates, to help reviewers only analyze information that changed.
* The state of systems’ controls could be fed into a dashboard.
* If an underlying system’s controls have already been vetted, the tool could generate a report about which controls are specific to that system, meaning less work for the reviewers.
* If there’s a compliance violation of an underlying system (e.g. AWS), the dependent systems (e.g. cloud.gov) could be traced through the dependency tree.

The goal is not just to be able to create documentation in an automated fashion, but to be able to validate that the systems meet the controls as described in an automated way too. Compliance Masonry templates can run [executable specifications](https://en.wikipedia.org/wiki/Behavior-driven_development#Behavioral_specifications) which are used to continuously monitor that systems behave in the way they’re documented.

Hopefully this gives you a better sense of the use case and goals of Compliance Masonry—please reach out to [email protected] with any questions!

0 comments on commit b71b49b

Please sign in to comment.