Any help on documenting (or auto generating) the certifications yamls would be welcome.

We currently have dummy data for FISMA, but we would love to document requirements for FISMA Low, Moderate and High and any other certifications.

• All of control masonry’s tools can be invoked from one CLI.
• The CLI offers user information for running commands
• CLI catches and informs users when commands are missing arguments

After seeing many failed attempts to do what we're doing in the past, here's one thing we can intervene on now - the current commits too strongly imitate paper processes that have nothing to do with operational security, how other programs would ingest this data, and create deviations from the NIST 800-53 structure.

For example, a single control has sub-sections with arbitrary letters: a, b, c, d, that don't actually mean anything. That's just information overhead. Similarly, keying on endnote doesn't make any sense.

Here's the practical way to look at it - any control like AC-X and its subsequent enhancements AC-X (Y) per the NIST 800-53 format can either be a technical control, an organizational control, or some blend of the two.

If it's a technical control, there should be a space to include a hyperlink to something that governs that control - an example being the UAA module in Cloud Foundry.

If it's an organizational control, similarly there should still be a hyperlink to the policy or procedure governing that control.

This also points at a potentially more flexible data structure. Instead of driving the hierarchy from NIST 800-53, we can treat each NIST control as a piece of metadata or tag to any particular technical or organizational control we have. As a result, we divorce ourselves from strictly linear inheritances that causes problem when a single technical or organizational "thing" actually helps us meet multiple controls.

Further, this would allow us ingest the data in a way that better visualizes how the system actually functions, as a layers of interacting security boundaries and surfaces.

To wrangle yaml files we can use this new tool: https://blog.starkandwayne.com/2015/10/19/use-spruce-with-new-bosh-releases/

(per @joshuamckenty https://twitter.com/jmckenty/status/654337484877205504)

Currently the certification documentation is stored in Yaml files. We'll need to convert them into different formats:

1. Browsable static documentation site using US Web Design Standards
2. Export to PDF/Docx

I'd like to contribute some code for processing the NIST SP 800-53 controls from an 800-53 Control Server prototype developed earlier this year as part of research for DHS funded Homeland Open Security Technologies. The prototype has a python class SecControl that extracts 800-53 security control information from 800-53.xml published by NIST.

The files control2json.xsl and controlenhancement2json.xsl have the xpath and XSL for extracting individual controls into JSON. This could be modified to produce YAML. I also created a simple API producing a list of controls in Control Masonry YAML.

This thread is to coordinate integration issues prior to a pull request, in case there already is some activity in this area. Below is a version of @mogul's gliffy showing how 800-53-server code integrates.

diagram gliffy source

Considering schema change to:

AWS/EC2.yaml

name: Amazon Elastic Compute Cloud # Name of the component
documentation_complete: false # Manual check if the documentation is complete (for gap analysis)
references:
  - name: Reference  # Name of the reference ie. EC2 website
    url: Refernce URL  # Url of the reference
    type: URL # type of reference (will affect how it's rendered in the documentation)
verifications:
  EC2_Verification_1: # ID of verification
    name: EC2 Verification 1  # Name of verification
    url: Verification 1 URL #  URL of the verification
    type: URL # type of reference (will affect how it's rendered in the documentation)
  EC2_Verification_2:
    name: EC2 Governor 2
    url: Verification 2 URL
    type: Image
satisfies:
  NIST-800-53:
    CM-2:
      narrative: Justification in narrative form # Justification text
      implementation_status: partial # Manual status of implementation (for gap analysis)
      references:
        - verification: EC2_Verification_1 # The specific verification ID that the reference links, no component or system is needed for internal references
        - system: CloudFoundry  # System name of the verification (can link to other systems / components)
          component: UAA  # System name of the verification (can link to other systems / components)
          verification: UAA_Verification_1 # The specific verification ID that the reference links to

CloudFoundry/UAA.yaml

name: User Account and Authentication (UAA) Server
documentation_complete: false
references:
  - name: Reference
    url: Refernce URL
    type: URL
verifications:
  UAA_Verification_1:
    name: UAA Verification 1
    url: Verification 1 URL
    type: URL
  UAA_Verification_2:
    name: UAA Verification 2
    url: Verification 2 URL
    type: Image
satisfies:
  NIST-800-53:
    AC-2:
      narrative: Justification in narrative form
      implementation_status: complete

exports/certifications/LATO.yaml

A certification yaml

components: # An object for storing components this information will be rendered in a appendix.
  AWS:
    EC2:
      documentation_complete: false
      name: Amazon Elastic Compute Cloud
      references:
      - name: Reference
        type: URL
        url: Refernce URL
      verifications:
        EC2_Verification_1:
          name: EC2 Verification 1
          type: URL
          url: Verification 1 URL
        EC2_Verification_2:
          name: EC2 Governor 2
          type: Image
          url: Verification 2 URL
  CloudFoundry:
    UAA:
      documentation_complete: false
      name: User Account and Authentication (UAA) Server
      references:
      - name: Reference
        type: URL
        url: Refernce URL
      verifications:
        UAA_Verification_1:
          name: UAA Verification 1
          type: URL
          url: Verification 1 URL
        UAA_Verification_2:
          name: UAA Verification 2
          type: Image
          url: Verification 2 URL
name: LATO
standards:
  NIST-800-53:
    AC-2:
      justifications:
      - component: UAA
        implementation_status: complete
        narrative: Justification in narrative form
        references: null
        system: CloudFoundry
      meta:
        name: Account Management
    AC-6:
      meta:
        name: Least Privilege
    CM-2:
      justifications:
      - component: EC2
        implementation_status: partial
        narrative: Justification in narrative form
        references: # verifications that don't have a a system and components are given thier parent's
        - component: EC2
          system: AWS
          verification: EC2_Verification_1
        - component: UAA
          system: CloudFoundry
          verification: UAA_Verification_1
        system: AWS
      meta:
        name: Baseline Configuration

Potential Markdown output

components.md

AWS

Amazon Elastic Compute Cloud - EC2

References

• [Reference](Reference URL)

Verifications

• [EC2 Verification 1](Verification URL)
• [EC2 Verification 2](Verification URL)

Cloud Foundry

User Account and Authentication (UAA) Server - UAA

References

• [Reference](Reference URL)

Verifications

• [UAA Verification 1](Verification URL)
• [UAA Verification 2](Verification URL)

AC-2.md

AC-2: Account Management

CloudFoundry - UAA

Justification in narrative form

CM-2.md

CM-2: Baseline Configuration

AWS - Amazon Elastic Compute Cloud

Justification in narrative form

• [EC2 Verification 1](Verification 1 URL)
• [UAA Verification 1](Verification 1 URL)

Currently, component yamls are stored as:

components/
  system/
    component.yaml

However, sometimes this can lead to confusion between the key and the name of the system / component. It might be better to store files like this:

components/
  system/
    meta.yaml
    component/
      meta.yaml
      image.png
      table.md

Hence the keys would be the folders and the data formally in the component.yaml files can be stored in the meta.yamls. This structure will also allow us to store images in component folders and add information to systems via the components/system/meta.yaml.

Current behavior:

$ compliance-masonry docs docx
Error: No Template SuppliedDEPRECATED Action signature.  Must be `cli.ActionFunc`.  This is an error in the application.  Please contact the distributor of this application if this is not you.  See https://github.com/codegangsta/cli/blob/master/CHANGELOG.md#deprecated-cli-app-action-signature
$ echo $?
0

• CM can specify and consume RequiredControls
• CM can take Inventory of its current Controls
• CM can compare RequiredControls and Inventory and output GapAnalysis

Stuff like AlienVault, Sophos, etc are not part of AWS

The rendered outputs should be usable documentation, gap analysis should be conducted elsewhere.

In addition to references, component and system should also have a section for descriptions.

Add a CONTRIBUTING.md with specific needs and standards for contributing.

Our team should be able to see what controls we are missing easily.

This is the output running on ubuntu 15.10
shows !!python/unicode as space.

components:
  SYS_POS:
    COMP-one:
      documentation_complete: false
      name: !!python/unicode 'COMP_one'
      references:
      - name: Reference Name
        type: Image
        url: Refernce URL
      verifications:
        Verification_ID:
          name: Verification Name
          type: Image
          url: Verification URL
    COMP-two:
      documentation_complete: false
      name: !!python/unicode 'COMP_two'
      references:
      - name: Reference Name
        type: Image
        url: Refernce URL
      verifications:
        Verification_ID:
          name: Verification Name
          type: Image
          url: Verification URL

It would be nice to expand the intro to this readme to help fellow-government-staff visitors understand how they can use this project for their work and how they can contribute. (I also filed a small suggestion at #100.)

Some questions people may have, to consider as a type of "checklist" for the readme:

• "What are some other examples of how I could use Compliance Masonry?"
• "How ready is it for me to use? Apart from UI difficulty, are there any major functionality limitations I should watch out for?"
• "Can I bring my own set of standards and certifications? Which ones does this project already come with? Can I contribute mine to this project somehow?"
• "Who maintains this (what is Open Control), and how should I get in contact with the authors if I'm a fed curious about helping or coordinating?"

It would also totally work to link to other places that answer these questions and related questions, if blog posts and other forms of documentation become available.

For more details view: #117

TODO:
Before creating a FedRAMP template we need to make sure that FedRAMP will accept our output. contact: Bridget from FedRAMP

Right now control data is exported in a way that might not be up to their specific standards and before putting in hours of work to build a template it might be better to do some user research.

For example, Compliance Masonry docs do no split the control descriptions; however, the FedRAMP SSP might. There may be other formatting issues that we don't know about without more communication.

[assuming covered_by is for test results/justifications. If not, replace with appropriate key]

I'm building a set of RHEL/7 instances and am starting to look at compliance-masonry to help with document creation and gap analysis - and possibly as a controller to run tests. I'm currently using the OpenSCAP tool for OS compliance verification, and each of the 800-53 controls has one or more STIG rules to check compliance. Things get complicated quickly:

• There may be seven STIG rules for a control of which only five pass (gap of two)
• Even if all pass, that's just the OS; there may be tests required for the application (gap) and other tiers

Two questions:

• Has anyone looked at hooking OpenSCAP up to CM?
• What is the thinking on handling multiple tiers (platform, application, etc.)?

First draft of script here: #83

cloud-gov/cg-deploy-compliance-documentation#7 is adding link verification as part of our build pipeline, but seems like it would be best to incorporate it within the tool. Alternatively, might be sufficient (for now) to recommend that folks use an external tool like HTML Proofer.

The original CM could use local files as verification paths; however, the new only works with public URLs.

• write tests
• many scripts share the same function, we should dry up the code.
• consider more OOP approach

Right now, controls that are not implemented are just blank, like:
https://compliance.cloud.gov/standards/NIST-800-53-CM-4.html

They should have some (maybe configurable) text, like 'Not Implemented', or 'This space left intentionally blank.'

Running python renderers/certifications_to_pages.py crashes from KeyError when control is listed in data/certifications/FISMA.yaml but control not listed in standards/NIST-800-53.yaml.

Since it is likely that people will have some trouble keeping everything in sync, it would be better if exceptions are caught and logged to standout like yaml_to_certifications.py is already doing.

Recreating error is easy. Add a control to data/certifications/FISMA.yaml like "AU-19" that does not exist in standards/NIST-800-53.yaml and then run python renderers/yaml_to_certifications.py followed by running python renderers/certifications_to_pages.py

Gregs-MacBook-Pro:dsca-control-masonry greg$ python renderers/certifications_to_pages.py
Traceback (most recent call last):
  File "renderers/certifications_to_pages.py", line 144, in <module>
    output_path="exports/Pages"
  File "renderers/certifications_to_pages.py", line 133, in convert_certifications
    create_control_nav(control_key, control)
  File "renderers/certifications_to_pages.py", line 44, in create_control_nav
    'text': control_key + " " + control['meta']['name'],
KeyError: 'meta'
Gregs-MacBook-Pro:dsca-control-masonry greg$ python renderers/certifications_to_pages.py
Traceback (most recent call last):
  File "renderers/certifications_to_pages.py", line 144, in <module>
    output_path="exports/Pages"
  File "renderers/certifications_to_pages.py", line 133, in convert_certifications
    create_control_nav(control_key, control)
  File "renderers/certifications_to_pages.py", line 44, in create_control_nav
    'text': control_key + " " + control['meta']['name'],
KeyError: 'meta'

Here are the relevant links:

• https://www.fedramp.gov/files/2015/03/FedRAMP-System-Security-Plan-Template-v2.1.docx
• https://www.fedramp.gov/resources/templates-3/

From @jacobian in cloud-gov/cg-compliance#66:

Working on https://github.com/18F/bug-bounty, and I'm getting this error:

$ compliance-masonry get
Compliance Dependencies InstalledDEPRECATED Action signature.  Must be `cli.ActionFunc`.  This is an error in the application.  Please contact the distributor of this application if this is not you.  See https://github.com/codegangsta/cli/blob/master/CHANGELOG.md#deprecated-cli-app-action-signature

The opencontrols dir does still get created, and appears (?) to be complete, so perhaps this is just noise?

Current the golang cm does not have the ability to use test verifications:

For example: https://github.com/opencontrol/cf-compliance/blob/master/CloudController/component.yaml#L129

New fields need to be added to the VerificationReferences struct

To ease integration into the compliance toolkit, compliance masonry should support optional machine readable output for end products.

Right now, the only end product that we are concerned with is the gap analysis, but this should be handled in a general enough way that additional commands could be added.

Tests should mock all network connections to improve testability.

Diagram how data flows through control masonry to create final documentation.

Having a machine readable format means we can rely on the machine for some data inspection. A linter is related to, but different from gap analysis, because it can find incompletely or incorrectly filled out fields within a 'complete' control.

For example, it should flag:

• TODO or FIXME lines
• Suspiciously short descriptions
• Link fields that don't contain links

Create process for adding image and url justifications

Documentation should answer questions below

• What files does a person have to create (e.g., FISMA.yaml)
• What files are generated by running scripts (e.g., what files change in the repository when you use it)?
• How do you clone/fork/whatever and use control-masonry in your project?
• How do you add your own components, customize text for existing controls?

via @gregelin

@RAMIREZG Pull Request #7 culminated a fairly significant reorganization of the files. What follows is my understanding of the changes. Can you tell me if they are correct?

1. Replaced the controls directory of YAML documents with (1) data directory of YAML and (2) completed_certifications directory.
2. This new structure replaces the base_control.yaml, final_controler.yaml, and project_info.yaml files with a better organized hierarchy of directories for source YAML files describing controls from system components.
3. The source YAML control files can actually be generated from source spreadsheets using workbook_to_yamls.py, which addresses importing controls from the many people who currently have controls listed in spreadsheets.
4. Instead of generating final_controler.yaml as the interim YAML file from which to generate the control markdown pages for Jekyll, there is a new python script, yamls_to_certification.py, that generates "certification" YAML files in completed_certifications.

I'm assuming the markdown pages can still be served with Jekyll, but the repo at the moment is missing the javascript scripts that previously existed to generate the markdown files. Is the idea to generate the markdown files using python script instead?

Love the first commits. My only comment just yet is on the SSP document. Seems like it could push farther in terms of extracting useful data and collapsing complexity down.

Instead, I'd like to move in the direction I'm already experimenting with on certain projects, like College Choice: https://github.com/18F/control-masonry/blob/master/data/project_data.yml

We can circle back to this later, I'd rather we approach this from the bottom up (structure controls first) before we formally tackle SSPs.

Control listing in navigation bar would be nicer if alphabetized, or if possible to set order in some manner.

I am going to preface this issue by saying that I am still relatively to Masonry, and compliance in general. After starting to go through setting up Masonry for a web application the other day, I wanted to take a step back and brainstorm a bit about where (from a user's perspective) the underlying compliance data would ideally live.

Compliance examples

cloud.gov

For cloud.gov, the compliance documentation is all being collected in https://github.com/18F/cg-compliance. That's fine, though what if another agency wanted to launch a system on AWS and get an ATO through Masonry? They could fork the repository, but they wouldn't benefit from any updates contributed upstream, unless they were diligent about checking for updates and merging. They would also probably want to delete the 18F/ directory since it doesn't apply to them, but this means that merging from upstream through Git becomes an even bigger headache.

From a quick glance, it seems like none of the information under AWS/ and CloudFoundry/ (minus the implementation_status) is (or needs to be) cloud.gov-specific.

An application running on cloud.gov

As a second thought experiment, let's say an agency is launching a web application on cloud.gov. It would be great if their compliance information could be versioned along with their application code (in a repository they manage), but this would require copying the files from this repository into theirs, which would create a lot of clutter. They should only have to care about the information that's specific to their application. It would be great if the developer could say:

• "It's using cloud.gov, so inherit the cloud.gov controls," without needing to copy in all of the cloud.gov Masonry files (and keep them up-to-date).
• "This will be a FISMA Low application."
• "I am fulfilling SA-11 by using Brakeman on Code Climate," without needing to fill out the references to re-explain to Masonry what Code Climate is.

A different platform

A third: suppose a hosting company wants to use Masonry to list their FedRAMP compliance information. It wouldn't make any sense for them to put their information in the "Compliance Masonry compatible repository for Cloud.gov" (cg-compliance), but they shouldn't have to maintain the data/certifications/FedRAMP-*.yaml files separately, either.

Takeaways

A few overall themes here:

• How can we avoid duplicating compliance information? (that can get out of date living in two places)
• How can we allow projects to keep compliance information specific to their system in the repository of their choosing?
• How can we distinguish compliance information that is general-purpose versus that that is implementation-specific? Examples of the former:
  • The list of sub-components of Cloud Foundry
  • What controls make up FedRAMP Medium
  • Where to find information about Code Climate / Logentries / any other reusable "component"

Suggestion

Short of supporting the reusable compliance data living anywhere, a good starting place might be to create a centralized "library" of certifications and components (e.g. "here is the canonical information about how EC2 fulfills NIST-800-53 SC-7"). A sketch of how that might work:

• opencontrol/masonry-data repository
  • data/
    • certifications/
      • 18f_open_data.yaml
      • gsa_fisma_low.yaml
      • fedramp_med.yaml
    • components/
      • aws/
      • cloud_foundry/
      • cloud_gov/

        • component.yaml

          inherits:
          - aws
          - cloud_foundry

      • code_climate/
• 18F/C2 repository (i.e. an application)
  • masonry/

    • system.yaml

      inherits:
      - cloud_gov
      verifications:
      - component: code_climate
        type: URL
        path: ...

The masonry-data could be pulled in by the masonry tool when run in the context of C2/, but doesn't need to be copied around by the user. Maybe that data gets packaged with the tool (a la Homebrew) or is downloaded from elsewhere as part of masonry docs – whatever works.

Not sure if any of this makes sense...thoughts?

Since data is more closely organized as the Certification Justifications. The first step will be to covert data from the SSP Controls Matrix to the certification justification format.

My Cloud.gov/AWS/18F Controls

Without being combined with the standards and certifications yamls the control yamls can be use to generate readable documentation w/ gitbook, etc...

## Cloudgov.yaml
CF_UAA:
  name: Cloud Foundry User Authentication and Authorization (UAA)
  references:
    - name: UAA design doc
      url: https://asdfasdf
    - name: Some other doc
      url: https://boobarbazbat
  governors:
    - name: UAA configuration
      url: https://pathtogitrepohead
    - name: Live test results
      url: https://dashboardwithupdatedtestresults
  satisfies:
    - standard:
        NIST-800-53:
           - element: AC-2-a
             narrative: Description of now CF_UUA meets point control X sub mod. a

Standards Documentation

# nist-800-53.yaml
standards:
  C-2:
    name: User Access
    description: There is an affordance for managing access by...

# PCI.yaml
standards:
  Regulation-6:
    name: User Access PCI
    description: There is an affordance for managing access by...

Certifications

Empty yaml for creating certification documentation. Serve as a template for combining controls and standards yamls.

# Fisma.yaml
standards:
  nist-800-53:
    C-2:
    C-3:
  PCI:
    6:

Certification Justifications

Centralized yaml for a specific certification, can be used to render matrix.csv, gitbook.md, ssp.docx... This is were we will be able to see if any pieces are missing.

# FISMA.yaml
AC-2:
  a:
  - title: Title of control requirement justifications
    justifications:
    - id: CF_UAA
      name: Cloud Foundry User Authentication and Authorization (UAA)
      narrative: Description of now CF_UUA meets point control X sub mod. a
      references:
        - name: UAA design doc
          url: https://asdfasdf
        - name: Some other doc
          url: https://boobarbazbat
      governors:
        - name: UAA configuration
          url: https://pathtogitrepohead
        - name: Live test results
          url: https://dashboardwithupdatedtestresults

Currently the only render format is .md gitbook
To build an .docx we can use the python-docx

This library here provide a nice way to work with open xml format
-https://python-docx.readthedocs.org/en/latest/
part of this project.
-https://github.com/python-openxml

Questions around this..
If we are to use this library , should we fork a version for this project or build a dependency in the requirements file at setup ???

Thanks.

With my network connection turned off:

$ go test $(glide nv)
ok      github.com/opencontrol/compliance-masonry/config    0.022s
ok      github.com/opencontrol/compliance-masonry/config/common 0.021s
?       github.com/opencontrol/compliance-masonry/config/common/mocks   [no test files]
ok      github.com/opencontrol/compliance-masonry/config/common/resources   0.029s
?       github.com/opencontrol/compliance-masonry/config/common/resources/mocks [no test files]
?       github.com/opencontrol/compliance-masonry/config/parser [no test files]
ok      github.com/opencontrol/compliance-masonry/config/versions/1.0.0 0.025s
ok      github.com/opencontrol/compliance-masonry/docx  0.163s
ok      github.com/opencontrol/compliance-masonry/gitbook   0.076s
ok      github.com/opencontrol/compliance-masonry/models    0.039s
?       github.com/opencontrol/compliance-masonry/tools/constants   [no test files]
?       github.com/opencontrol/compliance-masonry/tools/fs  [no test files]
?       github.com/opencontrol/compliance-masonry/tools/fs/mocks    [no test files]
ok      github.com/opencontrol/compliance-masonry/tools/mapset  0.018s
Running Suite: Vcs Suite
========================
Random Seed: 1461910702
Will run 5 of 5 specs

2016/04/29 01:18:22 Initializing repo https://github.com/opencontrol/compliance-masonry into /var/folders/ww/4wqv74nj65gcttnv9b1ky9ph0000gn/T/go-vcs115378598
2016/04/29 01:18:22 Cloning https://github.com/opencontrol/compliance-masonry into /var/folders/ww/4wqv74nj65gcttnv9b1ky9ph0000gn/T/go-vcs115378598
• Failure [0.049 seconds]
Manager
/Users/aidanfeldman/dev/go/src/github.com/opencontrol/compliance-masonry/tools/vcs/manager_test.go:33
  Clone
  /Users/aidanfeldman/dev/go/src/github.com/opencontrol/compliance-masonry/vendor/github.com/onsi/ginkgo/extensions/table/table.go:96
    sane check [It]
    /Users/aidanfeldman/dev/go/src/github.com/opencontrol/compliance-masonry/vendor/github.com/onsi/ginkgo/extensions/table/table_entry.go:46

        Error Trace:    manager_test.go:20
                asm_amd64.s:473
                value.go:435
                value.go:303
                table_entry.go:40
                runner.go:109
                runner.go:63
                it_node.go:25
                spec.go:167
                spec.go:118
                spec_runner.go:144
                spec_runner.go:61
                suite.go:59
                ginkgo_dsl.go:207
                ginkgo_dsl.go:188
                vcs_suite_test.go:12
        Error:      Expected nil, but got: &errors.errorString{s:"[Error: Cloning repo failed Repo: https://github.com/opencontrol/compliance-masonry Revision: master Dir: /var/folders/ww/4wqv74nj65gcttnv9b1ky9ph0000gn/T/go-vcs115378598 Error Details: Unable to get repository]\n"}


    /Users/aidanfeldman/dev/go/src/github.com/opencontrol/compliance-masonry/tools/vcs/manager_test.go:20
------------------------------
2016/04/29 01:18:22 Initializing repo https://github.com/opencontrol/compliance-masonry into /var/folders/ww/4wqv74nj65gcttnv9b1ky9ph0000gn/T/go-vcs112099533
2016/04/29 01:18:22 Cloning https://github.com/opencontrol/compliance-masonry into /var/folders/ww/4wqv74nj65gcttnv9b1ky9ph0000gn/T/go-vcs112099533
• Failure [0.028 seconds]
Manager
/Users/aidanfeldman/dev/go/src/github.com/opencontrol/compliance-masonry/tools/vcs/manager_test.go:33
  Clone
  /Users/aidanfeldman/dev/go/src/github.com/opencontrol/compliance-masonry/vendor/github.com/onsi/ginkgo/extensions/table/table.go:96
    sane check no revision [It]
    /Users/aidanfeldman/dev/go/src/github.com/opencontrol/compliance-masonry/vendor/github.com/onsi/ginkgo/extensions/table/table_entry.go:46

        Error Trace:    manager_test.go:20
                asm_amd64.s:473
                value.go:435
                value.go:303
                table_entry.go:40
                runner.go:109
                runner.go:63
                it_node.go:25
                spec.go:167
                spec.go:118
                spec_runner.go:144
                spec_runner.go:61
                suite.go:59
                ginkgo_dsl.go:207
                ginkgo_dsl.go:188
                vcs_suite_test.go:12
        Error:      Expected nil, but got: &errors.errorString{s:"[Error: Cloning repo failed Repo: https://github.com/opencontrol/compliance-masonry Revision:  Dir: /var/folders/ww/4wqv74nj65gcttnv9b1ky9ph0000gn/T/go-vcs112099533 Error Details: Unable to get repository]\n"}


    /Users/aidanfeldman/dev/go/src/github.com/opencontrol/compliance-masonry/tools/vcs/manager_test.go:20
------------------------------
2016/04/29 01:18:22 Initializing repo https://myrepo/opencontrol/compliance-masonry into /var/folders/ww/4wqv74nj65gcttnv9b1ky9ph0000gn/T/go-vcs303897544
•2016/04/29 01:18:22 Initializing repo http://user:[email protected]/opencontrol/compliance-masonry-blah into /var/folders/ww/4wqv74nj65gcttnv9b1ky9ph0000gn/T/go-vcs379111047
2016/04/29 01:18:22 Cloning http://user:[email protected]/opencontrol/compliance-masonry-blah into /var/folders/ww/4wqv74nj65gcttnv9b1ky9ph0000gn/T/go-vcs379111047
•2016/04/29 01:18:22 Initializing repo https://github.com/opencontrol/compliance-masonry into /var/folders/ww/4wqv74nj65gcttnv9b1ky9ph0000gn/T/go-vcs298980410
2016/04/29 01:18:22 Cloning https://github.com/opencontrol/compliance-masonry into /var/folders/ww/4wqv74nj65gcttnv9b1ky9ph0000gn/T/go-vcs298980410

------------------------------
• Failure [0.031 seconds]
Manager
/Users/aidanfeldman/dev/go/src/github.com/opencontrol/compliance-masonry/tools/vcs/manager_test.go:33
  Clone
  /Users/aidanfeldman/dev/go/src/github.com/opencontrol/compliance-masonry/vendor/github.com/onsi/ginkgo/extensions/table/table.go:96
    Get a revision that doesn't exist [It]
    /Users/aidanfeldman/dev/go/src/github.com/opencontrol/compliance-masonry/vendor/github.com/onsi/ginkgo/extensions/table/table_entry.go:46

        Error Trace:    manager_test.go:23
                asm_amd64.s:473
                value.go:435
                value.go:303
                table_entry.go:40
                runner.go:109
                runner.go:63
                it_node.go:25
                spec.go:167
                spec.go:118
                spec_runner.go:144
                spec_runner.go:61
                suite.go:59
                ginkgo_dsl.go:207
                ginkgo_dsl.go:188
                vcs_suite_test.go:12
        Error:      "[Error: Cloning repo failed Repo: https://github.com/opencontrol/compliance-masonry Revision: master-ultimate-branch-that-never-exists Dir: /var/folders/ww/4wqv74nj65gcttnv9b1ky9ph0000gn/T/go-vcs298980410 Error Details: Unable to get repository]
        " does not contain "Revision Checkout failed"


    /Users/aidanfeldman/dev/go/src/github.com/opencontrol/compliance-masonry/tools/vcs/manager_test.go:23
------------------------------


Summarizing 3 Failures:

[Fail] Manager Clone [It] sane check
/Users/aidanfeldman/dev/go/src/github.com/opencontrol/compliance-masonry/tools/vcs/manager_test.go:20

[Fail] Manager Clone [It] sane check no revision
/Users/aidanfeldman/dev/go/src/github.com/opencontrol/compliance-masonry/tools/vcs/manager_test.go:20

[Fail] Manager Clone [It] Get a revision that doesn't exist
/Users/aidanfeldman/dev/go/src/github.com/opencontrol/compliance-masonry/tools/vcs/manager_test.go:23

Ran 5 of 5 Specs in 0.144 seconds
FAIL! -- 2 Passed | 3 Failed | 0 Pending | 0 Skipped --- FAIL: TestVcs (0.14s)
FAIL
FAIL    github.com/opencontrol/compliance-masonry/tools/vcs 0.161s
?       github.com/opencontrol/compliance-masonry/tools/vcs/mocks   [no test files]
ok      github.com/opencontrol/compliance-masonry   19.466s

Chrome is showing .nav-children with a max-hight: 400px;. This is limiting the number of controls showing up in the rendered pages. There is currently no overflow setting, either. The end result is it appears many controls are missing after the page generation.

.nav-children {
    display: block;
    max-height: 400px;
    opacity: 1;
    -webkit-transition: max-height .2s, opacity .2s;
    -moz-transition: max-height .2s, opacity .2s;
    -o-transition: max-height .2s, opacity .2s;
    transition: max-height .2s, opacity .2s;
}

Best solution might be an overflow: scroll;.

Under the current structure, controls are mapped to components of systems. For example, in the yaml below the UAA, a component of Cloud Foundry satisfies the AC-2 control.

name: User Account and Authentication (UAA) Server
references:
- reference_name: User Account and Authentication (UAA) Server
  reference_url: http://docs.pivotal.io/pivotalcf/concepts/architecture/uaa.html
governors:
- governor_name: Cloud Foundry Roles
  governor_url: https://cf-p1-docs-prod.cfapps.io/pivotalcf/concepts/roles.html
satisfies:
  AC-2: Cloud Foundry accounts are managed through the User Account and Authentication
    (UAA) Server.

However, sometimes components like the UAA depend on sub-components like CA Siteminder to satisfy controls. Am I explaining this correctly @joshuamckenty?

Any ideas on how to represent this? We could have folders that contain sub-component yamls

+-- CloudFoundry
|   +-- UAA.yaml
|   +-- UAA
    | +-- CA_Siteminder.yaml

Any help on documenting (or auto generating) the standards yamls would be welcome.

We currently have some NIST controls, but we could use the rest and other standards.

Currently, there's no way to include other files when getting all components, certifications, and standards. Would like to have an includes section in the yaml for misc data.

This will fix some broken links in the gitbook

Examples

AWS Identify and Access Management (IAM)
AWS Elastic Block Storage (EBS)
AWS Simple Storage Service (S3)
AWS Elastic Load Balancing (ELB)
AWS CloudTrail
AWS CloudWatch
AWS Virtual Private Cloud (VPC)

Cloud Foundry Loggregator
Cloud Foundry User Account and Authentication (UAA) Server
Cloud Foundry User Account and Authentication CLI (UAAC)
Cloud Foundry Droplet Execution Agent (DEA)