How to handle NIST 800-53 sub elements?

[shawndwells]

What is the appropriate way to document NIST 800-53 sub-elements in the component.yaml's?

In the FISMA guidance, we have controls with sub-elements. For example: AC-2

In the FedRAMP word templates, these sub-elements are broken out into tables:

In code I can do something like this:

- control_key: AC-2
  standard_key: NIST-800-53
  covered_by: []
  implimentation_status: none
  narrative:
   - text: |
        (a) some answer A

        (b) some answer for B

..... however, using fedramp-templater, these sub-elements do not get properly populated. Anyone tackle this yet?

[shawndwells]

Closest I've seen in code was from AWS: https://github.com/opencontrol/aws-compliance/blob/master/EC2/component.yaml#L11

- control_key: SC-7
  covered_by: []
  implementation_status: none
  narrative: "#### a  \nThe AWS network provides significant protection against traditional\
    \ network security issues, and 18F can implement further protection. The following\

Tried breaking elements out such as "#### a" and "#### b" to no avail

[JJediny]

@shawndwells the key attribute is a sub-element which is currently supported by Compliance Masonry .doc/docx output:

  - control_key: AC-2 (7)
    covered_by: []
    implementation_status: complete
    control_origin: "service provider system specific"
    narrative:
      - key: a
        text: |
          'example
          ...'
    standard_key: NIST-800-53

[shawndwells]

Thanks @JJediny ! Used your example and setup a stanza as follows:

- control_key: AC-1
  standard_key: NIST-800-53
  covered_by: []
  implimentation_status: none
  narrative:
    - key: a
      text: |
        '
        test first paragraph

        <The customer will be responsible for developing, documenting, and 
        disseminating Access Control policy and procedures. A successful
        control response will need to address the content of the policy
        (which must include purpose, scope, roles, responsibilities,
        management committment, coordination, and compliance) and 
        procedures (which must facilitate the implimentation of the policies
        and associated controls).>

        <Adding, or binding, a role to users or groups gives the user or
        group the relevant access granted by the role. OpenShift administrators
        can add and remove roles to and from users and groups using OpenShift
        commands. Documentation for the management of OpenShift Role Bindings
        can be found at: 

        https://docs.openshift.com/container-platform/latest/admin_guide/manage_authorization_policy.html#managing-role-bindings>
        '

    - key: b
      text: |
        '<The customer will be responsible for reviewing and updating the
        Access Control policy every 3 years, and procedures annually. A
        successful control response will need to address and review and
        update process, including the role(s) responsible for initiating
        the review process, updating the policy and procedures, and
        providing approval of the updates.>'

The second paragraph of AC-1(a) gets dropped, as does all the text of AC-1(b):

Ever see anything like this?