Map validation rules to current FedRAMP review processes #45
Conversation
Establishes `response-point` properties in the FedRAMP High, Moderate, and Low Rev 4 profiles to clearly identify the statement level at which FedRAMP requires CSPs to respond to controls definitions within the SSP for each control (part a, part b.1, part b.2, etc.). These response-points align with the exiting Rev 4 High, Moderate, and Low FedRAMP SSP Word Templates. This change also identifies the control objective level at which assessors must respond to control objectives within the Test Case Workbook (TCW). This replaces the use of FedRAMP conformity tags for this purpose, and brings the control-objective approach into better alignment with the control definition approach above. These response-points align with the exiting Rev 4 High, Moderate, and Low TCW Excel Templates.
Per discussion over pending work in #32, we want to further enhance the XML content defined in the FedRAMP Registry as saved in the Excel XSLX file to include defined identifiers for roles particular to FedRAMP not the current milestone release of upstream OSCAL.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@brianrufgsa, I know we had discussed this earlier this week, but will mapping tasklists like this for Section B and Section C into comments about individuals rule checks ( I wanted you to have take a look next week and let me know, and if this works for now, I will proceed on integrating this more fully into the README, source code, and outputs as offered. Have a good weeekend! |
…ement-ids Fix statement IDs for example SSP.
Add defined identifiers values for only FedRAMP role types.
…e-ssp-statement-ids Revert "Fix statement IDs for example SSP."
Updating OSCAL repo commit and fixing ajv dependency version
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
For #40, we will move a high-level mapping of rules to the README and technical information will go to the CONTRIBUTING.md file.
Per conversation with @brianrufgsa earlier this week, as we continue to follow the dichotomy of informational validation data in sch:report and encoding warnings and errors in sch:assert checks, it is not completely transparent that the reports are information that is not an error, but a useful reporting item. Brian suggested he would like this to be marked with something like positive, so we shall start doing that and document it.
* adding a spec that is broken in the spirit of: - make it break - make it work - make it pretty Formatting Report... passed: 21 / pending: 0 / failed: 4 / total: 25 * surpress some of the xpspec output * fix the test * make scenario for party be invalid party-uuid instead of role-id * fix id's to be more specific * make scenario for rol be invalid role-id instead of party-uuid * add rule for parties, roles and responsible-party association * restructure test location under master SSP scenario per feedback
ohsh6o
force-pushed
the
issue-40-map-validations-to-fedramp-workflow-checklist
branch
from
35b135f
to
b09b78d
Compare
There was a problem hiding this comment.
I like the approach, having an attribute organizational-id dedicated to the crosswalk to the authorizing bodies process.
Given the scope of the validations will most likely be contained in the context of a repository, it may not be necessary but I wonder aloud if we should consider an organizational-body in this case organizational-body = FedRAMP to contextualize/scope the rule we are implementing.
|
|
||
| ## What is this? | ||
|
|
||
| This is the FedRAMP Validation Suite, a framework to take [FedRAMP documentation](https://www.fedramp.gov/templates/) that is properly formatted with [NIST OSCAL schemas](https://pages.nist.gov/OSCAL/) and check the content for correctness. [FedRAMP's adoption of OSCAL](https://www.youtube.com/watch?v=WCPkt56vZ-s) allows you to use this framework to perform logical validations, i.e. business rule checks, on documentation content. Currently, FedRAMP staff manually review the content provided by a cloud service provider for all steps of the [different](https://github.com/GSA/fedramp-gov/blob/master/assets/img/agency-auth.png) [authorization](https://github.com/GSA/fedramp-gov/blob/master/assets/img/ato-auth.png) processes. This framework and the associated business rules will automate as many of these checks as possible. Shared expectations are the goal: system owners, third-party assessors, or any interested party can use them as well. |
There was a problem hiding this comment.
I think this is a good distinction to make. I can see this readme incorporate a link to (or a marked-up version) of this. The reason to potentially 'mark it up' would be to indicate where in the process flow this instrumentation lives (think "you are here"). Additionally, when the adjudication extension is adopted, updating the readme to switch any vernacular that is specific to the model will further strengthen the concept.
Match GSA/fedramp-automation where they are at per [the Gitter convo](https://gitter.im/usnistgov-OSCAL/FedRAMP-10x-Schematron?at=6000db373d722a42e782a5ff).
ohsh6o
deleted the
issue-40-map-validations-to-fedramp-workflow-checklist
branch
This comment has been minimized.
This comment has been minimized.
2 similar comments
Implements #40.