Address Former Rev 4 User Table Template
Opened this issue · 3 comments
Action Item
This is a ...
- fix - Something needs to be different.
- investigation - Something needs to be investigated further.
This relates to ...
- the FedRAMP SSP OSCAL Example
Describe the problem or enhancement
As an OSCAL-based FedRAMP SSP author or tool developer, I need to understand how the OSCAL SSP //system-implementation/user assembly is to be populated for FedRAMP Rev 5 SSPs.
BACKGROUND
The core OSCAL syntax requires at least one //system-implementation/user assembly in an OSCAL-based SSP. It was designed to augment roles defined by the //metaschema/role assemblies, providing additional data that only made sense for roles in the context of an SSP.
This was construct was designed with the FedRAMP Rev 4 Word Template's user table as the example use case.
The User Table in the FedRAMP Rev 4 SSP Word template was dropped from the Rev 5 template.
Under Rev4, FedRAMP Reviewer guidance was that every role cited in any control's "Responsible Role(s)" field must be included in the Users Table, where each role needed additional documentation, such as internal/external, privileged/non-privileged/no-logical-access, as well as a description of any privileged access.
Under Rev 5, The FedRAMP SSP Word template still requires user roles to be cited for tables 6.1 (Leveraged Authorizations) and 7.1 (External Systems/Services and Interconnections); however, the template requires no additional information, essentially negating the need for a separate //system-implementation/user construct.
Goals:
- Determine if the
//system-implementation/userassembly is needed for OSCAL-based FedRAMP SSPs. - If not needed, determine how best to work around the OSCAL requirement to have at least one
//system-implementation/userentry. - Update example content to reflect decisions
- Update documentation (automate.fedramp.gov) to reflect decisions
Dependencies:
None
Acceptance Criteria
- All FedRAMP Documents Related to OSCAL Adoption (https://github.com/GSA/fedramp-automation) affected by the changes in this issue have been updated.
- A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
Other Comments
None
So the cardinality of /ssp/system-implementation/user is 1 to unbounded in the core v1.1.2 models, so is this something we can effectively work around without kludgey behavior?
So the cardinality of /ssp/system-implementation/user is 1 to unbounded in the core v1.1.2 models, so is this something we can effectively work around without kludgey behavior?
Yes. We have a few options. We can still use the user table to capture internal and external users, or we can just have a single entry user table that has no data. The following is the valid minimum to satisfy the requirement:
<user uuid="11111111-2222-4000-8000-008000000001" />
Unless a compelling reason emerges or leadership says otherwise, I am simply including only the above content in the example SSP for the user assembly, along with a remark that indicates it is under review for continued applicability.