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

POAM Item should have a related-finding assembly #1120

Closed
8 tasks
vmangat opened this issue Jan 31, 2022 · 9 comments · Fixed by #1478
Closed
8 tasks

POAM Item should have a related-finding assembly #1120

vmangat opened this issue Jan 31, 2022 · 9 comments · Fixed by #1478
Assignees
Labels
Discussion Needed This issues needs to be reviewed by the OSCAL development team. enhancement Model Engineering An issue to be discussed during the bi-weekly Model Engineering Meeting User Story
Milestone

Comments

@vmangat
Copy link
Contributor

vmangat commented Jan 31, 2022

User Story:

As an OSCAL tool developer, it is a challenge to identify a "target" or the implementation-statement-uuid for a specific poam-item without traversing through the observations of the poam-item and then correlating these observations with the related-observations in the findings

Goals:

This can be implemented by including an assembly in poam-items as follows:

related-findings [0 or 1]: [
        An array of related-findings objects [1 to ∞] {
              finding-uuid [1]: uuid
        }
], 

or

by use of a link with rel='related-finding'.

  • Develop a proposal for implementing this as an assembly and a link
  • Socialize both approaches at an OSCAL model review
  • Implement the consensus approach.

Dependencies:

None. This would be a backward compatible change that could be added in v1.0.2

Acceptance Criteria

  • A link rel has been added to support this in the poam-item.
  • An example has been created to illustrate this.
  • All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
  • A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
  • The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

{The items above are general acceptance criteria for all User Stories. Please describe anything else that must be completed for this issue to be considered resolved.}

@aj-stein-nist aj-stein-nist added Discussion Needed This issues needs to be reviewed by the OSCAL development team. Model Engineering An issue to be discussed during the bi-weekly Model Engineering Meeting labels Feb 3, 2022
@david-waltermire
Copy link
Contributor

I believe this could also be a link:

Something like:

link:
- rel: related-finding
  href: source#finding-uuid

@vmangat
Copy link
Contributor Author

vmangat commented Feb 7, 2022

Stepping back a little bit, lets envision creating a poam-item by including a

{finding which refers to target, and/or observations and/or risks}, OR
{observations and/or risks}

In both cases the related-observations and related-risks will be copied into the "observations" and "risks" assemblies in the POAM document. Likewise the related-findings should be copied into a "findings" assembly in the POAM document.

This continues the theme of keeping the POAM document fairly self sufficient

Using a link to other documents breaks the paradigm of keeping the POAM document fairly self sufficient.

@iMichaela
Copy link
Contributor

This continues the theme of keeping the POAM document fairly self sufficient

Using a link to other documents breaks the paradigm of keeping the POAM document fairly self sufficient.

@vmangat - OSCAL's core traceability concept is based on exactly the opposite approach than the one you try to implement. The information is not re-copied between documents (OSCAL content) because the maintenance/updates of all documents will be a nightmare. Tools can bring the information in front of the user's eyes by extracting it from the OSCAL sources.
Nobody wants to be where we are today and deal with documents that become obsolete before even the system is operational. One piece of information should remain in one place, so when it needs to be updated, the process becomes simple and requires a minimum effort.
@david-waltermire-nist 's guidance is correct. With that said, we are not prescriptive. Anyone can implement it as it suits their needs, but, regrettably, we cannot support requests to change OSCAL if we believe such requests are not aligned with the proper use of OSCAL.

@vmangat
Copy link
Contributor Author

vmangat commented Mar 8, 2022

@iMichaela We are by no means suggesting or supporting re-copying of information, i was making that comment based on the current design of poam-item, it will necessitate this.
The Observations and Risks assembly in the poam-item will require them to be copied in from the SAR. If the intention is not to do so, then they should included in a local-definition wrapper.

We are asking that Observations, Risks and Findings be treated the same and all 3 could be present in the poam-item. Finding is missing from poam-item as defined in v1.0.0

Happy to explain this in more detail if this issues can be scheduled for discussion a dev meeting.

@david-waltermire
Copy link
Contributor

@vmangat We can add a link rel to support this. This will allow the poam-item to point to the finding in the OSCAL assessment results. No copying or duplication needed.

@david-waltermire
Copy link
Contributor

We should also create an example of how to do this.

@GaryGapinski
Copy link

GaryGapinski commented Jul 8, 2022

plan-of-action-and-milestones (as of v1.0.4 schema) is replete with link elements including within poam-item. An example (of likely inter-document links) would be useful.

@Compton-US Compton-US moved this from Todo to In Progress in NIST OSCAL Work Board Aug 5, 2022
@Compton-US Compton-US moved this from In Progress to Todo in NIST OSCAL Work Board Aug 31, 2022
@Compton-US Compton-US moved this from Todo to In Progress in NIST OSCAL Work Board Sep 20, 2022
Compton-US pushed a commit to Compton-US/OSCAL that referenced this issue Sep 20, 2022
Compton-US pushed a commit to Compton-US/OSCAL that referenced this issue Sep 27, 2022
@Compton-US Compton-US moved this from In Progress to Under Review in NIST OSCAL Work Board Sep 29, 2022
@Compton-US
Copy link
Contributor

Submitted PR to address this: #1478

An assembly was added for related-finding.

@vmangat
Copy link
Contributor Author

vmangat commented Sep 30, 2022

Thank you for this change. It helps link poam-item to finding/target and finding/implementation-uuid without the use of additional props that FedRAMP had to introduce.

@aj-stein-nist aj-stein-nist linked a pull request Oct 17, 2022 that will close this issue
david-waltermire pushed a commit that referenced this issue Oct 17, 2022
* Add related finding assembly. #1120
* Add finding assembly to support related-findings, also moved finding to assessment common from assessment result metaschema.
* Accept suggestion to revise description.

Co-authored-by: Alexander Stein <[email protected]>
Repository owner moved this from Under Review to Done in NIST OSCAL Work Board Oct 17, 2022
aj-stein-nist added a commit that referenced this issue Oct 18, 2022
* Add related finding assembly. #1120
* Add finding assembly to support related-findings, also moved finding to assessment common from assessment result metaschema.
* Accept suggestion to revise description.

Co-authored-by: Alexander Stein <[email protected]>
david-waltermire pushed a commit that referenced this issue Oct 31, 2022
* Add related finding assembly. #1120
* Add finding assembly to support related-findings, also moved finding to assessment common from assessment result metaschema.
* Accept suggestion to revise description.

Co-authored-by: Alexander Stein <[email protected]>
aj-stein-nist added a commit to aj-stein-nist/OSCAL-forked that referenced this issue Jan 10, 2023
* Add related finding assembly. usnistgov#1120
* Add finding assembly to support related-findings, also moved finding to assessment common from assessment result metaschema.
* Accept suggestion to revise description.

Co-authored-by: Alexander Stein <[email protected]>
aj-stein-nist added a commit to aj-stein-nist/OSCAL-forked that referenced this issue Feb 6, 2023
* Add related finding assembly. usnistgov#1120
* Add finding assembly to support related-findings, also moved finding to assessment common from assessment result metaschema.
* Accept suggestion to revise description.

Co-authored-by: Alexander Stein <[email protected]>
aj-stein-nist added a commit to aj-stein-nist/OSCAL-forked that referenced this issue Jun 29, 2023
* Add related finding assembly. usnistgov#1120
* Add finding assembly to support related-findings, also moved finding to assessment common from assessment result metaschema.
* Accept suggestion to revise description.

Co-authored-by: Alexander Stein <[email protected]>
aj-stein-nist added a commit to aj-stein-nist/OSCAL-forked that referenced this issue Jul 10, 2023
* Add related finding assembly. usnistgov#1120
* Add finding assembly to support related-findings, also moved finding to assessment common from assessment result metaschema.
* Accept suggestion to revise description.

Co-authored-by: Alexander Stein <[email protected]>
aj-stein-nist added a commit to galtm/OSCAL that referenced this issue Sep 28, 2023
* Add related finding assembly. usnistgov#1120
* Add finding assembly to support related-findings, also moved finding to assessment common from assessment result metaschema.
* Accept suggestion to revise description.

Co-authored-by: Alexander Stein <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discussion Needed This issues needs to be reviewed by the OSCAL development team. enhancement Model Engineering An issue to be discussed during the bi-weekly Model Engineering Meeting User Story
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

6 participants