[X] the Guide to OSCAL-based FedRAMP System Security Plans (SSP)
[ ] the Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP)
[ ] the Guide to OSCAL-based FedRAMP Security Assessment Results (SAR)
[ ] the Guide to OSCAL-based FedRAMP Plan of Action and Milestones (POA&M)
[X] 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)
User Story
As a fedRAMP CSP, I want the ability to identify ports and protocols that are blacklisted within my accreditation boundary, instead of only identifying the protocols and ports that are white listed.
Goals
For a CSP with a large number of accepted ports, being able to identify only the restricted ports and services is a much clearer way to describe the boundary.
Goal 1:
Create a use case in OSCAL SSP that supports component services that are restricted, blacklist, whitelist, and a hybrid solution without introducing new props for added complexity.
Goal 2:
Ensure the validation metaschema allows for either a white list, black list, or combination of the two
Dependencies
This is outside of the current OSCAL usecase defined by FedRAMP and requires some thought on how to process.
Could possibly implement a solution using the operational status of the component, but using decomissioned may be the best option. This is currently not an accepted value for FedRAMP.
This is a ...
fix - something needs to be different
This relates to ...
User Story
As a fedRAMP CSP, I want the ability to identify ports and protocols that are blacklisted within my accreditation boundary, instead of only identifying the protocols and ports that are white listed.
Goals
For a CSP with a large number of accepted ports, being able to identify only the restricted ports and services is a much clearer way to describe the boundary.
Goal 1:
Create a use case in OSCAL SSP that supports component services that are restricted, blacklist, whitelist, and a hybrid solution without introducing new props for added complexity.
Goal 2:
Ensure the validation metaschema allows for either a white list, black list, or combination of the two
Dependencies
This is outside of the current OSCAL usecase defined by FedRAMP and requires some thought on how to process.
Could possibly implement a solution using the operational status of the component, but using decomissioned may be the best option. This is currently not an accepted value for FedRAMP.
Can we workshop a solution?
Acceptance Criteria
Other information
No response