Content Approval/Signature Date representation in OSCAL SSP

[SParekh]

• This is a ...

  • concern - I think something needs to be different.
  • question - I didn't understand something.
  • kudos - I found something helpful and want to encourage it in future FedRAMP publications.
  • request - I would like to see something additional provided.

• This relates to ...

  • the FedRAMP OSCAL Registry (Excel File)
  • the Guide to OSCAL-based FedRAMP Content (PDF)
  • the Guide to OSCAL-based FedRAMP System Security Plans (SSP) (PDF)
  • the Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP) (PDF)
  • the Guide to OSCAL-based FedRAMP Security Assessment Reports (SAR) (PDF)
  • the Guide to OSCAL-based FedRAMP Plan of Action and Milestones (POA&M) (PDF)
  • the FedRAMP SSP OSCAL Template (JSON or XML Format)
  • the FedRAMP SAP OSCAL Template (JSON or XML Format)
  • the FedRAMP SAR OSCAL Template (JSON or XML Format)
  • the FedRAMP POA&M OSCAL Template (JSON or XML Format)
  • General/Overall
  • Other

• Where, exactly?
  Guide_to_OSCAL-based_FedRAMP_Content.pdf
  Guide Version: fedramp1.0.1-oscal1.0.0
  Section: 4.7. Document Approval
  Page: 38

• What?
  The sample provided details on how to represent "Content Approver" (Party/Role), however there is no detail around how to represent the Approval/Signature "date". Would be helpful to have an example on how the same would be represented.

[ohsh6o]

@SParekh you only want clarity on only how the date and time field ought to be defined? The complexity of digital signatures has been discussed in the larger OSCAL community before.

The problem is this talks about responsible parties and contact info, but the representative OSCAL on the right-hand side does not completely map 100% to the image of the relevant copy of the Word-based template on the left hand side. You will notice in fact nothing in the OSCAL models exists, by default or in current FedRAMP extensions, to show ATO status and signatures. We do, however, allow you to give the FedRAMP ID for a system-identifier for an ongoing FedRAMPed authorization.

Do you have a more pressing need for this?

[SParekh]

@ohsh6o

Yes - We only want clarity only on how the date and time field ought to be defined.

We did see OSCAL did not have representation of it but we assumed FedRAMP might have extension for it and it might just have been an issue with documentation.

We have pressing need for this. I am not sure how FedRAMP Id for System-Identifier is going to answer the above question.

[ohsh6o]

From my perspective, @SParekh, most who are concerned with the approval status are those outside the agency system owners or engineers, i.e. external parties leveraging the authorization. In that sense, I mean you can referenced the FedRAMP package ID and confirm status through FedRAMP's website (marketplace.fedramp.gov) or its backing data (to save API calls). I presume this is not the use case you are interested in.

I do understand internally system engineers or system owners of a package themselves would want that. Is that what you mean?

I guess in terms of extension, one possibility would be adding information on or adjacent to /system-security-plan/system-characteristics/state, but I would prefer an upstream solution if possible.

[SParekh]

@ohsh6o - We are leveraging this in context of an SSP.

To represent a complete SSP snapshot that has been approved (by whom/when), this data would be required. By itself, there is no meaning to having "Content Approvers" and little surprising that there are "Content Approvers" role but no movement around actual Content Approvals

Is there any ongoing discussion around this that I can track so I don't duplicate this question on OSCAL github.

[ohsh6o]

I remember a discussion verbally with OSCAL devs in a model meeting 2-3 months ago. I will search and check with the NIST devs if I cannot find a definitive approach or an ongoing issue to track, @SParekh.

[ohsh6o]

I am sorry it seems I was very much mistaken! @SParekh, It appears system-security-plan/system-characteristics/date-authorized is the date field, just separate of the signature field.

[SParekh]

@ohsh6o
Really appreciate your help in identifying this information. Would it be fair to say that to represent "Content Approvals" under FedRAMP word in OSCAL

1. Step to setup the "Content Approvers" same as documented under Guide_to_OSCAL-based_FedRAMP_Content.pdf
2. In system-security-plan/system-characteristics/date-authorized --> Set the System Authorization date i.e. 'Content Approval Date" and same date would apply to all the "content approvals"

Not urgent but would be great if this can be represented in Guide_to_OSCAL-based_FedRAMP_Content.pdf]

Thanks

[ohsh6o]

@ohsh6o
Really appreciate your help in identifying this information. Would it be fair to say that to represent "Content Approvals" under FedRAMP word in OSCAL

That's what we are here for!

1. Step to setup the "Content Approvers" same as documented under [Guide_to_OSCAL-based_FedRAMP_Content.pdf](https://github.com/GSA/fedramp-automation/blob/master/documents/Guide_to_OSCAL-based_FedRAMP_Content.pdf)

I think content approvers really means "people in your company" (for a CSP) that review the content and sign off on it, like business owners. This is different from the agency official, the authorizing-official, that is the responsible role from a party that matters for date-authorized. See 4.7 in Guide to OSCAL-based FedRAMP System Security Plans.

2. In   system-security-plan/system-characteristics/date-authorized --> Set the System Authorization date i.e. 'Content Approval Date" and same date would apply to all the "content approvals"

As explained above, the only real role that matters to RMF, how FedRAMP practices RMF, and the OSCAL that represents that is the authorizing-official role.

I pointed out the above in 1 to explain my answer better for point two. I will discuss with FedRAMP policy members if content approvers is a required role for a party like a CSP in FedRAMP. I think here, it was just a suggestion.

Since this would imply (internal) content reviews by relevant members of a CSP, it might be best for your tools to add a custom prop such as date-content-approved adjacent to the system-security-plan/system-characteristics/date-authorized and given it a proper namespace (for you or your company such as <prop ns="https://sparekh.github.io/ns/oscal" name="date-content-approved" value="20210101"/>. Perhaps you can also add similar the UUID of the content reviewer by UUID reference and make that the value of <prop ns="https://sparekh.github.io/ns/oscal" name="content-approver" value="#01226254-84f1-4045-8195-aceda74ca962"/> <!-- that UUID maps to a role in a party for a content-approve role --> or some such. (When I have more time, I can flesh this out into the relevant JSON equivalent. I know you prefer that from prior conversation).

I would argue this is a short-term solution. Properly marking it with ns="https://sparekh.github.io/ns/oscal" ensures that extra data for your tools can be stored, and at this time, FedRAMP will not analyze that as a mandatory requirement. This would give you the best of both worlds. More detail on a long-term approach below.

Not urgent but would be great if this can be represented in Guide_to_OSCAL-based_FedRAMP_Content.pdf]

Thanks for explaining urgency. I would propose this as a short to medium-term solution. Longer-term, it would seem advisable to connect this information to the metadata revisions header for SSP and all other models so you can tie approvals to the current version, or whichever version in the chain was approved, and track subsequent modifications to walk back the changes.

Does this approach make sense to you? I would like to bring this up in the NIST OSCAL Use Cases group and a relevant Github issue accordingly! :-)

[ohsh6o]

@SParekh do you have any issues or concerns with this approach? Is the short-term solution acceptable? Is the long-term approach acceptable?

[SParekh]

@ohsh6o - Please excuse delay in responding back to you suggestion.

Our understanding is that given an SSP in OSCAL format, it should be able to reflect what current FedRAMP Word document contains (For legacy purpose) and we can generate word document if required from given OSCAL XML or JSON.

As current FedRAMP word document requires a list of "SSP Content Approvals" and it has corresponding date, in long term we would assume placeholder similar to "Revision History" would be reflected in OSCAL Format.

Regarding your suggestion -

Adding it to Props of "System characteristics" does not align, because understanding is that this data "Content Approvals" is associated to ANY document (as you have mentioned in your long term solution). If we have to achieve a hack for now, would it be better to add it to "Metadata.Props" instead of "SystemCharacteristics.Props"

Additionally, key of "Content Approvals" is tie both Content Approver and corresponding Approval Date as I am assuming content can be approved on different dates by internal Approvers.

Would it be better to have following as way to reflect it ?

<Metadata>
<prop ns="https://sparekh.github.io/ns/oscal" name="content-approved-by" value="#01226254-84f1-4045-8195-aceda74ca962" remarks="2021-01-01"/> <!-- that UUID maps to a role in a party for a content-approve role and remarks containing date till we have more concrete way of representing this-->
<prop ns="https://sparekh.github.io/ns/oscal" name="content-approved-by" value="#93226254-74f1-1345-2222-aceda74ca962" remarks="2021-02-01"/> 
</Metadata>

[ohsh6o]

@ohsh6o - Please excuse delay in responding back to you suggestion.

Please accept my apologies, @SParekh, for my delay in responding to you after catching up from leave. :-)

Our understanding is that given an SSP in OSCAL format, it should be able to reflect what current FedRAMP Word document contains (For legacy purpose) and we can generate word document if required from given OSCAL XML or JSON.

That totally makes sense, I agree with that approach.

As current FedRAMP word document requires a list of "SSP Content Approvals" and it has corresponding date, in long term we would assume placeholder similar to "Revision History" would be reflected in OSCAL Format.

To be clear, you mean, in the most recent version of the Word (DOCX) template, this section is before Information System / Title, correct?

Regarding your suggestion -

Adding it to Props of "System characteristics" does not align, because understanding is that this data "Content Approvals" is associated to ANY document (as you have mentioned in your long term solution). If we have to achieve a hack for now, would it be better to add it to "Metadata.Props" instead of "SystemCharacteristics.Props"

Now that you have pointed me to which section of the Word-based template, I can agree with this.

Additionally, key of "Content Approvals" is tie both Content Approver and corresponding Approval Date as I am assuming content can be approved on different dates by internal Approvers.

I do not see why not, that makes sense.

Would it be better to have following as way to reflect it ?

<Metadata>
<prop ns="https://sparekh.github.io/ns/oscal" name="content-approved-by" value="#01226254-84f1-4045-8195-aceda74ca962" remarks="2021-01-01"/> <!-- that UUID maps to a role in a party for a content-approve role and remarks containing date till we have more concrete way of representing this-->
<prop ns="https://sparekh.github.io/ns/oscal" name="content-approved-by" value="#93226254-74f1-1345-2222-aceda74ca962" remarks="2021-02-01"/> 
</Metadata>

I like this approach, but I think remarks would have to be nested, like so.

<metadata>
  <prop ns="https://sparekh.github.io/ns/oscal" name="content-approved-by" value="#01226254-84f1-4045-8195-aceda74ca962">
    <remarks>2021-02-01</remarks>
  </prop> 
  <prop ns="https://sparekh.github.io/ns/oscal" name="content-approved-by" value="#93226254-74f1-1345-2222-aceda74ca962">
    <remarks>2021-02-04</remarks>
  </prop> 
</metadata>

Making it remarks to me seems odd given the construct, which is why I thought it would make more sense (for now, until prop can have complex types beyond just a string @value, that will come in time with OSCAL in my humble opinion), I would imagine this would be slightly more clear.

<metadata>
  <prop ns="https://sparekh.github.io/ns/oscal" name="content-approval" class="approver-id" value="#01226254-84f1-4045-8195-aceda74ca962"/>
  <prop ns="https://sparekh.github.io/ns/oscal" name="content-approval" class="approver-date" value="2021-01-02"/>
  <prop ns="https://sparekh.github.io/ns/oscal" name="content-approval" class="approver-id" value="#93226254-74f1-1345-2222-aceda74ca962"/>
  <prop ns="https://sparekh.github.io/ns/oscal" name="content-approval" class="approver-date" value="2021-01-04"/>
</metadata>

I only recommend this because remarks is for describing with a sentence non-standard or exceptional behavior. We could do what you are doing there, but equally problematic. I'd like to know what NIST OSCAL devs think about this approach, is it ok we discuss it with them?

[SParekh]

@ohsh6o Thanks for detailed feeback.

<metadata>
  <prop ns="https://sparekh.github.io/ns/oscal" name="content-approval" class="approver-id" value="#01226254-84f1-4045-8195-aceda74ca962"/>
  <prop ns="https://sparekh.github.io/ns/oscal" name="content-approval" class="approver-date" value="2021-01-02"/>
  <prop ns="https://sparekh.github.io/ns/oscal" name="content-approval" class="approver-id" value="#93226254-74f1-1345-2222-aceda74ca962"/>
  <prop ns="https://sparekh.github.io/ns/oscal" name="content-approval" class="approver-date" value="2021-01-04"/>
</metadata>

The issue with above approach is that there is no way to associate approver-date = "2021-01-02" to approver-id="#01226254-84f1-4045-8195-aceda74ca962", you just have to assume based on order.

[SParekh]

@ohsh6o - Any guidance on above response ?

[ohsh6o]

@ohsh6o - Any guidance on above response ?

Sorry for the delayed reply, @SParekh. I intended to bring this up at least week's OSCAL model meeting but there were a serious of presentations that ran over and I did not get to bring it up.

Why bring it up? I agree my approach misses that key organizational piece you need on mapping who signed to a date and I feel there must be a "better way" than what both of us proposed in this thread. Can I discuss briefly with NIST OSCAL developers and get back too you?

[SParekh]

@ohsh6o - Thanks for response. Yes, definitely agree there can be better approach and right way to represent this.

Will wait for your feedback.

[david-waltermire]

Why not use responsible-party to do this since it supports links and props?

Something like:

role[id="content-approver"]
party[uuid="uuid-person-approver"]
responsible-party[role-id="content-approver"]
- party-uuid[uuid-person-approver]
- prop[name="approval-date",value="the date"]

The problem here is supporting more than one party. You can do this with multiple distict roles (i.e., reviewer, approver, etc).

[ohsh6o]

The problem here is supporting more than one party. You can do this with multiple distict roles (i.e., reviewer, approver, etc).

@david-waltermire-nist, the problem here is that if you look at the above image of the current Word-based templates: logically FedRAMP supports multiple distinct approvers, so that means I could also suggest a role of content-approver-1, content-approver-2, content-approver-N, but then analysis code for tools on the consuming side, like @SParekh is asking about, become kludgey or messy. This code smell sensation is why I was curious what you thought.

[ohsh6o]

@SParekh, I thought more about what @david-waltermire-nist recommended last week, and retract my previous comments. It does not really make sense. There are many other constructs with roles and party mappings where there is a role with overlap and I do not need to have content-approver-1, content-approver-2, content-approver-N.

I recommend we move forward with that approach. List in that comment. Do you need fuller examples or is it clear?

[SParekh]

@ohsh6o / @david-waltermire-nist

Our understanding is that there is 1-1 Relationship between when a Party i.e. a "Content Approver", approved the content.

E.g. there can be 2 parties that are content approvers i.e. assigned "content-approver" role under "responsible-party".
Jane Doe --> Approved on 1/1/2020
John Doe --> Approved on 1/2/2020

If we go with the following construct

role[id="content-approver"]
party[uuid="uuid-john-doe"]
party[uuid="uuid-jane-doe"]
responsible-party[role-id="content-approver"]
- party-uuid[uuid-john-doe]
- party-uuid[uuid-jane-doe]
- prop[name="approval-date",value="the date"]

Which approver does the prop "approval-date" apply to ?

[ohsh6o]

@SParekh, that looks correct, yes.

[SParekh]

@ohsh6o
Not sure I understood - Are we saying that "same" approval date" applies to both the approvals and is that FedRAMP Guidance ?

We had different understanding .. See Below

[ohsh6o]

Discuss this in the NIST OSCAL model meeting today, but this this seems to be a micro-example of the need for the larger macro-goal of better governance in OSCAL models to have a layer of approval/review data outside the models. Linking to usnistgov/OSCAL#640 for reference.

[ohsh6o]

@SParekh we discussed this in the NIST OSCAL model meeting this morning and Dave agrees I was a bit hasty in my immediate response. I had not immediately responded with my view of "how dates would work" but I later realized it was not going to be sufficient. I missed something important. During the meeting, they asked I make an issue to build out an approval metadata block to make this use case explicitly support with better structure in the next release.

I will be linking requested issues shortly and will begin working with NIST on a more explicit approach.

[ohsh6o]

I apologize for the delays in follow-up @SParekh. I have drafted a PR to better address this gap in functionality with the NIST OSCAL devs (usnistgov/OSCAL#1038) and will update you once I hear more.

[SParekh]

@ohsh6o Thank you so much for following up and helping resolve this missing data representation.

[volpet2014]

Consulted with NIST on this issue. NIST will support this in upcoming release. See usnistgov/oscal-content#139

Once the NIST Team reviews and merges this for inclusion in a tagged release, FR PMO can consider updating our code and content to that release