System Interconnection Table Completed

[ohsh6o]

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

• Confirmation with FR policy staff the relevant fields are correct.

Acceptance Critera

• [x] A check for: given an interconnection is defined in the SSP, there must be a ISA (interconnection security agreeement).
• [x] Given an interconnection (component[@type='interconnection']):
  • [x] Check: there is a properly defined remote-system-name<title> and <description>.
  • [x] Check: a valid contact for the interconnection security agreement for the FedRAMPed system (isa-poc-local)
  • [x] Check: a valid contact for the interconnection security agreement for the other system remotely interconnected to (isa-poc-remote)
  • [x] Check: a valid signatory for the interconnection agreement for the FedRAMPed system (ica-authorizing-official-local)
  • [x] Check: a valid signatory for the interconnection agreement for the system remotely interconnected to (ica-authorizing-official-local)
  • [x] Check: a link to the ISA in the back-matter
  • [x] Check: oneinterconnection-direction of information flow is set
  • [x] Check: that one mandatory FedRAMP value of connection-security is defined
  • [x] Check: all IP addresses of the remote system and FedRAMP system interace IP addresses are defined

Story Tasks

• [x] Create Schematron assertions
• [x] Create unit tests
• [x] Update related business rules

Definition of Done

• [x] Acceptance criteria met - Each user story should meet the acceptance criteria in the description
• [x] Unit test coverage of our code > 90% (from QASP) this may be fuzzy and hard to prove
• [x] Code quality checks passed (from QASP) - [ ] 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
• [x] Code reviewed - Code reviewed by at least one other team members (or developed by a pair)
• [x] Source code merged - Code that’s demoed must be in source control and merged
• [x] Code must successfully build and deploy into staging environment (from QASP): this may evolve from xslt sh pipline into something more - [ ] 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)
• [x] Code refactored for clarity - Code must be clean, self-documenting
• [x] No local design debt
• [x] Load/performance tests passed - test data needed - saxon instrumentation
• [x] Documentation generated - update readme or contributing markdown as necessary. - [ ] Architectural Decision Record completed as necessary for significant design choices

[GaryGapinski]

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.

[ohsh6o]

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.

[GaryGapinski]

Some further observations (this appears fractally flawed):

• The sample template exploits <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
  • has incorrect binding.
  • uses the obsolete term "ssl" (ditto the guide). Should be TLS and probably DTLS.
  • uses the term "certificate" which is devoid of what sort of (X.509?) certificate is used and how it is employed.
• SP 800-63B seems like it should be pertinent here (for at least auth).
• 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.
• The "information" <prop> should be disappeared in favor of the component> <description>.

I'll likely find further problems while generating assertions.

[ohsh6o]

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!

[GaryGapinski]

• The guide lacks a <component> <status> element (fedramp_values.xml constraint component-operational-status).
• The guide and template lack a <component> <protocol> element (fedramp_values.xmlhas no constraint).