Updated and tested in February 2019!
This project repository demonstrates a simple System Security Plan generated using the OpenControl framework to automate security compliance paperwork.
Anyone trying to get started with OpenControl, Compliance-Masonry, and hyperGRC:
- FISMA newbies that don't want to write big word documents
- FISMA experts that need a more efficent way of doing paper work
- FISMA enforcers that need to trust the OpenControl model and tools we're presenting
Freedonia modeled their FRedRAMP program for cyber security certification of major Information Systems after America's FedRAMP program for certifying cloud service providers.
The starting point for FRedRAMP certifications is the FRIST 800-53, which is like America's NIST 800-53 except with fewer security controls.
Freedonia's FRIST 800-53 has only 6 security controls:
| ID | Title | Type |
|---|---|---|
| AU-1 | AUDIT AND ACCOUNTABILITY POLICY AND PROCEDURES | organizational control on audit policy |
| AU-2 | AUDIT EVENTS | technical control at the node level |
| PE-2 | PHYSICAL ACCESS AUTHORIZATIONS | organization control on who accesses data center |
| SC-1 | SYSTEM AND COMMUNICATIONS PROTECTION POLICY AND PROCEDURES | organizational control on how components communicate securely |
| SC-7 | BOUNDARY PROTECTION | technical control defending boundary of entire system |
| XX-1 | MOCK/DUMMY CONTROL | here to demonstrate that a control in standard does not have to referenced in a certification |
The certification of FRedRAMP-Low requires all the above controls except for XX-1.
The standards and certifications are included in this repository, but also housed in a separate repository for easier re-use at https://github.com/opencontrol/freedonia-frist.
The system we're building is a 'Hello World' website for Freedonia, which will comprise:
- Two Amazon Web Service Virtual Private Clouds (AWS VPCs), one each for development and production
- In each AWS VPC, one node with
NGINXweb server and the static content for the website - Infrastructure for logging traffic
[Note: This system is still fictitious, but could be built if it helps Masonry users understand the process]
These steps assume you already have:
- a *nix type operating system
- Compliance Masonry installed
calibreinstalled for PDF generation- For OS X with Homebrew installed, try
brew cask install calibre
- For OS X with Homebrew installed, try
node-jsinstalled for local viewing at https://localhost:4000
Here's the tree structure of our repository:
.
├── README.md # the file you're reading now
├── components
│ ├── AU_policy
│ │ └── component.yaml # a local description of the Audit policy (AU)
│ ├── AWS_core
│ │ └── component.yaml # a local description of the "AWS core" component
│ └── AWS_implementation
│ └── component.yaml # a local description of the "AWS implementation" component
│
├── markdowns
│ ├── README.md # the introduction to the entire SSP
│ ├── SUMMARY.md # a table of contents for narrative documents of the SSP
│ └── docs # directory for narrative documents
│ ├── about-the-ssp.md
│ └── Waterfall_model.png # an example image
├── opencontrol.yaml # the schema for SSP and its remote resources/dependencies
Running compliance-masonry will also generate the directories opencontrols and exports
It just so happens you can get these files and file tree structure by cloning this repository!
Notice one file in particular, the opencontrol.yaml file in the root directory of the tree. The opencontrol.yaml file is key to using OpenControl.
OpenControl uses a config file called opencontrol.yaml following the popular configuration file pattern we see with so many tools today. Every OpenControl repository will have at least one opencontrol.yaml file providing critical information and, importantly, information about dependencies on other other OpenControl YAML files and repos.
Here's what the opencontrol.yaml file for our Freedonia project looks like:
schema_version: "1.0.0"
name: freedonia.fd
metadata:
description: Simple example of OpenControl Compliance-as-Code
maintainers:
- [email protected]
components:
- ./components/AU_policy
- ./components/AWS_core
- ./components/AWS_implementation
standards:
- ./standards/FRIST-800-53.yaml
certifications:
- ./certifications/FredRAMP-low.yamlClone this repo, then cd into freedonia-compliance. Then run:
compliance-masonry get
compliance-masonry docs gitbook FredRAMP-lowThe compliance-masonry get command reads the opencontrol.yaml file and retrieves all the dependencies, even from other OpenControl repositories!
The compliance-masonry docs gitbook FredRAMP-low command generates a document of the components and standards matching the FRedRAMP-Low certification that is expressed in the gitbook format.
At this point, you have generated content for your SSP inside of the exports directory that has artfully combined data from the all other OpenControl YAML files into a gitbook!
Our next step is to publish/deploy our gitbook content representing our SSP for shared human access. First, install GitBook:
npm install -g gitbook-cliTo make a PDF version:
cd exports && gitbook pdf ./ ./compliance.pdf
# creates the PDF at `exports/compliance.pdf`
A complete generated PDF is included here.
To make a HTML web site version:
cd exports && gitbook serve
# visit your HTML SSP at http://localhost:4000
and like this on a page for particular control:
The steps above are included in the project's Makefile so you can reliably run, say:
make clean pdf
# or
make clean serveClone this repo and clone hyperGRC.
Then cd into hyperGRC repository and follow the README.md instructions to install the Python packages.
To view Freedonia-Compliance in hyperGRC:
python -m hypergrc ../freedonia-compliance/NOTE: Python 3.5 or higher required. Also, your path to freedonia-compliance repo may be different.
Visit your OpenControl repo in a GUI at http://localhost:8000
See a list of components:
View controls associated with a component:
View control assembled from components:
We've generated a very simple System Security Plan from a bunch of re-usable YAML files and Markdown content in a computer-controlled pipeline style instead of a manually created word documents.
There are big benefits to this approach:
- Our
SSPis now managed like our codebase; anytime we update our code we can also update ourSSPand publish a new one with a single click - Our
SSPis more structured and more machine-readable, so we can do other processing - We can document compliance of re-usable components ONCE and re-use the documentation, too
OK. So we got a document. But how do we do include actual verification of the controls in the document? We've started another repo (still in progress) to show building a system and documentation together--and deploying both. Visit freedonia-aws-compliance for that.
You could use this repo as a kind of stub file for your own compliance documentation. Just change the opencontrol.yaml file and the content in the repo.
Please open an issue as needed.