Closed brian-ruf closed 4 years ago
This effort will create preliminary OSCAL syntax to address the FedRAMP SAP, SAR and POA&M:
NOTE: Creating the FedRAMP-specific implementation guide is outside the scope of this effort.
FedRAMP currently has separate SAP and SAR templates for the initial assessment vs. the annual assessment. They are similar but not identical, and must be analyzed separately. The initial and annual templates will be collapsed into a single OSCAL model for each document type as follows:
Template | Model |
---|---|
Initial SAP | SAP model |
Annual SAP | |
Initial SAR | SAR model |
Annual SAR | |
POA&M Template | POA&M Model |
Deviation Request (DR) |
FedRAMP (and possibly other frameworks) requires the assessor to document deviations from the SAP in the SAR.
I am taking the approach that the SAP documents what is intended to happen during an assessment, while the SAR documents what actually happened. As a result, most deviations can be generated by comparing an OSCAL-based SAP to an OSCAL-based SAR.
Example 1, Tools:
Example 2, Scope:
This somewhat departs from the OSCAL concept of avoiding duplication, and instead pointing to upstream data; however, in this instances, I believe it is important the SAR explicitly document exactly what did happen and exactly what was used.
Some data duplication will result. but I would liken it to a double-entry accounting system, where all transactions are entered twice in two different accounts, as a form of checks and balances.
Some OSCAL tools might pre-populate the SAR content from the SAP, such as copying the list of intended assessment tools; however, if an assessment tool from the SAP list is not used, there will be no results linked to it. Likewise, if an assessment tool was used, but not listed in the SAP, no results could be linked to it until it was entered into the SAR list. Similar statements can be made of control scope and results.
In other words, the linking of results/findings, force the SAR lists to be accurate, and allow the SAR to be compared to the SAP for deviation analysis.
An example of this upstream data is the inspec results data we use in the heimdall data format work links inspec test results to controls
On Tue, Jan 21, 2020, 10:58 AM Brian Ruf notifications@github.com wrote:
FedRAMP (and possibly other frameworks) requires the SAR document any deviations from the SAP.
I am taking the approach that the SAP documents what is intended to happen, while the SAR documents what actually happened during the assessment. Most deviations can be generated by comparing the SAP to the SAR.
Example 1, Tools:
- SAP lists intended assessment tools to be used.
- SAR captures actual assessment tools used, and links results to each.
- Deviation of tool usage is generated by comparing the two lists.
Example 2, Scope:
- SAP lists intended controls to assess (annual assessments don't test all controls)
- SAR captures actual controls assessed, and links findings to each control.
- Deviation of control scope is generated by comparing the two lists.
This somewhat departs from the OSCAL concept of avoiding duplication, and instead pointing to upstream data; however, in this instances, I believe it is important the SAR explicitly document exactly what did happen and exactly what was used.
Some data duplication will result. but I would liken it to a double-entry accounting system, where all transactions are entered twice in two different accounts, as a form of checks and balances.
Some OSCAL tools might pre-populate the SAR content from the SAP, such as copying the list of intended assessment tools; however, if an assessment tool from the SAP list is not used, there will be no results linked to it. Likewise, if an assessment tool was used, but not listed in the SAP, no results could be linked to it until it was entered into the SAR list. Similar statements can be made of control scope and results.
In other words, the linking of results/findings, force the SAR lists to be accurate, and allow the SAR to be compared to the SAP for deviation analysis.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/usnistgov/OSCAL/issues/589?email_source=notifications&email_token=AALK42FMGATGBUXEOCK5DG3Q64LR5A5CNFSM4KDJVLR2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJQH5LI#issuecomment-576749229, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALK42DYRECSGQHWIDR4LZTQ64LR5ANCNFSM4KDJVLRQ .
Nearly finished information inventory, with some preliminary modeling decisions/concepts sketched out.
Inventory complete. Finalizing data type, cardinality, source, and recommendations for OSCAL core vs. FedRAMP extension. Expect to have that wrapped up by COB today.
Issue #588 (Perform an information element inventory) complete, pending review. Established and started working Issue #617 (SAP, SAR and POA&M Syntax Diagrams and Mock-Up). Worked on high-level diagrams.
Go at least one level deeper (more detailed) on relationship diagrams. More if needed. Begin syntax mock-up.
The FedRAMP SAR carries a notion of past results, which are typically an annual snapshot. One goal of OSCAL is to better enable continuous monitoring. An approach to historic results is needed that can:
The ability to handle incomplete or missing historic information is important for
`findings
assembly, multiple findings assemblies could be allowed. Each represents a grouping of findings. For the assessment cycle approach, there would be one findings
assembly for each assessment cycle.
For the continuous approach, the use of this grouping could be more at the tool creator's discretion. For example, a tool generating SAR data could group findings under the findings
assembly based on:
findings
wrapper per result or per componentfindings
assemblyStill catching up from extended illness. Made some progress on this. Expect to make up time and complete by end of month as originally scheduled.
Discussion point: While FedRAMP will always require a SAP, is it possible that OSCAL will need to support a SAR without a SAP?
The current plan is for SAR to import SSP content via the SAP (SAR -> SAP -> SSP); however, should we also allow/enable a direct connection between the SAR and the SSP (SAR -> SSP)?
With the current approach to syntax modeling, this would be easy to support since the SAR syntax is intended to mimic and expand on the SAP syntax with the SAP being the "intended" assets and activities, while the SAR is the "actual assets and activities (plus findings). Allowing a direct SAR->SSP connection would only lose the ability to compare in intended assessment plan to the actual execution.
This may be important in a continuous assessment situation.
Still catching up after being sick. Nearly finished with issue #617 (details added to that issue). Expect to be finished with diagrams and syntax mock-up early next week and transition to metaschema development at that time.
Almost caught up on phase II. There are several views and tables in the SAR, which are all inter-related, and relate closely to the POA&M.
The Assessment Results assembly in the SAR model is going to be a normalized single set of information, on which the Test Case Workbook, Risk Exposure Table, and POA&M are based. Many of the other tables in the SAR are going to be "views" of this information.
This is proving to be more complicated than expected - especially ensuring all of the data correlates properly. I have a detailed mapping HERE.
I also have a data call out to several seasoned FedRAMP reviewers to validate and double-check my understanding of how all this information flows from the TCW to the RET to the POA&M (plus related tables). That feedback started to come in during the afternoon of 4-Mar, and results in some tweaking to this information.
I will also do a final round of validation with NIST Friday, and then will transition fully to modeling the syntax in the metaschema.
Wrapped up Phase II and started Phase III, which focuses on creating the actual syntax using the NIST metaschema language. In the early stages of Phase III there have been several adjustments to the model.
The Phase II diagrams and syntax mock-ups in issue #617 were updated to reflect these changes, and a summary of the changes can be found in this week's status entry to issue #621.
Phase III is nearly complete. A full draft of OSCAL syntax for SAP, SAR, and POA&M is complete, and some progress has been made on verifying cardinality, formal names and descriptions; however, more quality reviews are required to ensure those are accurate. The quality reviews should be complete by COB Friday.
Added issue #639 SAP, SAR, and POA&M Sample Files and Syntax Refinement.
I was still making updates to the mock-ups and diagrams in issue #617. In an effort to close that issue, diagram updates are now maintained in issue #621. The syntax is modeled enough that mock-up updates are no longer helpful. Will continue to maintain the three major tabs in the Information Inventory for now.
Phase III is complete and ready for review. See issue #621 for links to the work.
External to this, I am starting to work on the FedRAMP guidebooks for FedRAMP-compliant SAP, SAR, and POA&M implementation in OSCAL. I will be developing the examples and sample files in issue #639 in parallel to the guidebook development.
Wrapped up the metaschema work in issue #621, and transitioning to focus on issue #639.
All three metaschema models passed all automated checks, and have been published to the repo and the web site.
This work is complete.
User Story:
As an OSCAL syntax modeler, I need to develop syntax for the system assessment plan (SAP), system assessment report (SAR) and plan of actions and milestones (POA&M) using an approach agreeable to FedRAMP and NIST/OSCAL leadership.
Goals:
Document the fundamental concepts, scope, and planned activities for development of preliminary OSCAL syntax in support of FedRAMP SAP, SAR, and POA&M artifacts.
This work will be conducted over a series of issues:
Dependencies:
None.
Acceptance Criteria