Description
User Story
There is currently a type for interconnection, defined as "A connection to something outside this system." There is also a service, which is defined as "A service that may provide APIs."
The FedRAMP OSCAL Rev 5 has added new requirement for a "validation" component to identify the approved encryption module, with additional locally defined props that denote the if it is protecting data in transit, and/or data at rest.
Would like to understand how the service component can be leveraged, and or if we need a new internal connection component, to identify the following use cases:
- Server is communicating with the internal database.
Is this considered a service? Or do we tie the cryptographic module to the software components on either side of the communication? What is the recommended methodology for identifying how information moves around within an accreditation boundary?
Relates to #1913
Goals
Determine the appropriate way to identify and document internal movement of data within the boundary, either locally on a single machine or to different machines and how to further link the cryptographic module components. IE should cryptography be referenced at the software level, or at the service level?
Dependencies
No response
Acceptance Criteria
- All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
- A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
- The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.
(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)
Revisions
No response
Metadata
Metadata
Type
Projects
Status