SAP, SAR and PO&M Syntax Diagrams and Mock-Up

[brian-ruf]

User Story:

As an OSCAL syntax modeler, I need to understand the groupings and relationships of information necessary to model a security assessment plan (SAP), security assessment report (SAR), and plan of actions and milestones (POA&M), so that I can create preliminary OSCAL syntax for these artifacts.

Goals:

• Review and analyze the Information Inventory created in issue #588.
• Create overview relationship diagrams to define and illustrate groupings of information and relationship of information. This will help clarify syntax structure.
• Create mock-up SAP, SAR, and POA&M syntax models in MD and/or YAML, suitable for translation to metaschema in the next sprint.

Dependencies:

Issue #588

Acceptance Criteria

• [ ] Information relationships are clearly diagramed.
• [ ] All information in the inventory is accounted for in the syntax, either directly or because it can be generated from information represented using the syntax.

[brian-ruf]

Updated March 11, 2020. Added "Objectives" section. Moved Controls and Control Objectives from "Assessment Subject" to "Objectives" for SAP and SAR. Updated March 10, 2020. Changed "Scope" to "Assessment Subject" at high-level of SAP and SAR. Updated March 1 6,2020. Changed Model Names:

• Security Assessment Plan Model to "Assessment Plan"
• Security Assessment Report Model to "Assessment Results" Also changed "Evidence" to "Evidence Inventory", which better reflects its intended function. Added "Evidence Inventory" to POA&M diagrams.

[brian-ruf]

20-Feb-2020 Status

Still catching up from extended illness. Made some progress on this. Expect to make up time and complete by end of month as originally scheduled.

Will post detailed diagrams and mock-ups when I have a little more progress to show.

[brian-ruf]

27-Feb-2020 Status

Nearly finished with diagrams and syntax mock-ups. Expect to be finished this task early next week. (Still a little behind after more than a week of illness.) Providing work-to-date below.

[brian-ruf]

SAP, SAR, and POA&M Relationship Diagram

Updated March 11, 2020. Added "Objectives" section. Moved Controls and Control Objectives from "Assessment Subject" to "Objectives" for SAP and SAR. Updated March 10, 2020. Changed "Scope" to "Assessment Subject" at high-level of SAP and SAR.

Identification and Summary of Risks in FedRAMP SAR

[brian-ruf]

Security Assessment Plan (SAP) Syntax Mock-Up

Updated March 11, 2020 @ 4:30 PM EDT

Top Level Assemblies

security-assessment-plan
 - metadata [ 1 / 1 ]
 - import [ 1 / 1] (SSP)
 - objectives [ 1 / 1]
 - assessment-subject [ 0 or 1 / 1]
 - assets [ 0 or 1 / 1]
 - assessment-activities [ 0 or 1 / 1 ]
 - back-matter [ 0 or 1 / 1 ]

Cardinality Notes

Cardinality is in brackets. There are two cardinalities listed, separated by a slash. The first is the OSCAL cardinality The second is the FedRAMP cardinality, which is either as strict or more strict than the OSCAL cardinality.

Example: [0 or 1 / 1] means the cardinality for OSCAL syntax is 0 or 1; however, FedRAMP the FedRAMP cardinality is exactly 1.

Metadata

The following are handled using existing OSCAL Metadata syntax, thus are not re-modeled here:

- Title [1 / 1]
- Last-Modified [1 /1]
- OSCAL Syntax Version [1 / 1]
- Version [0 or 1 / 1]
- Publication Date [0 or 1 / 1]

Also Users, Roles, and Locaitons are modeled with standard Metadata syntax. This includes:

Roles: 
- Prepared By [ 0 or 1 / 1 ]
- Prepared For [ 0 or 1 / 1 ]
- Assessment teams [ 0 or more / 1 or more]

Parties:
- POCs
- Interviewed Staff Names, Roles, etc.

Assessment locations

Import

For SAP, only the SSP is imported

- import href="" [ 1 / 1 ] (System Security Plan)
  - remarks

Assessment Objectives

In the SAP, this identifies the controls and control objectives to be assessed.

All controls in the linked profile (SAP -> SSP -> Profile) may be specified using the all field, or a subset of those controls may be specified. For the identifed controls, all objectives may be specified using the all field, or a subset of objectives may be specified. Control objectives may also be defined and added to the assessment, but must be linked to an in-scope control.

- objectives
  - controls
    - all
    - include @control-id
    - exclude @control-id
  - control-objectives
    - all
    - include @objective-id
    - exclude @objective-id
    - objective @id
      - control-link @control-id

      (Same syntax as Catalog)
      - part name='' @id="sap-xx-#.a_obj"
        markup-multiline
        - prop name="label"
        - part id="xx-#.a_obj.1" name="objective"
          - promp name="label"
          - markup-multiline
        - part @id name='objective' [ 0 or 1 / 0 or 1 ]
          - prop name='label' [ 0 or 1 / 1 ]
          - markup-multiline [ 0 or 1 / 0 or 1 ]
      - part name='assessment' [ 0 or more / 0 or more ]
        - prop name='method'
        - part name='objects'

Adding to the SAP in this way is equivalent to adding rows in the test case workbook. An objective ID defined in the SAP must not duplicate an objective ID in the upstream profile or catalog.

Assessment Subject

In the SAP, this dentifies the system elements to be assessed, and which to avoid. This can include system components, inventory items, locations, and users. It also eanbles the the assessor to define any components, inventory-items, and users where they differ from the SSP content.

Assessment Subject has three sub-assemblies:

• subject-include explicitly defines what is included in the assessment's focus.
• subject-exclude explicitly defines what is excluded from the assessment's focus.
• local-definitions for anything not addressable elsewhere.

Assessment Subject sub-assemblies reference content in the SSP. For each subject-include or subject-exclude sub-assembly (controls, components, locations, etc.), either all must be present, or one or more id-ref fields.

- assessment-subject @type [ 1 / 1 ] 
  - prop (for extensions)
  - annotation (for extensions)
  - subject-include @name="components" @class
    - description  [ 0 or 1 / 0 or 1 ]
    - prop (for extensions) [ 0 or more / 0 or more ]
    - annotation (for extensions) [ 0 or more / 0 or more ]
    - all [ 0 or 1 / 0 or 1 ]
    - id-ref @id @name [ 0 or more / 0 or more]
    - remarks
  - subject-include @name="inventory-items" @class
       (Same syntax as subject-include @name="components")
  - subject-include @name="locations" @class
  - subject-include @name="users" @class

To explicitly identify an item to exclude from testing, use subject-exclude, such as excluding certain hosts from the assessment.

  - subject-exclude @name="components" @class
       (Same syntax as subject-include @name="components")
  - subject-exclude @name="inventory-items" @class
  - subject-exclude @name="locations" @class
  - subject-exclude @name="users" @class

  - remarks

For items not appropriately defined in the SSP, or where the linkage is unclear, the local-definitions assembly can be used to define components, inventory items, and users here. The syntax is identical to the SSP. NOTE 1: In the SAP, the assessor could use this to define required levels of tested user privileges more broadly, such as when the requirement is "external users, internal users, and administrors". NOTE 2: Define missing locations in the SAP's metadata.

  - local-definitions
      (component assembly syntax from SSP)
    - component @id="" 

      (inventory-item assembly syntax from SSP)
    - inventory-item @id="" 
      - description [ 1 / 1 ]
      - prop @name="ipv4-address"
      - prop @name="fqdn"
    - inventory-item @id="" 
      - description [ 1 / 1 ]
      - prop @name="network-id"
      - prop @name="ipv4-address-start" (such as 10.0.1.1)
      - prop @name="ipv4-address-end"   (such as 10.0.1.254)
    - inventory-item @id="" 
      - description [ 1 / 1 ]
      - prop @name="network-id"
      - prop @name="ipv4-network-address"  (such as "10.0.1.0/24")
    - user [ 0 or more / 0 or more ]
        (user assembly syntax from SSP)
      - title [ 1 / 1 ]
      - description [ 1 / 1 ]
      - prop @name='sensitivity' @ns="fedramp"
      - annotation @name='type'
      - annotation @name='privilege-level'

Assets

In the SAP, these are the (teams and tools) intended to perform the assessment. Tools follow the component approach/syntax from SSP, but are focused on assessment tools rather than components of the system. This allows assessment teams to select component files for tools the same as with the SSP.

- assets [ 0 or 1 / 1 ]
  - tools [ 0 or 1 / 1 ]
    - component @id @component-type  [ 0 or more / 1 or more ]
      - title [ 1 / 1 ]
      - description [ 1 / 1 ]
      - prop @name="virutal"  [ 0 or 1 / 1 ]
      - prop @name="software-name" [ 1 / 1 ]
      - prop @name="version" [ 0 or 1 / 1 ]
      - prop @name="vendor-name" @ns="fedramp" [ 0 or 1 / 1 ]
      - prop @name="model" [ 0 or 1 / 0 or 1 ]
      - prop @name="patch-level" [ 0 or 1 / 0 or 1 ]
      - prop [ 0 or more / 0 or more ]
        - NOTE: @name="asset-type", "scan-type" and "validation" are N/A.
      - annotation  [ 0 or more / 0 or more ]
        - NOTE: @name="allows-authenticated-scan" and "baseline-configuration-name" are N/A.
      - responsible-party [ 0 or more / 0 or more ]

If the assessor is conducting scans or penetration test attacks, not only must the tools be provided, but the origination address must be listed below for any scans or attacks intended by the assessor.

  - origination @id [ 0 or more / 1 or more ]
    - title
    - description [ 1 / 1 ]
    - prop @name="ipv4-address"
    - prop @name="fqdn"

In order to facililitate a machine-readable Rules of Engagement, or express similar terms, such as disclosures and limitations, the following prop and annotation fields are used. These are likely to be treated as FedRAMP extensions unless the cybersecurity community believes FedRAMP's ROE elements are more broadly applicable.

  - prop @name="results-delivery"  (# of days between completion of testing and delivery of results)
  - annotation @name="roe-forward"
    - remarks (any opening statements to the ROE)
  - annotation @name="disclosure"
    - remarks (a disclosure statement, such as may appear in an ROE)
  - annotation @name="limitation"
    - remarks (a limitation statement, such as limitaton of liability in an ROE)
  - annotation @name="roe-closing"
    - remarks (any closing statements to the ROE, such as the attestation above the signature block.)

Activities

In the SAP, these are the planned activities, including any planned deviations from the catalog-prescribed TEST, INSPECT, INTERVIEW actions for each in-scope control.

As with scope, activities can have two types. include (default) and exclude. Include explicitly defines the activities included in this assessment. Exclude defines the activities explicitly excluded form this assessment.

- activities [ 0 or 1 / 1 ]
  - test-method @id @type [ 0 or more / 1 or more ]
    - title [ 1 / 1]
    - description [ 1 / 1]
    - prop (for extensions) [ 0 or more / 0 or more ]
    - annotation (for extensions) [ 0 or more / 0 or more ]

  - schedule [ 0 or 1 / 1 ]
    - task @id
      - title [ 1 / 1]
      - description [ 1 / 1]
      - prop (for extensions) [ 0 or more / 0 or more ]
      - annotation (for extensions) [ 0 or more / 0 or more ]
      - start-date [ 1 / 1 ]
      - end-date [ 1 / 1 ]

  - included-activity @id [ 0 or more / 1 or more ]
    - title
    - description
    - prop
    - annotation
    - remark

To declare off-limit activities from the assessment, such as excluding social engineering, the same activities syntax is used.

  - excluded-activity
    - title
    - description
    - prop
    - annotation
    - remark

---

Related Topics

Notes on the Rules of Engagement (ROE)

The ROE can be generated from the above convent as described below; however, in early OSCAL adoption stakeholders are encouraged to accept the ROE as an attached docuemnt that is still produced in MS Word.

Even an ROE generated from the above content may still require assessor and system owner signatures, thus even a generated ROE may still need to be attached with cryptographic signatures, or as a scan of a hard-copy signed document.

A FedRAMP ROE is generated as follows:

• Introduction:
  • //assets/annotation[@name="roe-forward"] [ 0 or 1 ]
• Disclosures:
  • //assets/annotation[@name="disclosure"] [0 or more]
• Testing performed from the following IP addresses:
  • //assets/inventory-item [ 0 or more ]
• Security Testing May Include:
  • //activities[@type="include"]/activity [ 0 or more ]
• Security Testing Will NOT Include:
  • //activities[@type="exclude"]/activity [ 0 or more ]
• End of Testing Notification:
  • //metadata/role[@id='end-testing-POC'] [ 0 or more / 1 or more ]
• Communication of test results (within X days):
  • //assets/prop @name="results-delivery-time" [ 0 or 1 / 1 ]
• Communication of test results recipients:
  • //metadata/role[@id='results-recipients'] [ 0 or more / 1 or more ]
• Limitation of Liability:
  • //assets/annotation[@name="limitation"] [0 or more / 0 or more ]
• Attestation above signature:
  • //assets/annotation[@name="roe-closing"] [ 0 or 1 / 1 ]

Laws/Regulations/Standards/Guidance (LRSG)

The SAP inherits those cited in the SSP, and only includes additional LRSG as needed.

- back-matter
  - resource
    - citation

[brian-ruf]

Security Assessment Report (SAR) Syntax Mock-Up

Updated March 11, 2020 @ 9:10 PM EDT

Top Level Assemblies

security-assessment-results
 - metadata [ 1 / 1 ]
 - import [1 / 1 ] (SAR)
 - objectives
 - assessment-subject [ 0 or 1 / 1]
 - assets [ 0 or 1 / 1]
 - assessment-activities [ 0 or 1 / 1 ]
 - evidence [ 0 or 1 / 1 ]
 - results [ 1 / 1 ]
 - back-matter [ 0 or 1 / 1 ]

Cardinality Notes

Cardinality is in brackets. There are two cardinalities listed, separated by a slash. The first is the OSCAL cardinality The second is the FedRAMP cardinality, which is either as strict or more strict than the OSCAL cardinality.

Example: [0 or 1 / 1] means the cardinality for OSCAL syntax is 0 or 1; however, FedRAMP the FedRAMP cardinality is exactly 1.

Metadata

The following are handled using existing OSCAL Metadata syntax, thus are not re-modeled here:

- Title [1 / 1]
- Last-Modified [1 /1]
- OSCAL Syntax Version [1 / 1]
- Version [0 or 1 / 1]
- Publication Date [0 or 1 / 1]

Also Users, Roles, and Locations are modeled with standard Metadata syntax. This includes:

Roles: 
- Prepared By [ 0 or 1 / 1 ]
- Prepared For [ 0 or 1 / 1 ]
- Assessment teams [ 0 or more / 1 or more]

Parties:
- POCs
- Interviewed Staff Names, Roles, etc.

Assessment locations

Import

For SAR, only the SAP is imported.

- import href="" [ 1 / 1 ] (Security Assessment Plan)

Assessment Objectives

In the SAR, this identifies the controls that were actually assessed, along with their control objectives.

All controls in the linked profile (SAR -> SAP -> SSP -> Profile) may be specified using the all field, or a subset of those controls may be specified. For the identifed controls, all objectives may be specified using the all field, or a subset of objectives may be specified. Control objectives may also be defined and added to the assessment, but must be linked to an in-scope control.

- objectives
  - controls
    - all
    - include @control-id
    - exclude @control-id
  - control-objectives
    - all
    - include @objective-id
    - exclude @objective-id
    - objective @id
      - control-link @control-id

      (Same syntax as Catalog)
      - part name='' @id="sap-xx-#.a_obj"
        markup-multiline
        - prop name="label"
        - part id="xx-#.a_obj.1" name="objective"
          - promp name="label"
          - markup-multiline
        - part @id name='objective' [ 0 or 1 / 0 or 1 ]
          - prop name='label' [ 0 or 1 / 1 ]
          - markup-multiline [ 0 or 1 / 0 or 1 ]
      - part name='assessment' [ 0 or more / 0 or more ]
        - prop name='method'
        - part name='objects'

Adding to the SAR in this way is equivalent to adding rows in the test case workbook. An objective ID defined in the SAR must not duplicate an objective ID in the upstream SAP, profile or catalog.

Assessment Subject

In the SAR, this dentifies the system elements actually assessed, and which were avoided. This can include system components, inventory items, locations, and users. It also eanbles the the assessor to define any components, inventory-items, and users where they differ from the SSP content.

Assessment Subject has three sub-assemblies:

• subject-include explicitly defines what is included in the assessment's focus.
• subject-exclude explicitly defines what is excluded from the assessment's focus.
• local-definitions for anything not addressable elsewhere.

NOTE: In the SAR, local-definitions should not duplicate the SAP, but could be used for circumstances such as where an undocumented device was discovered on the network.

See the SAP Syntax Mock-Up for details.

NOTE: A tool could duplicate the SAP subject-include and subject-exclude statements into the SAR. The assessor could then modify it to reflect what was actually assessed. Later, a tool can compare the SAP assessment-subject with the SAR assessment-subject and report differences as assessment deviations.

NOTE: Local definitions in the SAP are addressable via the import-sap link, and should not be duplicated to the SAR.

Assets

In the SAR, these are the (teams and tools) actually involved in the performance of the assessment. Tools follow the component approach/syntax from SSP, but are focused on assessment tools rather than components of the system. This allows assessment teams to select component files for tools the same as with the SSP.

- assets
  - tools

  - origination

See the SAR mock-up.

Activities

In the SAR, these are the actual activities, including any actual deviations from the SAP.

(This syntax is identical to the activities assembly in the SAP)
- activities @type[ 0 or 1 / 1 ]
  - test-method @id @type [ 0 or more / 1 or more ]

  - schedule [ 0 or 1 / 1 ]

  - included-activity @id [ 0 or more / 1 or more ]

  - excluded-activity @id [ 0 or more / 1 or more ]

See the SAP mock-up for details.

Assessment Results

In the SAR, results take on different forms. All of which are represented in this structure and presented as different views.

All findings appear as entries in the test case workbook. The assessment team collects evidence in the form of inspections (notes of observations, screen shots, inspection tool output), interview notes, and tests performed (tools, scripts, and manual tests - each intended to observe a result).

Evidence can demonstrate that an assessment objective is satisfied. If the evidence demonstrates an objective is not satisfied, risk information becomes relevant.

FedRAMP follows NIST in that it assigns qualitative values (High, Moderate, Low) to impact and likelihood, as well as in the calculation of risk (impact x likelihood); however, OSCAL must support compliance frameworks that accept both qualitative and quantitative values. As such, these fields must support both. It may be possible to have both qualitative and quantitative entries for the same risk.

Risks discovered during testing have a status of "open". If closed during testing, status may be changed to "closed", only if the closure-actions field explains how the risk was addressed.

- evidence [ 0 or 1 / 1 ]
  - artifact @id  [ 0 or more / 1 or more ] (Either description or link must be present. Both may be present.)
    - title [ 0 or 1 / 0 or 1 ]
    - description  [ 0 or 1 / 0 or 1 ]
    - prop
    - annotation
    - link rel="interview-notes | tool-output | photo | questionnaire" @href="#back-matter-id"  [ 0 or 1 / 0 or 1 ]
    - remarks

- results @id  [ 1 or more / 1 or more ] (Each assessment has its own 'findings' assembly)
  - start (date-time stamp) [ 0 or 1 / 1 ]
  - end (date/time stamp) [ 0 or 1 / 1 ]
  - description [ 1 / 1]
  - finding @id [ 0 or more / 1 or more ]
    - title [ 0 or 1 / 0 or 1 ]
    - description  [ 0 or 1 / 0 or 1 ]
    - date-time-stamp

OJBECTIVE SATISFACTION

The objective-status links the finding to a specific control objective, or optionally to the entire control definition.

With most frameworks, the degree of control satisfaction is based on the degree to which all of its objectives are satisfied. In some cases, a control is only fully satisfied if every objective is fully stisfied. Below that could be pass/fail, scored, or some qualitative assignment.

The satisfied field is a boolean field for sorting and filtering. It indicates whether the objective is fully satisfied or not.

The implementation-status is a concise statement of the degree of implementation. For FedRAMP, these are constrained to one of five values; however, other frameworks may define different contraints (or no) constraints on this field.

NOTE: Link to control-objectives when possible. Only link to an entire control when linking to a control-objective is not possible or not appropriate.

NOTE: One control objective per finding assembly. Create a new finding assembly for each control objective assessed.

    - objective-status @objective-id @control-id [ 0 or more / 1 or more ]
      - satisfaction [ 0 or 1 / 0 ]
      - implementation-status [ 1 / 1 ]
      - remarks

      ** SSP Implementaiton Statement Differential handled as an observation. See the Related Topics section below.

OBSERVATIONS

    - observation @id  [ 0 or more / 1 or more ] (There _must_ be either a reference or a description. There _may_ be both.)
      - title [ 0 or 1 / 0 or 1 ]
      - description [ 0 or 1 / 1 ]
      - prop  [ 0 or more / 0 or more ]
      - annotation [ 0 or more / 0 or more ]
      - observation-type
      - reference @ref-id @type=(tool, party, test method) [ 0 or 1 / 0 or 1 ]
      - target
        - prop name="authenticated-scan"
        - component-id
        - inventory-item-id
      - assessor @party-id
      - relevant-evidence @evidencie-id @type="observation | vulnerability | false-positive | operational-requirement | risk-adjustment"
        - description
      - remarks
    - threat-id system="https://fedramp.gov" [ 0 or more / 0 or more ]

RISK There are many ways risk is defined, measured, calculated, and assessed. In order to offer flexibility of risk metrics and calculations, OSCAL uses prop fields with name flags for all risk-related fields.

FedRAMP uses likelihood and impact to "calculate" risk exposure, using qualitative values (high, moderate, and low). FedRAMP sometimes allows the consideration of mitigating factors to adjust likelihood and impact (thus adjusting risk exposure). As a result, there are always initial values, and sometimes also mitigated values.

    - risk [ 0 or more / 0 or more ]
      - title [ 0 or 1 / 0 or 1 ]
      - description  [ 0 or 1 / 1 ]
      - prop name="impacted-control" [ 0 or more / 1 or more ]
      - prop name="vulnerability-id" class="tool-name" [ 1 / 1 ]
      - prop name="vulnerability-id" class="cve" [ 0 or 1 / 0 or 1 ]
      - prop name="source-id" class="tool-name" [ 1 / 1 ] (Such as plug-in ID)
      - prop name="likelihood" class="initial" [ 1 / 1 ]
      - prop name="impact" class="initial" [ 1 / 1 ]
      - prop name="risk" class="initial" system="https://fedramp.gov"
      - prop name="cvss-metrics" class="CVSSv3" (** See Note Below)
      - prop name="risk-reduction-auto-approve" system="https://fedramp.gov"
      - risk-statement  [ 1 / 1]
      - mitigating-factor @implementation-id  [ 0 or more / 0 or more ]
      - prop name="likelihood" class="residual" [ 1 / 1 ]
      - prop name="impact" class="residual" [ 1 / 1 ]
      - prop name="risk" class="residual" system="https://fedramp.gov"
      - remediation type='recommendation' source-id='' [ 0 or more / 1 or more]
      - status [ 0 or 1 / 1]
      - closure-actions  [ 0 or 1 / 0 or 1]
      - annotation name="vendor-dependency"
        - remarks (justification)
      - annotation name="risk-adjustment"
        - remarks (justification)
      - annotation name="operational-requirement"
        - remarks (justification)
      - annotation name="false-positive"
        - remarks (justification)
      - remediation-planning
        - annotation "resources-required"
          - remarks
          - schedule
            - task @id
              - title
              - description
              - start-date
              - end-date
      - remediation-tracking
        - title
        - date-time-stamp
        - annotation name="status-update"
          - remarks
        - annotation name="schedule-update"
          - remarks
        - annotation name="vendor-check-in"
          - remarks
      - remarks (overall to identified risk) [ 0 or 1 / 0 or 1]
    - point-of-contact @party-id  [ 0 or more / 1 or more ]
    - priority @ns='https://fedramp.gov/ns/oscal'
  - remarks  [ 0 or 1 / 0 or 1]

** See the OSCAL-based CVSS Scoring Table.

NOTES ON RISK FIELDS

For calculated risk values, a system flag identifies the method or source of calculation used to assign risk values.

FedRAMP values are represented as follows:

      - prop name="likelihood" class="initial" [ 1 / 1 ]
      - prop name="impact" class="initial" [ 1 / 1 ]
      - prop name="risk" class="initial" system="https://fedramp.gov"

      - prop name="likelihood" class="residual" [ 1 / 1 ]
      - prop name="impact" class="residual" [ 1 / 1 ]
      - prop name="risk" class="residual" system="https://fedramp.gov"

This approach allows risk values from different systems to be present within the same OSCAL file, including both qualitative and quantitative approaches. Below are a few examples, other mixed risk fields. The names, classes, and systems will likely be modified and evolve as the community reviews these initial recommendations.

- impact 
    <prop name="impact" class="initial">high</prop>
    <prop name="confidentiality-impact" class="initial">72</prop>
    <prop name="integrity-impact" class="initial">64</prop>
    <prop name="availability-impact" class="initial">86</prop>
- likelihood
    <prop name="likelihood" class="initial">moderate</prop>
    <prop name="confidentiality-likelihood" class="initial">70</prop>
    <prop name="integrity-likelihood" class="initial">78</prop>
    <prop name="availability-likelihood" class="initial">42</prop>
- threat
    <prop name="threat-level" class="initial">moderate</prop>
- mitigating factors 
    <mitigating-factors class="overall"><p>Description</p></mitigating-factors>
    <mitigating-factors class="likelihood"><p>Description</p></mitigating-factors>
    <mitigating-factors class="impact"><p>Description</p></mitigating-factors>
    <mitigating-factors class="confidentiality"><p>Description</p></mitigating-factors>
    <mitigating-factors class="integrity"><p>Description</p></mitigating-factors>
    <mitigating-factors class="availability"><p>Description</p></mitigating-factors>

- CVSS Scoring (partial)
    <prop class="CVSSv3.1" name="attack-vector">network</prop>
    <prop class="CVSSv3.1" name="attack-complexity">low</prop>
    <prop class="CVSSv3.1" name="privileges-required">none</prop>
    <prop class="CVSSv3.1" name="user-interaction">required</prop>
    <prop class="CVSSv3.1" name="scope">unchanged</prop>
    <prop class="CVSSv3.1" name="confidentiality">none</prop>
    <prop class="CVSSv3.1" name="integrity">high</prop>
    <prop class="CVSSv3.1" name="availability">high</prop>
- risk
    <prop name="risk" class="initial" system="https://fedramp.gov">high</prop>
    <prop name="risk" class="residual" system="https://fedramp.gov">moderate</prop>
    <prop name="risk" class="initial" system="https://financial.industry">68</prop>
    <prop name="risk" class="residual" system="https://financial.industry">45</prop>

Related Topics

Notes on documenting SAP deviaitons in the SAR

The FedRAMP SAR requires assessors to document deviations from the SAP in the SAR.

The SAP is intended for system owners and authorizing officials (AOs) to know in advance whether planned assessment testing is acceptable. For this reason, it is important to know when the actual assessment deviates from the plan.

Under OSCAL, the SAP captures the intended objectives, subjects, assets, and activities. The SAR catpures the actual objectives, subjects, assets, and activities using the same OSCAL syntax.

This enables automated comparision of the SAP and SAR to identify the differences with no additional effort on the part of the assessor.

SSP Implementation Statement Differential

For each instances of an assessor finding an SSP implementation statement that does not match the actual observed implementation, this is treated as an observation instance, with an observation-type of "implementation-statement"

Laws/Regulations/Standards/Guidance (LRSG)

The SAR inherits those cited in the SSP and SAP, and only includes additional LRSG as needed.

- back-matter
  - resource
    - citation

Evidence

SAR evidence is attached or embedded within back-matter. This may include interview notes, photos, screen shots, tool output, raw scan results, and other files as needed. NOTE: As with all resource assemblies, if both rlink and base64 are present, the tool developer is free to use either, or compare both; however, NIST encourages tool developers to give preference to base64, as a best practice.

- back-matter
  - resource
    - rlink
  - resource
    - base64
  - resource
    - rlink
    - base64

[brian-ruf]

SAP, SAR and POA&M are mapped to mocked-up OSCAL syntax HERE

[brian-ruf]

Plan of Action and Milestones (POA&M) Syntax Mock-Up

Updated March 12, 2020 @ 9:50 AM EDT

Top Level Assemblies

plan-of-action-and-milestones
 - metadata [ 1 / 1 ]
 - import (system security plan) [ 0 or 1 / 0 or 1 ]
 - system-characteristics  [ 0 or 1 / 0 or 1 ]
 - evidence [ 0 or 1 / 0 or 1 ]
 - results [ 1 / 1 ]
 - back-matter [ 0 or 1 / 0 or 1 ]

Cardinality Notes

Cardinality is in brackets. There are two cardinalities listed, separated by a slash. The first is the OSCAL cardinality The second is the FedRAMP cardinality, which is either as strict or more strict than the OSCAL cardinality.

Example: [0 or 1 / 1] means the cardinality for OSCAL syntax is 0 or 1; however, FedRAMP the FedRAMP cardinality is exactly 1.

Metadata

The following are handled using existing OSCAL Metadata syntax, thus are not re-modeled here:

- Title [1 / 1]
- Last-Modified [1 /1]
- OSCAL Syntax Version [1 / 1]
- Version [0 or 1 / 0 or 1 ]
- Publication Date [0 or 1 / 1]

Also Users, Roles, and Locaitons are modeled with standard Metadata syntax. This includes:

Roles: 
- Prepared By [ 0 or 1 / 1 ]
- Prepared For [ 0 or 1 / 1 ]
- Other roles as needed for reference within individual POA&M entries or DRs.

Parties:
- CSP  [ 0 or 1 / 1 ]
- Primary CSP POC [ 0 or 1 / 1 ]
- Other parties as needed for reference within individual POA&M entries or DRs.

Locations: 
- Only if needed for reference within individual POA&M entires or DRs.

Import and System

For POA&M, only the SSP is imported. Either the SSP must be imported, or the `system assembly must be present with sufficient information for identifying the system. Both may be present. If both are present and ID duplication existis, tools should override the SSP content with the data present in the OSCAL-based POA&M file.

Rationale: POA&Ms are updated frequently, and shared far more often than an SSP. There are use cases for a POA&M to be imported into a repository that already has information about the system, thus only a unique system identifier (such as the FedRAMP assigned ID) is necessary in the POA&M.

- import href="" [ 0 or 1 / 0 or 1 ] (System Security Plan)

OR

- system-characteristics [ 0 or 1 / 0 or 1 ]
  - system-id [ 1 or more / 1 or more ]
  - system-name [ 1 / 1 ]
  - system-name-short [ 0 or 1 / 1 ]
  - description [ 1 / 1 ]
  - prop (for extensions) [ 0 or more / 0 or more ]
  - annotation (for extensions) [ 0 or more / 0 or more ]
  - date-authorized [ 0 or 1 / 1 ]
  - security-sensitivity-level [ 1 / 1 ]

POA&M Entries

POA&M Evidence and POA&M Results uses the same syntax as the SAR. For more information, see the POA&M column of the TCW-RET-POA&M Mapping Spreadsheet

Also, see the SAR Syntax Mock-up for details on the Evidence and Results assemblies.

[brian-ruf]

5-Mar-2020 Status

This is greater than 90% complete and should be wrapped up in the next few days.

Updated SAR "results" assembly significantly. Performed substantial analysis to ensure it can be used for Test Case Workbook, Risk Exposure Table, and POA&M. Also ensured it could be filtered to create views that are equivalent to the many SAR tables, such as operationally required risks (ORs), false positive findings (FPs), and risks closed during testing.

Still waiting on some feedback from senior FedRAMP JAB reviewers and authorization leads. Also need to discuss some issues with NIST.

Please view the TCW-RET-POA&M Mapping Spreadsheet to see how the same structure is used for these three key risk tables, plus other sources and tables.

[brian-ruf]

Above syntax mock-up is now 100% draft. It is likely to be tweaked as it gets reviewed and as we begin translating it to metaschema.

[brian-ruf]

12-Mar-2020 Status

Have refined the diagrams and mock-ups in this issue several times over the past week as I've started modeling this content in OSCAL. Details are covered in Issue #621 (SAP, SAR, and POA&M Metaschema Modeling)

[brian-ruf]

Going forward, diagram updates will be added to Issue #621, so that this issue can be frozen and closed. Updates to the mock-ups in this issue will no longer be made now that the syntax work is nearly complete and under refinement.

This issue should be closed, pending final review.