Publication Characteristics

[brian-ruf]

User Story:

As an OSCAL content creator, I can provide standardized content within OSCAL files (catalogs, profiles, etc.) that identify publication characteristics.
At a minimum, this would include publication Title, Date, Version Number, and Publishing Organization. Ideally, this also includes contact information for the publishing organization (web site, email address, etc.) and document revision history (date, version, change description).

Goals:

1. Define clear information fields, and a standard set of tagging to support those fields.
2. Identify required and optional fields.
3. Ensure all current OSCAL files are updated to include this publication information.
4. Address version control and version tagging (metadata)
5. For catalogs, consider a reference to the base-authoritative source from which the catalog is derived.

Dependencies:

None.

Acceptance Criteria

1. Publication fields identified.
2. Schema tags established and documented.
3. All current "production" versions of OSCAL files updated to include publication characteristics tagging.
4. Version control capability clearly established, documented, and communicated to team.
5. Tracability goes back to authoritative source. (Example: 800-53 Catalog points to Official 800-53 document.)

[wendellpiez]

This is not a huge work item, but it must be coordinated with metaschema work since any metadata model we propose will also have to go there.

Also suggest changing the name of this Issue to sth like "Catalog and Profile metadata modeling".

[david-waltermire]

2018-06-07 Meeting Notes:

• @brianrufgsa and @wendellpiez will meet the week on 6/11 to work out the data structure needed to support this issue. Fields, data types, and cardinality. This will be posted as a comment on this issue.
• We will review this on the 6/14 status meeting.

[wendellpiez]

@brianrufgsa has an ERD showing possible metadata fields, which he is forwarding to me. We will aim for something both comprehensive (enough) and lightweight.

[brian-ruf]

Items for team discussion/agreement:

• <title> as it's own element or grouped with other publication characteristics.
• Publication date and version. Since we need a version history, do we simply adopt a standard that the most recent entry in version history represents "this document's" version and date, or do we also explicitly have and elements separate from the version history.

[brian-ruf]

June 14 Status:
Developed initial (draft) ERD. Per a suggestion from @wendellpiez, I am updating it to align with the NISO Standard Tag Suite (http://niso-sts.org/).

[wendellpiez]

June 26 Status

A sketched model is underway in the form of a metaschema, capturing fields appearing in the ERD. Will post again when committed.

We didn't finish covering the details of these fields (from the db) in our work session:

system_id
organization_id
unique_id
system_name
system_name_short description
purpose
security_sensitivity_level
security_objective_confidentiality
security_objective_integrity
security_objective_availability
security_auth_ial
security_auth_aal
security_auth_fal
security_eauth_level
deployment_status
deployment_type
deployment_model

Many of these might best be handled by a generic model, permitting FedRAMP (or other recipient/authority) to define the particular fields in detail, as in

<meta-group term="security">
  <meta term="sensitivity-level"> [ ... ] </meta-term>
  <meta term="objective-confidentiality">[ ... ] </meta-term>
  <meta term="objective-integrity">[ ... ] </meta-term>
  <meta term="objective-availability">[ ... ] </meta-term>
  <meta-group term="auth">
    <meta term="ial"> [ ... ] </meta>
    <meta term="eal"> [ ... ] </meta>

Next steps: produce actual data conformant with our sketch; (re)iterate the design a few times.

[wendellpiez]

Note that while the model above could also be parts and properties (part | prop), reserving a separate element set for document metadata (not any sort of control contents) may make sense here.

Another thing to note is that whatever this is, it could be a utilitarian approach to one of the commonest sets of metadata requirements, namely keywords, index terms, controlled reference vocabularies and taxonomies. Which we have not faced yet (TMK) but it is likely to come up sooner or later.

[wendellpiez]

Work is proceeding in a new branch, with a commit here (very much WIP this mockup isn't even valid yet): 0d81459

[wendellpiez]

For current WIP, see https://github.com/wendellpiez/OSCAL/tree/feature-metadata-schema/schema/xml especially metadata-blank.xml (a sample), and also the file oscal-metadata-metaschema.xml in the neighboring metaschema directory.

Things are valid, hanging together, and ready to try out on real data.

[brian-ruf]

June 28 Status: As indicated by @wendellpiez above, Wendell, Brian, and Peter met to discuss this on June 26th and reached a proposed draft baseline. Next step is to seek concurrence from Dave.

[iMichaela]

June 28 Status Meeting Update

@brianrufgsa , @wendellpiez and @PCrayton worked on it on June 26th - see above

[iMichaela]

July 18 Status Update (Sprint 12 Acceptance Meeting)

@wendellpiez has a model that needs review. He will submit shortly a PR.

[wendellpiez]

A schema and demo file for a lightweight tag set for document-level metadata is here in a branch in my repo:

https://github.com/wendellpiez/OSCAL/tree/feature-metadata-schema/schema/xml

In the neighboring metaschema directory is a metaschema (valid to current models afaik) describing this schema. (Note that currently, all the schemas live together, as do metaschemas etc. We might wish to change this.)

The "blank" XML document is not blank as to tagging (it has tagging valid to the model), but only as to data content. Most of the elements are optional and would not appear if not used; this is only a specimen for demo/testing.

The next step is to use this file and schema in a "fill in the blank" exercise, collecting the relevant metadata for catalogs and profiles we have so far.

I am ready to make a PR, but I should have asked, which branch should I request this be pulled into? @anweiss or @david-waltermire-nist any advice?

[david-waltermire]

Status Update

This is still a work in progress by @wendellpiez based on feedback from @brianrufgsa.

[wendellpiez]

Planning meeting for Thursday Aug 20 with @brianrufgsa and @PCrayton to review and proceed with making examples.

[iMichaela]

Status Meeting: 8/23/2018

@wendellpiez and @brianrufgsa met today and made more progress.

[david-waltermire]

9/6/2018 Status Meeting

We discussed the following as an example of document metadata. https://www.fedramp.gov/assets/resources/documents/CSP_Continuous_Monitoring_Strategy_Guide.pdf

[wendellpiez]

Sprint 13 Progress Sep 13 2018

Meeting with @david-waltermire-nist 9/12 we made progress on the (meta)schema for the metadata header (to be integrated into main schemas for catalog, profile and other modules). The model is now (even) simpler and more streamlined. A mockup/sample provided by @brianrufgsa is valid to the provisional model. We are making more examples, inasmuch as we need headers for SP800-53 and all profiles (NIST and FedRAMP).

Percent complete: 50%

[wendellpiez]

Sprint 13 Progress Sep 20 2018

More progress is available in a branch in my repo including rough cut examples.

Integrating the metadata (meta)schema into catalog and profile (meta)schemas should probably wait until outstanding PRs are accepted.

Percent complete: 60%

[wendellpiez]

Sprint 13 Progress Sep 27 2018

IMO this will soon become a blocking task for other tasks and should be a priority for next Sprint. (This metaschema will be in play with the implementation layer as well.)

Presently the work on modeling document headers (metadata) is all in a branch in my repo (feature-metadata-schema). It is difficult to push forward, however, until the metaschema work (in another branch and behind PR #237) is stabilized.

Percent complete: 60%

Finalizing this task will require input from NIST @iMichaela @david-waltermire-nist wrt the metadata headers on SP800-53 (catalog and profiles) and FedRAMP (GSA) @brianrufgsa on metadata headers on FedRAMP profiles (even if unofficial/provisional).

[iMichaela]

9/26/2018

@wendellpiez prototyped at OSCAL/schema/metaschema/nist-sp800-53-catalog-header.xml the newly proposed metadata. @david-waltermire-nist has concerns with the proposed model. A hash of the referenced catalog is suggested as an alternative, but @brianrufgsa finds it risky.
We will break #196 into smaller issues. We will close this issue after breaking it into smaller issues. We will need a new issue addressing the integrity (hash) of a document: for the current document and referenced document.