Closed ohsh6o closed 3 years ago
Neither OSCAL nor FedRAMP_extensions.xml
define a <remote-system-name>
element. Will have to be a <prop>
.
Neither OSCAL nor FedRAMP_extensions.xml
define a <responsible-party>
for a <component>
. OSCAL has <responsible-role>
which associates a <party>
indirectly via a <responsible-party>
.
There are the above errors in the Guide to OSCAL-based FedRAMP System Security Plans.§4.20 and §4.21. There is also an orphan </interconnection>
which should be removed. Additionally, the <!-- repeat citation assembly for each ICA -->
implies an ICA per connection. Instead, a ICA for a several connections is far more likely.
Furthermore, FART requires that each data flow (of which an interconnection is a conduit) identifies the type of encryption used and its CMVP module certificate. This implies the interconnection should cite the (same-document) validation component(s).
The FedRAMP OSCAL interconnection component documentation neglects the OSCAL-defined <protocol>
element though the sample OSCAL template exploits it.
There are other oddities worth examining in detail, both in the predecessor SSP template as well as the FedRAMP OSCAL implementation.
Neither OSCAL nor
FedRAMP_extensions.xml
define a<remote-system-name>
element. Will have to be a<prop>
.
I do not know how this one slipped my attention. I guess I will have to add another bug or include in GSA#166.
Neither OSCAL nor
FedRAMP_extensions.xml
define a<responsible-party>
for a<component>
. OSCAL has<responsible-role>
which associates a<party>
indirectly via a<responsible-party>
.There are the above errors in the Guide to OSCAL-based FedRAMP System Security Plans.§4.20 and §4.21. There is also an orphan
</interconnection>
which should be removed. Additionally, the<!-- repeat citation assembly for each ICA -->
implies an ICA per connection. Instead, a ICA for a several connections is far more likely.
Yesterday afternoon I added this to a bug GSA#166.
Furthermore, FART requires that each data flow (of which an interconnection is a conduit) identifies the type of encryption used and its CMVP module certificate. This implies the interconnection should cite the (same-document) validation component(s).
OK, I can add this to the AC. I agree to that.
The FedRAMP OSCAL interconnection component documentation neglects the OSCAL-defined
<protocol>
element though the sample OSCAL template exploits it.
You mean as how they apply to port
ranges?
There are other oddities worth examining in detail, both in the predecessor SSP template as well as the FedRAMP OSCAL implementation.
OK, we should discuss those then.
Some further observations (this appears fractally flawed):
<title>
for system name, which seems appropriate. The guide should be changed.fedramp_values.xml
lacks a constraint for the responsible-roles.fedramp_values.xml
interconnection-security
fedramp_values.xml
interconnection-direction
.<prop>
should be disappeared in favor of the component>
<description>
.I'll likely find further problems while generating assertions.
Some further observations (this appears fractally flawed):
* The sample template exploits `<title>` for system name, which seems appropriate. The guide should be changed.
Agreed, will do.
* `fedramp_values.xml` lacks a constraint for the responsible-roles.
We can add that.
* `fedramp_values.xml` `interconnection-security` * has incorrect binding.
Ok, will fix.
* uses the obsolete term "ssl" (ditto the guide). Should be TLS and probably DTLS.
Makes sense, can modify.
* uses the term "certificate" which is devoid of what sort of (X.509?) certificate is used and how it is employed.
Would you prefer mutual (mtls
) over certificate authentication? I guess that is equally vague, but maybe explains the mechanism more than what kind of certificate (if we agree mutually-authenticating TLS is certficate-based authentication).
* SP 800-63B seems like it should be pertinent here (for at least auth).
I assumed network-layer interconnect security would likely not authenticate specific users, but system-to-system authentication. Am I mistaken? I thought AAL/FAL/IAL determinations are very much focused on identifying user principals when they are not system-to-system.
* If an interconnection targets a FedRAMP authorized package, that should be accommodated here or indirectly elsewhere in the SSP and associated here. * The "direction" prop is at odds with the `fedramp_values.xml` `interconnection-direction`.
Will need to fix.
* The "information" `<prop>` should be disappeared in favor of the `component>` `<description>`.
I would say we keep it for now per our conversation about using that to describe the kind of info, separate from description.
I'll likely find further problems while generating assertions.
Sounds good!
<component>
<status>
element (fedramp_values.xml
constraint component-operational-status
).<component>
<protocol>
element (fedramp_values.xml
has no constraint).
Extended Description
As a FedRAMP reviewer, in order to understand the relationship for this FedRAMP system to other systems and services, I want to validate the proper completion of a system interconnects table.
Preconditions
Acceptance Critera
component[@type='interconnection']
):remote-system-name
<title>
and<description>
.isa-poc-local
)isa-poc-remote
)ica-authorizing-official-local
)ica-authorizing-official-local
)back-matter
interconnection-direction
of information flow is setconnection-security
is definedStory Tasks
Definition of Done
- [ ] Accessibility: (from QASP) as we create guidance or documentation and reports (semantic tagging including aria tags): demonstrate with 0 errors reported for WCAG 2.1 AA standards using an automated scanner and 0 errors reported in manual testing- [ ] Security reviewed and reported - Conduct vulnerability and compliance scanning. threat modeling?- [ ] Code submitted must be free of medium- and high-level static and dynamic security vulnerabilities (from QASP)- [ ] Usability tests passed - Each user story should be easy to use by target users (development community? FedRAMP FART team)- [ ] Usability testing and other user research methods must be conducted at regular intervals throughout the development process (not just at the beginning or end). (from QASP)- [ ] Architectural Decision Record completed as necessary for significant design choices