Open vmangat opened 2 weeks ago
Thank you for your feedback. It does appear the documentation in the "Importing the FedRAMP Baseline" section should be more specific about referencing the authoritative FedRAMP baselines.
Referencing a local copy of a FedRAMP baseline (e.g., <import-profile href="#[uuid-value]" />
) is completely acceptable and may be the only way for air gapped environments. It does not guarantee that the provided profile is the authoritative one (e.g., modified locally without changing the UUID), so there are some checks that may be required for assurance (e.g. verifying file hash).
Specifying a URL for import (e.g., <import-profile href="path/to/profile.xml" />
) does introduce the risks mentioned (e.g., changes to profiles), but that could be mitigated with GitHub "permalink" references to specific versions of the FedRAMP profiles. This would only work in environments that can access the FedRAMP Automation repository.
Thanks again for bringing this to our attention. We will need to provide additional / clearer guidance on importing the official FedRAMP profiles and how to verify that.
This is a ...
request - need something additional provided
This relates to ...
What is your feedback?
The import-profile field should be limited to a uuid of an authoritative FedRAMP baseline. This will ensure that a unique FedRAMP baseline is referenced and the SSP can be validated against a specific baseline. Authoritative baselines can be downloaded and available in an air-gapped environment and a GRC tool can resolve the SSP against the baselines.
Allowing a URL creates the following issues for a GRC tool importing or validating the SSP:
Where, exactly?
https://automate.fedramp.gov/documentation/ssp/3-working-with-oscal-files/
Other information
No response