Layout of the new SSP Documentation

Background

We began looking at compliance-masonry as a potential solution to generating SSPs for the SIMP framework.

As we proceeded with understanding what an integration would take, we realized that we were going to lose a great deal of what we currently posses with our ReST documentation.

Our goal is to, eventually, be able to easily output OpenControl compatible YAML files but, in the mean time, we need to generate system-centric SSP materials that are easily extensible and able to pull from arbitrary code bases for validation and verification functionality.

New Layout

The general idea is that the new security guide will have a component level directory structure and a standards directory structure.  When the document is built, the controls referenced in the component section will be mapped to the standards bodies selected. 

The SIMP documents will be built based on the modules.  For each module that would be defined as a service, there will be a component directory structure and corresponding document/section produced. 

Here is a not so fancy example of the directory structure:

• security_guide
  • components
    • simplib
      • account_management
        • control.rst (includes metadata reference to a control body)
        • validation
        • hiera
      • public_key_cryptography
        • control
        • validation
        • hiera
      • <security topic>
    • apache
    • rsyslog
    • <named after modules>...
  • standards
    • nist80053
      • <control list file>
    • <standard2>
      • <control list file>
  • customization
    • component
      • simplib
        • <security topic> (if it already exists in the current directory structure for a given component, the SIMP text will not be included.  Instead, the custom text will be included)

Action items

• Ralph Wright Update this decision log with the general framework that we outlined

<control list file1>