Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allowed Values for nature-of-agreement for external systems #907

Open
8 of 22 tasks
Tracked by #808
brian-ruf opened this issue Nov 15, 2024 · 4 comments · Fixed by #929
Open
8 of 22 tasks
Tracked by #808

Allowed Values for nature-of-agreement for external systems #907

brian-ruf opened this issue Nov 15, 2024 · 4 comments · Fixed by #929

Comments

@brian-ruf
Copy link
Collaborator

brian-ruf commented Nov 15, 2024

Constraint Task

As a maintainer of a digital authorization package, in order to know I am using the appropriate type of agreement between the documented system and external system(s) documented in my SSP so that I avoid a pass-back, I would like a check in my SSP to confirm the appropriate types of agreement between the CSP maintaining a CSO documented in a SSP and the external system.

Intended Outcome

Syntax

  • Define an allowed-values constraint that allows the enumerated values below or other possible options (allow-other="yes"):
    • contract: A contract between the CSP and the organization that owns the external system.
    • mou: A memorandum of understanding between the CSP and the organization that owns the external system.
    • isa: An interconnection security agreement between the CSP and the organization that owns the external system.
    • sla: A service-level agreement between the CSP and the organization that owns the external system.
    • eula: An end user license agreement between the CSP and the organization that owns the external system.
    • license: An application license agreement between the CSP and the organization that owns the external system.
    • other: An non-typical agreement between the CSP and the organization that owns the external system. Explain in remarks.

Syntax Type

This is a FedRAMP constraint in the FedRAMP-specific namespace.

Allowed Values

FedRAMP allowed values must be defined or verified.

Metapath(s) to Content

This is the corrected metapath

target="//component[ (@type='service'  and not(./prop[@name='leveraged-authorization-uuid']) and ./prop[@name='implementation-point' and @value='external']) or (@type='interconnection') or (@type='service' and ./prop[@name='implementation-point' and @value='internal'] and ./prop[@name='direction']) or (@type='software' and ./prop[@name='asset-type' and @value='cli'] and ./prop[@name='direction']) ]"

This was the originally stated metapath, but is incorrect.

//component[@type='system' and not(./prop[@name='leveraged-authorization-uuid']) and ./prop[@name='implementation-point' and @value='external']]/prop[@name='nature-of-agreement' and @ns='http://fedramp.gov/ns/oscal' ]

Purpose of the OSCAL Content

Check for agreement types as they are material to the review of a CSO SSP by FedRAMP reviewers.

Dependencies

No response

Acceptance Criteria

  • All OSCAL adoption content affected by the change in this issue have been updated in accordance with the Documentation Standards.
    • Explanation is present and accurate
    • sample content is present and accurate
    • Metapath is present, accurate, and does not throw a syntax exception using oscal-cli metaschema metapath eval -e "expression".
  • All constraints associated with the review task have been created
  • The appropriate example OSCAL file is updated with content that demonstrates the FedRAMP-compliant OSCAL presentation.
  • The constraint conforms to the FedRAMP Constraint Style Guide.
    • All automated and manual review items that identify non-conformance are addressed; or technical leads (David Waltermire; AJ Stein) have approved the PR and “override” the style guide requirement.
  • Known good test content is created for unit testing.
  • Known bad test content is created for unit testing.
  • Unit testing is configured to run both known good and known bad test content examples.
  • Passing and failing unit tests, and corresponding test vectors in the form of known valid and invalid OSCAL test files, are created or updated for each constraint.
  • A Pull Request (PR) is submitted that fully addresses the goals section of the User Story in the issue.
  • This issue is referenced in the PR.

Other information

No response

@brian-ruf
Copy link
Collaborator Author

This issue is very similar to #889 and it would be efficient for the same person to do both at the same time.

@brian-ruf
Copy link
Collaborator Author

brian-ruf commented Nov 20, 2024

Per discussion with @DimitriZhurkin and @brian-ruf the allow-others should be set to no instead of yes.

@brian-ruf
Copy link
Collaborator Author

Documentation for this issue will be addressed as part of GSA/automate.fedramp.gov#126

DimitriZhurkin added a commit to DimitriZhurkin/fedramp-automation that referenced this issue Nov 25, 2024
DimitriZhurkin added a commit that referenced this issue Nov 27, 2024
* Add external-system-nature-of-agreement

* Update help-url

* Modified Metapath as per #907
@Rene2mt Rene2mt moved this from 👀 In review to 🚢 Ready to Ship in FedRAMP Automation Nov 27, 2024
@brian-ruf brian-ruf changed the title Allowed Values for nature-of-agreement for external systems. Allowed Values for nature-of-agreement for external systems Dec 2, 2024
@brian-ruf
Copy link
Collaborator Author

@DimitriZhurkin we need to further relax the location of the "nature-of-agreement" prop/extension.

For this allowed value constraint, simply use:

  • metapath target="//component/prop[@name='nature-of-agreement' and @ns='http://fedramp.gov/ns/oscal']"
  • target="./@value"

We will rely on other (possibly changing) constraints to determine whether this property is appearing in the correct components.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 🚢 Ready to Ship
Development

Successfully merging a pull request may close this issue.

2 participants