Recording Evidence and Status of a Satisfied Control?

[flickerfly]

I'm trying to wrap my head around the Assessment Results model. I'm assuming this is where I'd put information about how I've tested for and confirmed compliance to a specific control, but I'm struggling to wrap my head around it.

Would this type of information in the AR be in the "reviewed controls" or part of the "assessment log"? Maybe I'm way off on how this should be done.

Thanks!

[aj-stein-nist]

That's a great question. I guess it really depends on what specifically you are documenting that "tested for and confirmed compliance to a specific control." Do you mean what you had done at the level of description in 800-53 assessment procedures (like 800-53A's objectives and interview criteria for "[determining] the frequency of baseline configuration review and update is defined by [interviewing] organizational personnel with configuration management responsibilities" or the details supporting that objective and methods?

I am not sure it will be super helpful, but the FedRAMP Guide to OSCAL-based SARs show how some of that information would look in existing FedRAMP documents (that might not be your exact use case), but the detail around the specific topic you asked about are scant.

Some more detailed examples would help better answer the question (at least for me).

[iMichaela]

I think you rightly point out the lack of following the expected flow. I'm trying to first hit the requirement of providing the eMASS Test Results document and then figure out how to model that in OSCAL as the intermediate document.

AJ and I could tell you (because we've seen it happen) that if you do not have a plan for passing information from the AP to eMASS of WHAT (link to the uuids) and HOW to assess, you might have a very hard time to relate the results to WHAT and to demonstrate that the HOW defined in the AP was met.

[iMichaela]

So we have a few CDefs that are evaluated through a Continuous Integration pipeline.

You can think of those CDefs being PROVISIONALLY A&A. Only a system owner can review the P-A&A CDefs and include them into the system. A review coming from the sys owner or authorizing official is a must because only he/she can assess the risk. Any tailoring will require a Re-A&A. An assessment of inherited controls and stacked solutions is a must as well, especially for CDEfs that rely on the environment for defense.

[iMichaela]

Another objective our team is pushing is trying to require as little application developer knowledge of OSCAL as possible (keeping it in the pipeline context) to accelerate initial adoption,

In my experience, this can be achieved with simple wish lists or questions or checklists mapped on the back-end to OSCAL-formatted 'answeres'/code.

[flickerfly]

@iMichaela Thank you for all those thoughts!

[aj-stein-nist]

Also, personally I'd love your attention on #1058 as it evolves, as this further examination of this topic. Not necessarily your immediate question, but more to come on how to make this more specific (it's already possible in OSCAL with SAP and SAR) before SAP and SAR time.