Incorporation of other "ontology" documents from the SP corpus.

[egyptiankarim]

User Story:

As an OSCAL (and NIST) fan and cybersecurity professional, I regularly reference several other NIST SP documents in the course of working on security plans, control implementations, assessments, and so on. Specifically:

• NIST SP 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories
• NIST SP 800-30, Guide for Conducting Risk Assessments
• NIST SP 800-181, Workforce Framework for Cybersecurity (NICE Framework)

Together, these "ontology" type documents help to structure conversations about the types of data in play, specific dimensions of risk, and the types of folks best suited to help implement recommendations (resulting from assessments, etc.).

To wit, easily searching and providing programmatic access to this content has been the goal of the Risk Redux, and component projects control_freak, typist, and performatron.

In order to make projects like the Risk Redux more robust, I need to be able to reference canonical sources of the content of OSCAL-adjacent documents, and would love to see that content incorporated into OSCAL itself.

Goals:

I want OSCAL to expand to include the content from other adjacent "ontology" documents from the SP corpus. Especially SP 800-30, SP 800-60, and SP 800-181.

Dependencies:

I don't believe there are any existing dependencies for implementing the enhancement described above.

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.

[GaryGapinski]

This document has a rather large portion of SP 800-60v2r1. It resembles but is not an OSCAL document. The information-type elements are partially modeled after this.

[sunstonesecure-robert]

I think this would put too much into OSCAL that is best managed by tooling. as it is OSCAL is very large. not everything needs to be in one schema IMO; just one opinion.

we (kubernetes policy wg) are for example trying to align policy elements to OSCAL for compatibility/integration, so adding even more requirements would make it cumbersome to support OSCAL - especially where those concepts are not relevant to kubernetes. having the minimum number of concepts that support data from disparate systems and environments makes OSCAL better - less is more: letting OSCAL focus on its specific domain - controls - allows for supporting risk management and a data first approach to expressing controls, without having to bring in all domains into the schema.

[egyptiankarim]

[…] having the minimum number of concepts that support data from disparate systems and environments makes OSCAL better - less is more […]

@sunstonesecure-robert I absolutely appreciate that perspective. I just can’t help but think a canonical NIST reference to the information in those key documents (in a format other than the PDFs 😋) would be incredibly useful. OSCAL seems as good a place as any.

[sunstonesecure-robert]

could you use this to reference the doc by URL?

https://pages.nist.gov/OSCAL/reference/latest/catalog/xml-reference/#/catalog/back-matter

if you are worried the link would change and there's no publicly available NIST github repo (I've never thought to look), then maybe just check a copy into your public repo and use that version controlled URL?

[egyptiankarim]

@sunstonesecure-robert those are useful resources, to be sure. But just to be clear, what I’m hoping for is the content from some of those other OSCAL-adjacent documents (e.g., 800-30 and 800-60) in a structured format like they’ve done with the control catalog. Right now the only way to review that content from a canonical source is with the PDFs. It’d be nice, as an example, to have all of the information types defined in 800-60 in an official NIST managed repository, structured as JSON, XML, etc according to some official schema. I’ve already parsed a lot of this content myself manually, to develop projects like the ones I linked in the original post, but I’d love to have a canonical NIST reference to drive future work.

[david-waltermire]

I am switching this to a discussion.

@egyptiankarim We have considered adding formats for things like a Privacy Impact Assessment (PIA). We have also considered adding something around an organizational security/privacy plan to use as a companion to the SSP for controls that apply at the organizational level. We do hope to get to these in the not-to-distant future.

What specific artifacts would you find most interesting?

[egyptiankarim]

@david-waltermire-nist I think it would be great to see:

• The information types cataloged in SP 800-60.
• The threat sources, threat events, TTPs, etc from SP 800-30.
• The work roles, categories, and KSATs from SP 800-181.
• The assessment objectives from SP 800-53a.

Ideally, this content would exist in a variety of programmatically accessible formats (e.g., JSON and XML), and could be officially referenced from source controlled repositories like usnistgov/OSCAL.

It would also be incredible to see "official schemas" for each of these things, so that organizations could, for example, build out their own catalogs of information types or assessment objectives in a manner that matches up with how NIST formally defines them in their SPs.

I reference all of this content regularly in my day-to-day, and I'd love to see OSCAL get to a point where I could do so programmatically and that spares me having to poke around manually at the PDFs.

[ohsh6o]

@david-waltermire-nist, shall we consider this information as part of the approach for GSA/fedramp-automation#115?