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

[EPIC] Adjudication or Governance Model #640

Open
10 tasks
brian-ruf opened this issue Mar 25, 2020 · 1 comment
Open
10 tasks

[EPIC] Adjudication or Governance Model #640

brian-ruf opened this issue Mar 25, 2020 · 1 comment
Labels
Aged A label for issues older than 2023-01-01 enhancement Epic A collection of issues to be worked on over a series of sprints Research User Story

Comments

@brian-ruf
Copy link
Contributor

User Story:

As an OSCAL syntax developer, I need the ability to capture and automate certain aspects of cybersecurity authorization governance/adjudication activities.

Justification is as follows:

  • Adjudication is a process. Authorization is a decision resulting from that process.
  • Authorization decisions, ongoing status, and changes to this status need to be published. Especially in the case of an authorization suspension or revocation. (Example: Automated notification of change to leveraging system owners.)
  • The following activities are typically adjudicated by AOs who must render a decision:
    • initial authorization (adjudication of initial assessment package)
    • periodic re-authorization (adjudication of periodic re-assessments)
    • continuous monitoring (adjudication of vuln, threat, patch mgt reporting, including things like POA&M deviations)
    • significant changes (adjudication of plans, implementation, and validation of change)
  • Cloud systems (and possibly legacy general support systems), could have multiple authorizing officials. Also, when applying OSCAL to multiple frameworks, the same system could have different adjudicators for each framework. This should all be captured.
  • Authorization package reviews, often include back and forth comments and associated commend disposition. All comments must be tracked and closed. Some comments essentially constitute a "conditional authorization" (ie. "will authorize now, provided you have POA&M Item JSON schema #10 resolved by ___ date.")
  • Even an adjudication process supported by automation can be langthly. Reporting of adjudication process is currently a manually tally of structured information. This information could be summarized to dashboards if available in OSCAL.
  • In terms of responsibility for content (authorship):
    • System Owners are the only ones who should be creating/changing content in the SSP and POA&M
    • Assessors are the only ones who should be creating/changing content in the SAP and SAR
    • Authorizing Officials are the only ones who should be creating/changing/publishing authorization decisions, including suspensions and revocations; as well as decisions surrounding POA&M deviations (agreement that a finding is a false positive, operationally required or appropriately risk adjusted) and significant change adjudication.

I recommend the following tasks:

  • Clarify scope of work and refine the tasks below as appropriate.
  • Analyze authorization activities to ensure a complete understanding common adjudication and governance activities related to authorization of systems.
  • Create an information inventory that supports adjudication/governance activities.
  • Create diagrams and syntax mock-ups of model(s).
  • Develop and refine syntax using metaschema.
  • Develop and refine examples to validate and demonstrate the models.

Goals:

  • Identify the appropriate new model(s) to support this syntax, as well as the appropriate (existing or new) OSCAL layer to incorporate these models.
  • Provide syntax to capture typical adjudication, decisions, and other common governance details.
  • Provide appropriate extension points, allowing individual frameworks to tailor the model to their needs.

Dependencies:

None.

Acceptance Criteria

  • 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.
  • Model(s) developed, fully documented, and published.
@aj-stein-nist
Copy link
Contributor

This work should go back to user research and discovery, so this will be moved back to DEFINE Research Needed. After that, if it is returned to development as-is, we should consider refinement being needed as this epic, as previously used it, is too large re upcoming #1688 reorganization and needs to be broken down into manageable pieces.

@aj-stein-nist aj-stein-nist moved this from Todo to DEFINE Research Needed in NIST OSCAL Work Board Sep 27, 2023
@Compton-US Compton-US added the Aged A label for issues older than 2023-01-01 label Nov 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Aged A label for issues older than 2023-01-01 enhancement Epic A collection of issues to be worked on over a series of sprints Research User Story
Projects
Status: DEFINE Research Needed
Development

No branches or pull requests

4 participants