Describe the bug

The SSP example contains incorrect references to control statements, specifically missing an underscore in au-1smt* instead of au-1_smt:

• https://github.com/usnistgov/oscal-content/blob/master/src/examples/ssp/json/ssp-example.json#L268
• https://github.com/usnistgov/oscal-content/blob/master/src/examples/ssp/json/ssp-example.json#L271
• https://github.com/usnistgov/oscal-content/blob/master/src/examples/ssp/json/ssp-example.json#L304
• https://github.com/usnistgov/oscal-content/blob/master/src/examples/ssp/json/ssp-example.json#L313

Who is the bug affecting?

Developers leveraging the example content

What is affected by this bug?

The example content

When does this occur?

Always

How do we replicate the issue?

Attempt to reconcile the example SSP control implementations against the 800-53 rev 4 controls.

Expected behavior (i.e. solution)

The control statement IDs of the SSP control implementation should match the 800-53 rev 4 control statement IDs.

Other Comments

User Story Candidate: As a compliance auditor, I can see all control catalog entries that correspond to profiles for at least four other frameworks (possible selections include FedRAMP, HIPAA, NIST CSF, and PCI DSS).
Required Resources:

• Need a subset (or the entirety) of FedRAMP, HIPAA, NIST CSF, and PCI DSS
  Goals:

1. Refine the draft profile model from User Story 3.
2. Develop one instance document for each of the four frameworks: FedRAMP, HIPAA Security Rule, NIST CSF, and PCI DSS.
3. Refine the Schematron from User Story 3 to enforce profile constraints and validate the profiles against the referenced control catalogs and controls.
   Acceptance Criteria:
4. Validate that the OSCAL instance documents have been created as defined in Goal 2 and are valid according to the Schematron required by Goal 3.
5. Validate that the OSCAL profile model at least partially represents the FedRAMP, HIPAA Security Rule, NIST CSF, and PCI DSS baselines.

Describe the bug

{The FedRAMP profiles' 'parpared-by' role is misspelled. Should be 'prepared-by'}

Who is the bug affecting?

What is affected by this bug?

{Describe the impact the bug is having.}

When does this occur?

{Describe the conditions under which the bug is occurring.}

How do we replicate the issue?

{What are the steps to reproduce the behavior?

1. grep -i parpared-by -r src

If applicable, add screenshots to help explain your problem.}

Expected behavior (i.e. solution)

{A clear and concise description of what you expected to happen.}

Other Comments

{Add any other context about the problem here.}

The Readme.md file in the SP 800-53 directory needs a review and typos corrected.

The file currently reads:

NIST maintained OSCAL content for NIST Special Publication 800-53

NIST is maintaining OSCAL content for multiple revisions of the NIST Special Publication (SP) 800-53. The XML, JSON, and YAML versions of SP800-53 given here are derived from the NIST publications. These OSCAL files are intended to faithfully to represent the published documents in machinable readable form.

OSCAL XML-, JSON-, and YAML-based content is provided for the following revisions:

• NIST SP 800-53 Revision 4 OSCAL catalog and baseline profiles content.

• NIST SP 800-53 Revision 5 Final OSCAL catalog and SP 800-53B (draft) baseline content.

  Note: In the SP 800-53 Revision 5, the control catalog and control baselines are separated. The control baselines are published as SP 800-53B (draft).

  Please refer to the publication announcement for more information.

The OSCAL XML, JSON, and YAML variants are all equivalent in their information content. These variants are provided to support tooling on different format-specific implementation stacks.

At a minimum, the following corrections are necessary:

NIST maintains OSCAL content for NIST Special Publication 800-53

NIST is maintaining OSCAL content for multiple revisions of the NIST Special Publication (SP) 800-53. The XML, JSON, and YAML versions of SP800-53 given here are derived from the NIST publications. These OSCAL files are intended to faithfully represent the published documents in machine-readable formats.

OSCAL XML-, JSON-, and YAML-based content is provided for the following revisions:

• NIST SP 800-53 Revision 4 controls catalog and baselines are provided in OSCAL in rev4, as:
  • an OSCAL controls catalog file that captures the SP 800-53 rev 4 and SP 800-53A rev4, combined;
  • an OSCAL profile file for each of the SP 800-53 rev 4 baselines.
• NIST SP 800-53 Revision 5 Final document and SP 800-53B (draft) baselines are provided in OSCAL in rev5, as:
  • an OSCAL controls catalog file that captures the SP 800-53 rev 5, final;
  • an OSCAL controls catalog file that captures the SP 800-53 rev, final public draft (FPD);
  • an OSCAL profile file for each of the SP 800-53B rev 5 baselines, final public draft (FPD).

Note: In the SP 800-53 Revision 5, the control catalog and control baselines are published in separate documents. The control baselines are published as SP 800-53B (draft).

Please refer to the publication announcement for more information.

The OSCAL XML, JSON, and YAML variants are all equivalent in their information content. These variants are provided to support tooling on different format-specific implementation stacks.

User Story:

As an OSCAL catalog maintainer, I can refer to an optional, but recommended format for control/subcontrol identifiers. Without any sort of standard format, it becomes difficult for consumers of catalog data to parse the IDs of multiple catalogs. While the declarations model can help with this somewhat, having a standard format that can be verified and checked for upon consumption of catalogs can help ease the burden of maintaining multiple control/subcontrol ID parsing mechanisms.

Related to usnistgov/OSCAL#221, usnistgov/OSCAL#39, usnistgov/OSCAL#218, usnistgov/OSCAL#248, usnistgov/OSCAL#254

Goals:

Catalog maintainers have clear and concise guidance for putting controls/subcontrol IDs into a standard format. This would be optional, but recommended guidance and would make it easier for consumers of catalogs to parse control/subcontrol IDs.

Dependencies:

None.

Acceptance Criteria

An optional, but recommended format for control/subcontrol IDs is developed and documented.

User Story:

As an OSCAL tool/application developer, I would like to have handy example instances of the various schemas.

Goals:

It is sometimes difficult to imagine from the schema and the documentation of the schema alone what a concrete instance might look like. A nonsensical but full example for each of the required and optional fields would be helpful. The values should be valid, but need not been meaningful (e.g., the value for 'title' could be 'title' or 'title goes here').

Dependencies:

N/A

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.

User Story:

To chase down, potential transcription quality issues in the Rev 5 conversion:

• At path /catalog/group[1]/control[11]/control[1]/part[1]/p[1], bold text? (Anywhere else? Use of bold and italics generally?)
• Paragraphs beginning with numerals i.e. matching ^\d

Goals:

Determine whether the data would not be even better if these were faithful representations of documentary intent.

Dependencies:

None, but can be folded into FISMA workflow (as errata versions are released etc.)

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• 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.}

User Story:

As an OSCAL modeler and content author, I need the OSCAL syntax to support various ways in which I may work with content from NIST SP 800-53A, and incorporate it into assessment activities.

Goals:

For 800-53A content:

• Ensure content is granular enough, and addressable (via IDs) at an appropriate level of granularity.
• Ensure existing and added ID assignments are logical and predictable to the degree practical.
• Provide the ability to map specific assessment activities (EXAMINE, INTERVIEW, TEST) to individual assessment objectives, instead of just assigned to the control as a whole.

Dependencies:

None; however, this impacts the SAP and SAR Modeling (Issues usnistgov/OSCAL#589, usnistgov/OSCAL#617, and usnistgov/OSCAL#621).

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.

• If necessary, catalog and profile syntax has been updated.

• All 800-53A assigned IDs are logical and predictable

• 800-53A content is modeled at the appropriate level of detail, with addressability (IDs) at an appropriate level of detail.

In relation to CA-7 CONTINUOUS MONITORING

The PDF list of related controls list SC-38 twice:
CM-11, IA-5, IR-5, MA-2, MA-3, MA-4, PE-3, PE-6, PE-14, PE-16, PE-20, PL-2, PM-4, PM-6, PM-9, PM-10, PM-12, PM-14, PM-23, PM-28, PM-31, PS-7, PT-8, RA-3, RA-5, RA-7, SA-8, SA-9, SA-11, SC-5, SC-7, SC-18, SC-38, SC-43, SC-38, SI-3, SI-4, SI-12, SR-6.

This error has been faithfully reproduced in the OSCAL format:

         <link rel="related" href="#sc-7">SC-7</link>
         <link rel="related" href="#sc-18">SC-18</link>
         **<link rel="related" href="#sc-38">SC-38</link>**
         <link rel="related" href="#sc-43">SC-43</link>
         **<link rel="related" href="#sc-38">SC-38</link>**
         <link rel="related" href="#si-3">SI-3</link>
         <link rel="related" href="#si-4">SI-4</link>

Looking for an implementer that is interested in taking a stab at creating profiles for the DoD Cloud Computing Security Requirements Guide (SRG) FedRAMP+/Impact Level controls? -> https://iasecontent.disa.mil/cloud/SRG/index.html#_Tbl2. Can easily extract from the HTML table. You'll end up with the following profiles:

• DoD SRG Impact Level (IL) 4
• DoD SRG Impact Level (IL) 5
• DoD SRG Impact Level (IL) 6
• FedRAMP+ Moderate (which is a subset of IL4-6 controls per the table in addition to FedRAMP Moderate controls)
• FedRAMP+ High (which is a subset of the IL5-6 controls per the table in addition to FedRAMP High controls)

Describe the bug

In at least one place - AC-3 - references are duplicated, appearing both with the control and with its last enhancement, AC-3(15) in this case. This probably happens consistently.

Compare lines starting at 540 and 919. Control enhancements in the PDF have no references. Reference copy is here:

https://github.com/usnistgov/oscal-content/blob/master/nist.gov/SP800-53/rev5/xml/NIST_SP-800-53_rev5_catalog.xml

Also perhaps validate against references appearing inside control/control.

Describe the bug

https://github.com/usnistgov/oscal-content/blob/master/fedramp.gov/json/FedRAMP_HIGH-baseline-resolved-profile_catalog.json

Missing "Guidance: If performed as part of a Configuration Baseline check, then the % of items. requiring setting that are checked and that pass (or fail) check can be provided."

Who is the bug affecting?

Everyone relying on this file

What is affected by this bug?

I can't rely on the data for generating the correct OSCAL Template
{Describe the impact the bug is having.}

When does this occur?

n/a
{Describe the conditions under which the bug is occurring.}

How do we replicate the issue?

Search "ac-8_fr_gdn.1"

If applicable, add screenshots to help explain your problem.}

Expected behavior (i.e. solution)

Should be ac-8_fr_gdn.1 "Guidance: If performed as part of a Configuration Baseline check, then the % of items. requiring setting that are checked and that pass (or fail) check can be provided."

Other Comments

User Story:

As an OSCAL implementer, I would benefit from examples demonstrating both component and SSP content.

NOTE: Due to the sensitivity of SSP content, samples must be fictitious.

Goals:

• Provide component examples, that cover several use cases, including a single vendor product, a single policy or process, and a capability comprised of a grouping of products, policies, and processes.
• Provide SSP examples that cover several use cases, including "flat-file" SSP (classic word-based document conversion), and a component-based SSP.

Dependencies:

Issue usnistgov/OSCAL#246

Acceptance Criteria

• At least one component example of an Individual product or service
• At least one component example of a policy or procedure
• At least one component example of a capability, consisting of one or more products, one or more policies, and one or more procedures.
• At least one flat-file SSP example
• At least one component-based SSP example

Resolved profile NIST_SP-800-53_rev5_PRIVACY-baseline-resolved-profile_catalog contains 14 instead of 16 groups

NIST_SP-800-53_rev5_PRIVACY-baseline_profile.json references controls from PE & SC groups, however resolved profile has respective groups missing NIST_SP-800-53_rev5_PRIVACY-baseline-resolved-profile_catalog.json

Who is the bug affecting?

Anyone referencing the "oscal-content" repo as source for NIST based baselines

Expected behavior (i.e. solution)

PE & SC group to be part of resolved baseline.

Describe the bug

The NIST 800-53 JSON profiles contain back-matter links to XML catalogs rather than the JSON representation, even though the media-type indicates json.

Who is the bug affecting?

Developers attempting to resolve catalogs from JSON profiles

What is affected by this bug?

The ability to parse the proper catalog

When does this occur?

Always

How do we replicate the issue?

Attempt to resolve a catalog from a profile using JSON tooling

Expected behavior (i.e. solution)

The rlink should reference the JSON representation of the catalog

Other Comments

User Story:

As an OSCAL content consumer, I need the SP 800-53rev4 Appendix J controls added to the SP 800-53rev4 catalog.

Goals:

The controls in SP 800-53rev4 Appendix J are added as controls in the SP 800-53rev4 catalog.

Dependencies:

None.

Acceptance Criteria

All appendix J controls have been added to the SP 800-53rev4 catalog.

User Story:

On Dec 10 a version of SP800-53 revision 5 was released with corrections to errata.

OSCAL versions available in this repository should be updated accordingly.

Goals:

Keep the data sources here up to date with the latest official releases.

Dependencies:

This was waiting for RC1 OSCAL schemas, no longer a blocker.

See also #43 and #47.

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• 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.

User Story:

Early in the OSCAL effort, the FedRAMP baselines were initially found within the usnistgov/OSCAL repository. Since then, the updated baselines are being maintained by FedRAMP in the GSA/fedramp-automation repository.

with the migration of OSCAL content from the usnistgov/OSCAL repository to the usnistgov/OSCAL-content repository we should discontinue the duplicative maintenance of the FedRAMP content from usnistgov repositories.

Goals:

• Ensure all FedRAMP content is removed from the OSCAL repository, and replaced (temporarily) with files directing users to the correct location in the fedramp-automation repo.
• Within the OSCAL repo, ensure any links/references to FedRAMP content are updated with the GSA/fedramp-automation repo location.

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.

User Story:

As an OSCAL catalog/framework maintainer, I should be able to express the CJIS Security Policy in OSCAL-formatted XML and JSON

Goals:

Provide an OSCAL-formatted example of the CJIS Security Policy; more specifically "Section 5 - Policy and Implementation".

Dependencies:

Leverages the "catalog" and "framework" models.

Acceptance Criteria

A well-formed OSCAL document representing the CJIS Security Policy is created.

The JSON files in the GitHub repository for the NIST 800-53 Rev.5 catalog (NIST_SP-800-53_rev5-FINAL_catalog-min.json and NIST_SP-800-53_rev5-FINAL_catalog.json) have some oddly placed newlines and spaces. Specifically, in the "prose" values, generally where the prose begins with a reference to a parameter, are newline marks followed by a series of spaces immediately before but sometimes after the insert (e.g. "prose":"\n {{ ac-2_prm_8 }} when system usage or need-to-know changes for an individual;"}). Note that, at least in the instances I checked, there appeared to be 22 individual space characters between the newline and the insert.

As a developer of tooling built around OSCAL catalogs/profiles, would it be possible to either have separate branches, tags, or actual releases for the different OSCAL milestones? At least the current and RC releases would be extremely helpful.

This would provide stability in the tooling that pulls in catalogs/profiles provided by NIST and FedRAMP and avoid breaking changes based on updates in the OSCAL milestone.

The OSCAL definition of MA-4 (2) does not match the PDF
<control class="SP800-53-enhancement" id="ma-4.2"> <title>Logically separated communications paths.</title> <prop name="label">MA-4(2)</prop> <prop name="sort-id">MA-04(02)</prop> <part name="statement" id="ma-4.2_smt"> <p>Discussion: Communications paths can be logically separated using encryption.</p> </part> <part name="guidance" id="ma-4.2_gdn"/> </control>
It should reflect:
(2) NONLOCAL MAINTENANCE | DOCUMENT NONLOCAL MAINTENANCE
[Withdrawn: Incorporated into MA-1, MA-4.]

User Story:

As captured from the full text of SP800-53B, we have four OSCAL profiles, one for each of the security impact levels HIGH, MODERATE and LOW, and also a separate profile for the controls identified for the "privacy baseline" (PRIVACY).

However, the controls selected as "privacy" controls are not intended to be managed or grouped by themselves: this selection is intended to be deployed as an overlay (supplementary control set) to any or each of the security baselines, i.e. as HIGH+PRIVACY, MODERATE+PRIVACY, LOW+PRIVACY.

These composite groupings can and should be represented as OSCAL profiles.

Goals:

1. Deploy OSCAL profiles that represent these combinations as overlays
2. Consider alternatives and refine methods for addressing use cases for 'overlays' and other combinations, at this level of complexity, of controls selected from the same or different catalogs via multiple imports.
3. (optional) Test and extend profile resolution to confirm this use case is supported

The third goal, which would include developing unit tests to reflect the import semantics, could be spun off onto a separate Issue, if it proves to be complex.

Dependencies:

If goal #3 is in scope, we should be prepared to consider edge cases in OSCAL profile import semantics, regarding chains of imports, merge behavior etc.

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• 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.

User Story:

As an OSCAL modeler and content author, I need the OSCAL syntax to support linking of control objectives and assessment methods. This is currently not possible with the NIST SP 800-53 Rev 4 OSCAL catalog.

Goals:

• Assign IDs to assessment methods parts.
• Define the catalog syntax by which control objectives may be linked to assessment methods.

Dependencies:

None; however, this is an off-shoot of usnistgov/OSCAL#628.

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• 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.

I'm working with SP 800-53 rev 5 JSON files. I noticed that none of the baseline files (FPD) reference SR-12 but publication NIST SP 800 53B clearly marks SR-12 within the High, Moderate and Low Impact baselines.

Describe the bug

In NIST_SP-800-53_rev5_catalog.json there is a self-reference from control SC-12 to SC-12 (itself).

Who is the bug affecting?

Everyone working with the example catalog.

What is affected by this bug?

Data consistency.

When does this occur?

When importing the data into a tool.

How do we replicate the issue?

Please see the attached screenshots:

• I highlighted the link in the JSON file.
• I noticed the self-reference while importing this data into the Neo4J graph database. It's immediately obvious in the graph:

Expected behavior (i.e. solution)

This reference should not be present.

Other Comments

I noticed this while importing the OSCAL content into a Neo4J database. The scripts I am using are available in my Github repo

Errors in production of SP800-53 Revision 5 in OSCAL, both final and earlier (FPD) versions, show the process needs to be addressed for robustness and maintainability.

A new design will shorten and simplify the initial extraction by performing a generic conversion from the Word document (docx) into HTML, which contains all the necessary information for the OSCAL, and then processing it through a chain of cleanup and enhancement filters. By using the open-source XSweet utility, we can do this end-to-end in XSLT with no other language or application dependencies.

The new pipeline should produce valid and correct OSCAL for the current (final) version of SP800-53 Rev 5, with the same UUIDs as the presently published version (for minimum destabilization). Going forward, it should also be able to produce the same correct outputs for future revisions (with minimal adjustment and assuming consistent formatting in the input data), with UUIDs maintained or refreshed as required.

Issues #16 and #23 can also be addressed in this work, if not already resolved.

Criteria for acceptance:

• The new pipeline (including an XSweet first step) is able to produce valid and correct OSCAL from the best-available docx version of SP800-53 rev 5.
• Optionally, UUIDs can be preserved from an older catalog provided to the pipeline as a secondary input. The same object (e.g., a resource element) should be given the same UUID on its uuid flag. As an alternative, all UUIDs can be refreshed.
• The pipeline has been committed to a Github repository for maintenance. (An internal NIST repository is fine inasmuch as this is not a general-purpose or general-use tool.)

Producing a valid NVD XML representation of an input catalog -- since we will no longer do this at the beginning -- is not a goal of this Issue, and should be tracked separately. It makes sense to build this as a conversion from the OSCAL produced by this pipeline.

User Story:

As an OSCAL stakeholder, it would be helpful to have component definition files in OSCAL to serve as examples, as well as for proof-of-concept and testing.

Goals:

• Identify suitable examples to create.
• Create examples.

Dependencies:

Issue usnistgov/OSCAL#216 and possibly Issue usnistgov/OSCAL#328.

Acceptance Criteria

• All intended examples have been fully drafted.

Describe the bug

1. The source values in the example component definition reference a relative catalog and profile that contain /content in the path, which is no longer correct. The /content segment of the path should be removed.
2. The leveraged-authorizations in the example leveraging SSP references a relative link that no longer exists. It is likely intended to point to oscal_leveraged-example_ssp.<format> (and the rel value should probably indicate the correct format).

Who is the bug affecting?

Anyone working with the leveraging SSP and component definition examples.

What is affected by this bug?

The examples are incorrect and developers building tooling around them must compensate.

When does this occur?

Always

How do we replicate the issue?

N/A

Expected behavior (i.e. solution)

Links should be resolvable and correct.

Other Comments

User Story:

Responding to usnistgov/OSCAL#534 we implemented a simple profile link checker that reports when profiles call controls that can't be found in an imported catalog. It doesn't work on profiles importing profiles but it is better than nothing for detecting simple pointer errors.

The Schematron is in this branch: https://github.com/wendellpiez/OSCAL/tree/Issue534-profile-validation. The PR is usnistgov/OSCAL#539.

(Link to commit: wendellpiez/OSCAL@aa223f3#diff-ae6cae8616ab5f465e28e103376e036e )

Goals:

Help ensure profiles committed to the repo are correct.

This Schematron can also be the basis for other checks to be run on profiles.

Dependencies:

• fixing build breaking from usnistgov/metaschema#240 and updated submodule commit when #240 has been merged into OSCAL.

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.

{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.}

User Story:

As an OSCAL content consumer, I have an example of a real-world SSP in OSCAL format.

Goals:

• Develop a "flat SSP"
• Pick a sample of the controls that cross multiple families
• Selectively enhance the component data where possible

Dependencies:

Acceptance Criteria

1. A real-world SSP exists in OSCAL format.

Describe the bug

The README.md file in the root directory lists the directory structure and descriptions of the src directory since it is a copy of the README.md from that directory.

- nist.gov/SP800-53/rev4: This directory contains OSCAL examples of the catalog, and low, moderate, and high baselines defined by NIST Special Publication (SP) 800-53 Revision 4.

- nist.gov/SP800-53/rev5: This directory contains OSCAL examples of the catalog, and low, moderate, and high baselines defined by NIST Special Publication (SP) 800-53B Revision 5 and SP 800-53B Revision 5 respectively.

- fedramp.gov: This directory contains OSCAL examples of the low, moderate, and high baselines defined by FedRAMP (the Federal Risk and Authorization Management Program).

- components: This directory contains sample OSCAL component files.

- mini-testing: This directory contains sample files that can be used for unit testing in support of regressions of OSCAL.

The structure of the root directory and content of README.md should list, in addition to the .github directory and the link to OSCAL schema repo, the following:

- components: This directory contains sample OSCAL component files.

- fedramp.gov: This directory contains OSCAL examples of the low, moderate, and high baselines defined by FedRAMP (the Federal Risk and Authorization Management Program).

- nist.gov/SP800-53/rev4: This directory contains OSCAL examples of the catalog, and low, moderate, and high baselines defined by NIST Special Publication (SP) 800-53 Revision 4.

- nist.gov/SP800-53/rev5: This directory contains OSCAL examples of the catalog, and low, moderate, and high baselines defined by NIST Special Publication (SP) 800-53B Revision 5 and SP 800-53B Revision 5 respectively.

- src: This directory contains the source files for all the OSCAL examples located in this repository.

- ssp-example: This directory contains the SSP data model and SSP mock-up samples

Describe the bug

The example SSP contains a relative import-profile href that is incorrect. (I believe the profiles were moved and the relative links weren't updated.

Who is the bug affecting?

Developers trying to resolve the example SSP's profile

What is affected by this bug?

The example SSP's profile

When does this occur?

Always

How do we replicate the issue?

Attempt to resolve the example SSP's profile

Expected behavior (i.e. solution)

The import-profile href should point to the correct profile location

Other Comments

User Story:

As an OSCAL content consumer, I need an accurate representation in the OSCAL SP800-53/rev4 catalog of the controls described in the document SP 800-53rev4 Appendix J.

Goals:

The controls added to the OSCAL SP800-53/rev4 catalog are free of errors.

Dependencies:

• usnistgov/OSCAL#347

Acceptance Criteria

All controls added to the OSCAL SP800-53/rev4 catalog have been reviewed and are accurate.

User Story:

As an security practitioner responsible for transitioning my system from NIST SP 800-53 Revision 4 to Revision 5, it would be helpful to have the Revision 5 representation in OSCAL format as soon as possible after the official Revision 5 specification is published.

This transition is a great time to promote the use of OSCAL as having the content in machine-readable format would help system owners make the transition.

Properly tooled system owners should be able to use 800-53 Revision 4 and Revision 5 control content in OSCAL to produce a delta file. Any that have started to express their Rev 4 implementation in OSCAL, could use automation to more easily identify gaps and transition their implementation to Rev 5.

As of Aug. 30, 2018, the publication schedule calls for:

• Draft 800-53, Revision 5 to be published December 2018
• Final 800-53, Revision 5 to be published March 2019
• Draft 800-53A, Revision 5 to be published September 2019
• Final 800-53A, Revision 5, to be published December 2019

Goals:

• Create and publish OSCAL content with 800-53 / 800-53A content as soon as possible after each becomes available in official draft and final.
• This means publishing 800-53 content in OSCAL initially without the 800-53A content due to the large time gap between the two.

Dependencies:

• Finalizing the OSCAL Catalog and profile specifications.
• Publication of draft and final 800-53, Revision 5 documents from NIST.

Acceptance Criteria

• Create and publish an OSCAL interim draft Catalog for NIST SP 800-53, Revision 5 as soon as possible after the draft is published, and before the final is published. This would not have the 800-53A content.
• Update and publish an interim final OSCAL Catalog for NIST SP 800-53, Revision 5 as soon as possible after the Final document is published. This would not have the 800-53A content.
• Create and publish an updated OSCAL final draft Catalog for NIST SP 800-53, Revision 5 that includes the 800-53A content as soon as possible after the 800-53A Draft is published, and before the final is published.
• Update and publish an full final OSCAL Catalog for NIST SP 800-53, Revision 5 as soon as possible after the Final document is published. This would not have the 800-53A content.
• Before publishing, perform a quality review and peer of each of the four above publications.

Create a "Feature Request" template:

User Story:

As an OSCAL content {stakeholder}, I {provide a clear and concise description of what the problem is. Ex. I need to be able to do}

Goals:

{A clear and concise description of what you want to happen. This should be outcome-focused. Include a concise description of any alternative solutions or features you've considered. Feel free to include screenshots or examples about the feature request here.}

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 OSCAL repo, 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.}

Create a "Bug Report" template:

Describe the bug

{A clear and concise description of what the bug is.}

Who is the bug affecting?

What is affected by this bug?

{Describe the impact the bug is having.}

When does this occur?

{Describe the conditions under which the bug is occurring.}

How do we replicate the issue?

{What are the steps to reproduce the behavior?

1. Do this...
2. Then this...
3. See error...

If applicable, add screenshots to help explain your problem.}

Expected behavior (i.e. solution)

{A clear and concise description of what you expected to happen.}

Other Comments

{Add any other context about the problem here.}

Crete an "Ask a Question" template:

{Please enter your question.}

Describe the bug

The structure of control PM-30 in the OSCAL content does not match the structure in the published 800-53 Rev5 PDF file.

PDF structure

JSON "parts" segment

        "parts": [
          {
            "id": "pm-30_smt",
            "name": "statement",
            "parts": [
              {
                "id": "pm-30_smt.a",
                "name": "item",
                "props": [
                  {
                    "name": "label",
                    "value": "a."
                  }
                ],
                "prose": "Develop an organization-wide strategy for managing supply chain risks associated with the development, acquisition, maintenance, and disposal of systems, system components, and system services;",
                "parts": [
                  {
                    "id": "pm-30_smt.a.1",
                    "name": "item",
                    "props": [
                      {
                        "name": "label",
                        "value": "1."
                      }
                    ],
                    "prose": "Implement the supply chain risk management strategy consistently across the organization; and",
                    "parts": [
                      {
                        "id": "pm-30_smt.a.1.a",
                        "name": "item",
                        "props": [
                          {
                            "name": "label",
                            "value": "(a)"
                          }
                        ],
                        "prose": "Review and update the supply chain risk management strategy on {{ pm-30_prm_1 }} or as required, to address organizational changes."
                      }
                    ]
                  }
                ]
              }
            ]
          },

XML content has similar structure as JSON.

Who is the bug affecting?

Consumers of the OSCAL content

Describe the bug

SP 800-53 rev5 XML content contains withdrawn controls — some of those controls are cited in the SP 800-53 rev5 XML control baselines.

The controls are AU-3(2), AU-8(1), CM-5(3), IR-10, SI-2(1), SI-3(1), SI-8(1).

An example can be seen here.

Attached archive
800-53-compare.zip
contains a report of the affected controls.

Who is the bug affecting?

Anyone who expected a baseline to cite controls which are not withdrawn.

What is affected by this bug?

Security content automation using oscal-content XML documents..

When does this occur?

Durably.

How do we replicate the issue?

Presumably, the process by which the SP 800-53 rev5 security control baseline content was generated is the source of the anomaly.

SP 800-53B indicates these controls are not members of the control baselines.

Expected behavior (i.e. solution)

Withdrawn controls within a catalog should not be cited in attendant baselines.

The NIST SP 800-53 YAML files, and possibly others, as posted are not valid. Running a Revision 5 YAML file through a validator shows many errors. Most errors are related to the use of colons in values. Values should likely be surrounded by quotes or something similar.

User Story:

Curious if this package is going to incorporate CCI correlation to control families?

Goals:

Since DISA released a correlation XML for CCI's to control family to verify STIG's and be able to related them quickly to control family, will this do the same for Rev 4 and Rev 5?

Dependencies:

{Describe any previous issues or related work that must be completed to start or complete this issue.}

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• 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.}

Describe the bug

When using the latest OSCAL spec according to (https://pages.nist.gov/OSCAL/documentation/schema/implementation-layer/ssp/json-model-map/ and/or https://github.com/usnistgov/OSCAL/blob/master/json/schema/oscal_ssp_schema.json)

examples/ssp/json/ssp-example.json fails validation due to annotations that are no longer required.

Who is the bug affecting?

Anyone relying on consistency between oscal content and the base oscal repo

When does this occur?

When validating json object

Exhibit (A): the XML SSP Example

Exhibit (B): the XML JSON Example

Notice the difference in the description section.
in xml we have html tags.
in JSON we have newline characters.

It seems to be advertised that JSON and XML are interoperable, but looking at these two files the conversion appears to be lossy. The HTML tags used in the XML version are not stored in the json representation.
As an oscal developer this is introducing a difficulty in supporting the conversion between representations in a lossless manner when the examples are lossy.
Should we store the HTML string as is in the description field?
Convert the inner-content of description tag to markdown and back?
Some guidance would be much appreciated, kind regards.

~S

User Story:

OSCAL metadata includes provision for formal version tracking in the document instance, but we have not used it so far for releases of SP800-53 data in OSCAL.

As processes become more regular and formal we should consider whether we should be using this feature, either for its utility, as a demonstration, or both.

Goals:

Define a usage profile for change tracking of SP800-53 data (catalog and profiles) appropriate to its release/change management cycle.

Implement this usage in releases going forward, perhaps by integrating it into the production pipeline for these data sets.

Dependencies:

None at present. But the design should reflect the needs of all stakeholders, including needs for both transparency, and low overhead.

Acceptance Criteria

• All readme documentation affected by the changes in this issue have been updated.
• 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.

Artifacts such as XML, HTML, Markdown or XSD files, when produced by automated transformations (and even when not) should have comments offering hints as to what they are, when they were produced etc.

Some timestamping logic has been added to the pipelines that produce SP800-53 and ISO 27002 examples, which produces comments at the top of those file outputs. But there are other places (for example, schema documentation) where we need this also.

At time of writing, a final release of NIST 800-53B, describing control baselines, has been or is being made available.

For the FPD we produced four OSCAL profiles representing baselines HIGH, MODERATE, LOW and PRIVACY.

We should refresh this work based on the latest release, and update the published profiles accordingly.

Describe the bug

This is a follow-up from #69. @tuckerzp and @zclarkEDC surfaced EasyDynamics/oscal-react-library#125 after we updated FedRAMP's directory structure in GSA/fedramp-automation#137. As agreed and discussed, since the source material is FedRAMP's and I updated the reference to it here last, I will file a report and fix here for their use and the rest of the community.

Who is the bug affecting?

All those using the example components.

What is affected by this bug?

Anyone using the example components.

When does this occur?

Consistently.

How do we replicate the issue?

1. Follow the details in EasyDynamics/oscal-react-library#125.

Expected behavior (i.e. solution)

The correct profile is referenced in the component, so no source resolution errors would occur.

Describe the bug

The component examples are citing the wrong enhancement of the AC-2 control . The AC-2.3 is addressing the inactive accounts not AC-2.2

What files is the bug affecting?

https://github.com/usnistgov/OSCAL/blob/master/content/components/json/example-component-min.json
https://github.com/usnistgov/OSCAL/blob/master/content/components/json/example-component.json

When does this occur?

When the example was created

Expected behavior (i.e. solution)

Replace any reference to AC-2.2 with AC-2.3

Other Comments

none.

Describe the bug

Several errors have been found in the version of the SP800-53 Rev 5 FPD now distributed on the OSCAL site here: https://github.com/usnistgov/OSCAL/blob/master/src/content/nist.gov/SP800-53/rev5/xml/NIST_SP-800-53_rev5-FPD_catalog.xml

These errors are then propagated (in CI/CD) to released XML and JSON versions in the content directory.

Here are the issues we know of so far:

• AU-9 (7) missing "Related" links
• SA-11 (2) missing "Related" links
• PT-8 (2) - requires inline link to resource [PRIVACT] in Guidance section
• IA-5 (2) PUBLIC KEY-BASED AUTHENTICATION - the actual title is dropped, with the statement appearing as the title and the guidance ("Discussion") appearing as the statement
• MA-4 (4) - missing guidance (Discussion) part

Who is the bug affecting?

Anybody who needs to rely on this data.

What is affected by this bug?

Any downstream processing of these controls (enhancements).

Expected behavior (i.e. solution)

The conversion pipeline must be amended to correct these errors. This may require changes in either or both the source->NVD-XML extraction, or the NVD-XML to OSCAL conversion. Where the extraction cannot be corrected due to anomalies in the source data, the conversion step can be provided with a patch to insert the corrected information.

Describe the bug

The leveraged ssp and leveraging ssp example have each 2 this-system components. An SSP can have only one this-system component. The error might come from the M3-> RC1 OSCAL up converter.

Who is the bug affecting?

All parties interested in the example

What is affected by this bug?

The accuracy of the example

When does this occur?

Always

How do we replicate the issue?

Exhibit in the example files. We might want to invest time and fix the converter ONLY if there are interested parties.

Expected behavior (i.e. solution)

Only one this-system component is included.

Other Comments

User Story:

In usnistgov/OSCAL#611 we remodeled citations in the back matter. Data was migrated, but the new model (which supports both a title and a citation) shows how impoverished it is. More complete and legible references would be welcome to users and consumers.

It would be great to:

1. Remove citation elements when they are only titles, and fully captured by title
2. Rewrite titles as only titles when citations have more than the title
3. Supply actual citations from the published SP (PDF) if/where available (not just the abbreviated citation as given).

Goals:

Improve the data set for use in the field.

Also, determine the scope and complexity of this task, since similar work may be necessary in future (on rev 5 for example).

Dependencies:

We anticipate process questions, regarding what to do with unclear cases, broken links etc., potentially requiring some domain expertise to resolve.

This work should be done in a separate branch. Only the OSCAL SP800-53 control catalog (a single file) should be affected. Before a PR, the branch should be rebased against master to ensure that schemas are up to date, etc.

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.