usnistgov / oscal

Open Security Controls Assessment Language (OSCAL)

Open Security Controls Assessment Language (OSCAL)

NIST is developing the Open Security Controls Assessment Language (OSCAL), a set of hierarchical, XML-, JSON-, and YAML-based formats that provide a standardized representations of information pertaining to the publication, implementation, and assessment of security controls. OSCAL is being developed through a collaborative approach with the public. Public contributions to this project are welcome.

With this effort, we are stressing the agile development of a set of minimal formats that are both generic enough to capture the breadth of data in scope (controls specifications), while also capable of ad-hoc tuning and extension to support peculiarities of both (industry or sector) standard and new control types.

The OSCAL website provides an overview of the OSCAL project, including an XML and JSON schema reference, examples, and other resources.

If you are interested in contributing to the development of OSCAL, refer to the contributor guidance for more information.

Project Repositories

Repository	Description
OSCAL	The main OSCAL project that contains the source code for the OSCAL models.
OSCAL-Pages	The project that contains the public OSCAL website content.
OSCAL-Reference	The project that contains the model documentation and developer reference content.
OSCAL-Content	The project that contains examples of OSCAL model content.
OSCAL-DEFINE	The project for managing research into the development and enhancement of OSCAL.

Project Status

To view the latest release of OSCAL check out GitHub releases. Each release on that page provides a complete summary of the changes made in each release.

The changes made in each release are based on the excellent feedback and contributions that are received from the OSCAL community. The NIST OSCAL team is very thankful for all of it.

Any feedback may be emailed to the NIST OSCAL team at [email protected] or by creating an issue on the GitHub repository.

Looking forward, the NIST OSCAL team is excited to continue working with the OSCAL community to continue enhancing OSCAL through additional minor releases. Future efforts will include providing a more complete set of documentation for all the OSCAL layers and models, creating more examples, and providing a diverse set of tutorials.

For additional information on the OSCAL project, please see the NIST’s Cybersecurity Insights blog: “The Foundation for Interoperable and Portable Security Automation is Revealed in NIST’s OSCAL Project” and the OSCAL website.

The NIST team is also maintaining OSCAL content that is updated to the latest OSCAL revision. The OSCAL content repository provides OSCAL examples, in addition to:

• The NIST SP 800-53 revision 5 catalog and the security and privacy NIST SP 800-53B baselines.
• The NIST SP 800-53 revision 4 catalog and the three NIST SP 800-53 revision 4 baselines.
• The FedRAMP SP 800-53 revision 4 baselines.

All of this OSCAL content is provided in XML, JSON and YAML formats.

NIST is also seeking tool developers, vendors, and service providers that would like to implement the OSCAL models in commercial and open-source offerings. NIST is also seeking software and service providers that are willing to work with us to represent control implementation information about their products.

To provide feedback, to ask questions, or to let us know about an OSCAL implementation you are working on, please email the NIST OSCAL team at [email protected]. You can also post publicly to the OSCAL development list: [email protected] or create an issue on our GitHub repository.

Please find instructions for joining the OSCAL development and update lists on our contacts page. If you have any questions about OSCAL in general or if you would like to get involved in the OSCAL project, please contact us at: [email protected] or on Gitter.

Cloning this repository

Run the following Git command to clone the OSCAL repository.

git clone --recurse-submodules https://github.com/usnistgov/OSCAL.git

oscal's Issues

Provide JSON mechanism to represent XML-equivalent prose

Goals:

1. Ensure that the JSON representation of OSCAL is equivalent in all functionality to the XML representation. This means that content can be round-tripped between the XML-JSON-XML representations. Whitespace preservation may not be possible,
2. Develop a prose markup capability in JSON to support the equivalent features in XML (e.g., parameter insertion, etc.). Consider using markdown to do this, with some extensions.
3. Answer how namespaces will be handled in JSON. OSCAL currently has a single namespace.

Dependencies:

1. Examples of OSCAL XML-based catalog and profile content. These examples are SP 800-53 based.
2. Pull request (#63) is merged into the sprint-5 branch,

Acceptance Criteria:

1. Demonstrate that content can be round-tripped. Content can be converted from XML-to-JSON-to-XML without any semantic loss of information. (Addresses #59)
2. Demonstrate that OSCAL JSON content can be validated to be well-formed. (#10)

Use a profile to merge controls

Is this something that profiles need to be able to do?

If so, perhaps the merged control has a new title, while its old titles are demoted to p elements?

Are controls to be merged, called by ID? Does the new merged control have its own ID as well?

Does the merged control contain all the properties, parts and contents of the controls, which have been merged?

Can subcontrols or parts be merged? Can controls be merged with subcontrols, etc?

It might be argued that merging controls is precisely not what OSCAL should encourage, in which case the requirement should be placed far far away.

Render a framework in a human-readable format

As a compliance auditor, I can see a framework in a human-readable format.

Required Resources:

• A framework in a machine-readable OSCAL format (e.g., NIST CSF, PCI DSS)

Goals:

1. Create the necessary files (CSS, XSLT, etc.) to convert a machine-readable OSCAL framework into a human-readable format.
2. Test the conversion process using the selected framework.

Acceptance Criteria:

1. Validate that the necessary conversion files have been created as defined in Goal 1.
2. Validate that the conversion successfully generates the framework in a clear, human-readable format without conversion errors, omissions, etc.

Display a profile with parameters inserted

A profile lists controls and subcontrols to be included, and permits parameters to be set.

Produce a web page that shows all the controls included in a profile, with their parameter values injected ('transcluded') into their points of insertion.

Subcontrols that are not explicitly included, should not be shown, unless a runtime parameter is set to show all subcontrols in included controls. Controls that are not included, should not be shown.

The HTML (web page) should have a directory or ToC to the included controls; the ToC should give visual indicators of which controls contain dynamically inserted values, which should also be highlighted inline. It does not, however, have to represent the controls in the same arrangement in which they appear in source catalog(s). It does have to be able to handle a profile that calls multiple catalogs.

JSON data sources as well?

Hi All,

Are we also going to have JSON data sources for the 800-53 r4/5 and others in alignment with the XML?

Thanks,

Aaron

Set parameter values for controls within the context of the union of multiple profile standards

User Story Candidate: As a compliance auditor, I can set parameter values for controls within the context of the union of multiple profile standards [standards TBD].
Required Resources:

• Standards TBD
  Goals:

1. TBD
   Acceptance Criteria:
2. TBD

Stabilize schema and maintenance model

The core schema is now in RNC but developers will want a stable XSD.

We need to build and use, at least once, a bridge. The XSD produced by Trang looks good. An XSLT stylesheet can be applied that injects documentation for use by tools. Both these steps could potentially be run in an XProc or "by hand" in oXygen.

The documentation injection XSLT can also take responsibility for schema boilerplate that needs to be added to the schema Trang produces from our upstream source. (Note however that Schematron rules will not be injected, at least for now.)

Merge Sprint 3 branch into Master and Create Sprint 4 Branch

Setup the Sprint 4 branch for work on Sprint 4.

Build a profile that works by exclusion

A profile can include all the controls in a catalog, or it can select specific controls (and subcontrols) by ID.

How about if a blacklist were provided instead of an included list? Include all controls except IDs X, Y and Z.

This is currently modeled and implemented in a prototype but it hasn't been tested. If it is a requirement, it should be tested. If it is not a present or foreseeable requirement, perhaps the model should be rolled back (so future implementations don't have to support it either).

Tidying up naming convention for schema files

Would be great to come up with a solid naming convention for schema files. For example, the OSCAL core schemas, oscal-documented.xsd and oscal-working.rnc, could probably be better named oscal-core.xsd and oscal-core.rnc.

Define scope of next demo(s)

There are a couple of different directions we could go with our next demonstrations:

• Focus on SP800-53, customization and tailoring including parameter management and insertion
• Focus on demonstrating "merge/overlay" capabilities in profiling across catalogs
• Focus on modeling/mappings into OSCAL (more examples?)
• Focus on production/emulation e.g. new views or analytics; PDF stylesheets; "facsimile renderings" of a range of catalog formats etc. etc.
• (More?)

Potential issues: accessibility of data sets; (de)obfuscation of ISO 27002

Define CI/CD process and workflow

Using this as a starting point for discussion on a CI/CD workflow for automated testing and artifact generation/deployment. Initial thoughts below:

• Define high-level overview of CI/CD process and include this as part of a CONTRIBUTING.md or BUILD.md file
• Determine which items could be rolled up under automated testing
  • Validation of OSCAL-formatted XML against XSD/RNC
  • Validation of OSCAL-formatted XML against Schematron
  • Validation of OSCAL-formatted JSON against JSON schema
• Determine which items could be rolled up under automated artifact generation
  • Conversion of RNC to XSD via Trang
  • Conversion of non-OSCAL XML to OSCAL-formatted XML artifacts via XProc and Calabash
  • Conversion of OSCAL-formatted XML to JSON
• Determine who/what is responsible for automated artifact generation (e.g. CI/CD system vs. individual who executes automated tools locally and manually creates PRs with auto-generated artifacts)
• Select a CI/CD system (e.g. Travis CI, CircleCI, etc)

Param as a child element of call in profile schema

In oscal-profile-working.rnc, would it not make more sense to define param elements as children of call elements? Or does one envision a scenario where a param would be associated with an id not referenced by a call in the same profile?

import relationships between core, common, and extension schemas

I'm confused about the respective roles of the "core" and "common" schemas. If I understand the PowerPoint slides correctly, "core" definitions are globally applicable whereas "common" definitions apply to some, but not all, extensions.

However, the "core" schema imports the "common" schema. Why is this the case?

Unless I'm missing something, it would make more sense to me if "core" did not import
common". Then all extensions would could"core", and extensions wishing to leverage the "common" definitions could also import "common"

Organize the documentation

As a content or tool developer, I can find well-organized information containing an overview of OSCAL's purpose, benefits, and uses; the high-level OSCAL architecture and components; and the composition of OSCAL's catalog schema.

Required Resources:

• Text and graphics on OSCAL's purpose, benefits, and uses; high-level OSCAL architecture and components; and the composition of OSCAL's catalog schema

Goals:

1. Plan how the documentation should be organized and reach core team consensus on the plan.
2. Implement the plan so all documentation is clearly structured and linked together using formats such as HTML and Markdown that can import cleanly into Word, Powerpoint, and/or other appropriate production platforms.

Acceptance Criteria:

1. Validate that all documentation is included in the new organization scheme and no content is unnecessarily duplicated.
2. Be ready to share the reorganized documentation with Fred, Jaafar, and the tiger team for review.

Add support for profile tailoring

Goals:

1. A user can extend an existing profile to create a new profile
2. A user can choose which controls from a given catalog are excluded from a profile (already done, but needs to be tested). If an extended profile, this should allow controls in the extended profile to be excluded. #34
3. A user can modify existing statements for a control included in the profile. #37 The changes made to a control in this way must be discernible. #16
4. A user can set a value for a parameter for a control included in the profile. #14
5. Multiple catalogs must be supported for inclusion of controls.

Dependencies:

• Existing control catalogs defined for SP 800-53, ISO/IEC 27001/2, COBIT 5
• Parameters will be used from the SP 800-53 catalog
• Need a spreadsheet or equivalent content documenting the FedRamp "moderate" baseline

Acceptance Criteria:

1. A mockup is produced demonstrating implementation of the FedRamp "moderate" baseline that uses profile extension and tailoring features described above (goals 1-4).
2. A mockup is produced demonstrating implementation of a profile supporting multiple source catalogs used as a basis for a tailored profile. This should include use of all features described above (goals 1-5).
3. A stylesheet is produced that supports rendering a human-readable view of the profile. The stylesheet will be used with the mockups from items 1 and 2 above.

Cleanup Issues

Goals:

1. Characterize issues as enhancements, bug fixes, questions, etc.
2. Remove duplicate issues,
3. Mark issues that are user stories as such.
4. Pre-assign LoE for group discussion (Dave's vote).
5. For user stories, describe goals and acceptance criteria.

Acceptance Criteria:

1. All issues submitted by September 22 have been reviewed and characterized based on the above goals.

pull requests

Would you prefer that contributors of example OSCAL instances use GitHub's pull request mechanism to do so? I think this makes sense particularly for examples that require modifications to the schemas in order to validate.

Display the delta between controls

User story candidate: Show delta between controls
Required resources:

• TBD
  Goals:

1. TBD
   Acceptance Criteria:
2. TBD

Address the NIST SP 800-53 Revision 5 draft

Address the NIST SP 800-53 Revision 5 draft.

Change default GitHub branch to `master`

As a collaborator, I want to implicitly know the working branch. Request to change settings default branch to https://github.com/usnistgov/OSCAL/tree/develop

re: #1 (comment)

Schematron Quickfix requirements (parameters)

At present, the Quickfix for adding a parameter for a loose assignment asks for a value.

Correct this so the user can use this without providing a value.

There are related requirements regarding setting of default values instead, etc.

Rectifying ID format in SP800-53 rev4 extraction

XML IDs must follow some arcane naming rules inherited from SGML (and shared with HTML). These include rules such as no punctuation apart from . and _. No brackets, parentheses etc.

Consequently, the auto-extracted SP800-53 (rev4) has some odd ID syntax, where IDs have been interpolated for components (parts) with formal identifiers (name properties) such as SA-15 (4)(a). The syntax presently is a very ad-hoc reduction intended only to maintain uniqueness, in this case s_smm_sa-15.4.a. because it is sa-15.4.a as a statement subitem inside a subcontrol.

As long as IDs are kept behind the scenes this is okay. But if IDs are to be a "public face" of even granular components inside controls, we could probably develop a better cleaner mapping (which we could install into the current extraction pipeline).

Community Slack channel or forum?

Are there plans to spin up a community discussion channel (i.e. Slack) or some sort of forum? May not want to necessarily bog down the GitHub issues list for general discussion threads.

Unit tests for Schematrons

So far we have been validating Schematron functionality as we go.

Thorough regression testing requires that we can demonstrate not only that valid documents pass appropriate Schematron checks, but also that erroneous cases fail Schematrons "correctly" (no-go tests), while valid edge cases pass them (go tests).

We could do this less formally (less overhead) with simple examples (real and pathological) or more formally (more effort but easier to run) with XSpec-for-Schematron -- which would also permit us to enumerate and document the requirements they address and even push them out into Markdown for the Github repo. See https://github.com/xspec/xspec.

Use a profile to patch controls

A profile represents controls to be included from a catalog, and parameter values to be inserted into the controls in question.

Can a profile also perform more drastic interventions, such as supplementing the contents of controls? Or suppressing or replacing contents? Specific properties, paragraphs or parts may be known in advance, addressable and hence replaceable.

Can new contents include insertions that imply parameters, which must also be provided?

Distinguish implementer/end user and maintainer documentation

As an implementer/end user or a maintainer, I can find well-organized information on how I can use OSCAL.

Goals:

1. Plan how the existing documentation should be reorganized and reach core team consensus on the plan.
2. Implement the reorganization plan so all documentation clearly indicates the target audience.
3. Identify missing pieces of documentation on OSCAL use, such as walking end users through basic document creation or explaining to more advanced users how to generate prose from OSCAL content.
4. Create missing pieces of documentation on OSCAL use in Markdown format that can import cleanly into Word, Powerpoint, and/or other appropriate production platforms. Ensure each document clearly indicates the target audience.

Acceptance Criteria:

1. Validate that the documentation has been reorganized in accordance with the plan.
2. Validate that the new documents have been created and their contents are accurate and concise.
3. Be ready to share the new and revised documentation with Fred, Jaafar, and the tiger team for review.

Design an OSCAL approach for mapping to security frameworks (e.g., NIST Cybersecurity Framework)

https://gist.github.com/JJediny/65438415b5e38ac7560ad5f5597f1877

How do these efforts currently relate?

Document the composition of the profile schema and how it relates to the catalog schema

User story candidate: As a content or tool developer, I can find clear, concise, and accurate information on the composition of OSCAL’s catalog and profile schemas and how they relate to each other.

Required Resources:

• Stable OSCAL catalog schema
• Stable OSCAL profile schema
• Feedback on original OSCAL catalog schema documentation

Goals:

1. Produce a profile schema with embedded documentation (usable by tools).
2. Make documentation of the profile schema tag set accessible in the GitHub repository.
3. Make the profile schema tag set documentation available in multiple formats, to include HTML and Markdown, that can import cleanly into Word, Powerpoint, and/or other appropriate production platforms.
4. Document the high-level conceptual description and description "tags" (elements) for the profile schema in OSCAL.
5. Make any needed revisions to the catalog schema, catalog schema tag set documentation, and documentation of the high-level conceptual description and description tags for the catalog schema.

Acceptance Criteria:

1. Validate that profile schema documentation can be made available when working with OSCAL in oXygen.
2. Validate that documentation on the profile schema tag set is online and available in GitHub.
3. Validate that the same catalog and profile documentation appears in HTML and Markdown formats.
4. Verify that the contents of the catalog and profile schema documents make sense.
5. Verify that all catalog and profile schema element descriptions are accurate and concise.
6. Be ready to share the catalog and profile schema documentation for review by interested parties (tiger team, Fred, Jaafar).

Gather feedback on Sprint 3 documentation

Goals:

1. Specific channels are identified by which the the tiger team and NIST reviewers can provide feedback (e.g., mailing lists, email aliases, github issues, etc).
2. The documentation created in Sprint 3 is reviewed and comments are addressed. Comments will be aggregated and triage.

Acceptance Criteria:

1. Tiger team members and other reviewers are subscribed to the [email protected] mailing list.
2. Clear review instructions are developed and sent to reviewers by 9/8, allowing 2 weeks for reviews to be completed (9/22).
3. A list of comments is developed and issues are triaged.

JSON schema

We should include a JSON schema as well.

Tracking WIP in #6

Further validations on profiles

We currently have validation logic that checks a profile to ensure that all controls, subcontrols and parameters referenced, correspond to elements of the same type with the same ID value, in the catalog in which they appear.

There are a couple of more refined validations we might also want:

• Validate that any controls included in the profile that have parameters (in the catalog), have the 'same' parameters in the profile
• Same for points of insertion in the catalog - included controls do not have insert elements that don't have corresponding parameters. (Note this is a warning inasmuch as controls can provide default values for parameters so a profile not including one, is not actually an error.)
• Validate that parameters named in the profile, are used (actually inserted) in controls included in the profile

Alternatively/additionally, maybe a "cleanup" transformation would insert parameters needed, and remove parameters not needed, in the included controls.

Documenting declarations model

The declarations model, whereby an OSCAL catalog developer can stipulate certain constraints over OSCAL data to be checked (validated) externally, is an optional feature of OSCAL. It remains to be seen whether it will prove to be useful to developers of catalogs or profiles. However, in principle it may be useful, if only as a demonstration of how implementors and developers of OSCAL applications (not to say "users") may wish to structure, regularize and document (expose) controls through the use of external "contracts" (constraint sets) of this form or some other. (Basically, the declarations model represents a way of extension-through-restriction, or subsetting, something achievable in a number of ways.)

Suggestion: we edit oscal-oscal.xml to make it clear that OSCAL can be used without the declarations model (that is, without making or using declarations) and that the functionality provided by OSCAL declarations can also be provided by other means. (And indeed that an application might wish for such extra validations in any case since the declarations model doesn't do everything either.)

Also, in explaining the declarations model, examples will be extremely helpful, and we have examples of declarations for all our samples so far, plus oscal-oscal.xml itself. The documents describing the mappings of each of the reference documents into OSCAL should also describe how the declarations work in each case.

GSA's FEDRAMP - Public Comments on NIST-800-53 rev5

18F/tts-public-comments#23

Namespace update

The namespace now assigned to OSCAL elements, http://scap.nist.gov/schema/oscal, doesn't conform with current guidelines (I am told) for NIST namespaces. It is essentially a placeholder.

What will the namespace of OSCAL be?

Update Markdown and add structure to Table of Contents

Need to update Markdown and add structure to Table of Contents (render TOC as a set of headers). Perhaps use capabilities in Jeckyll (sp?) to address structure issue.

Define mechanisms for framework customization

As a compliance auditor, I can customize a framework by choosing which parts of the framework are included, modifying the framework, and extending the framework.

Required Resources:

• A framework in a machine-readable OSCAL format (e.g., NIST CSF, PCI DSS)

Goals:

1. A user can extend an existing framework to create a new framework.
2. A user can choose which parts of a given framework are included or excluded.
3. A user can modify existing parts of a given framework.

Acceptance Criteria:

1. A mockup is produced demonstrating implementation of a framework that uses framework extension and tailoring features described above (goals 1-3).

overlays versus tailored baselines

It seems to me that OSCAL assumes that all 800-53 tailoring is done in the form of overlays. If my assumption is correct, I would suggest modifying the schemas so that instances can be created that represent a tailored baseline without all the overhead and formality of an overlay.

Back when I showed an early version of Baseline Tailor to Ron Ross and Kelley Dempsey, they told me that the vast majority of 800-53 users are looking to tailor one of the three baselines. They are generally not interested in creating overlays. I admit I don't fully understand how much this is about "branding" versus semantics. Maybe it would be sufficient to have a tailored-baseline element, and then have "overlay" be a collection of tailored baselines plus metadata adding the necessary formality that 800-53 recommends for overlays.

Define a machine-readable framework format

As a content or tool developer, I can define frameworks in a common machine-readable OSCAL format.

Required Resources:

• Two frameworks in machine-ingestible formats (e.g., NIST CSF text, PCI DSS text)

Goals:

1. Create an OSCAL instance document for two frameworks.
2. Create XSD for framework content validation purposes.
3. Create Schematron to validate framework-specific requirements.
4. Create CSS/XSLT for human readability and data entry.
5. Test both frameworks using the CSS for data entry into oXygen using Author mode.

Acceptance Criteria:

1. Validate that the OSCAL instance documents have been created as defined in Goal 1.
2. Validate that all framework information from the sources was transformed (no loss of information).
3. Validate that all information types common to both frameworks are formatted the same way.
4. Evaluate Schematron to ensure framework-specific requirements have been included.
5. Evaluate CSS/XSLT for human readability/data entry.
6. Validate that textboxes, pick lists, etc. work as defined in the oXygen interface.

Merge Sprint 4 into master and create Sprint 5 branch

Merge Sprint 4 into Master
Create Sprint 5 branch

Clean up outstanding issues

User Story
As an OSCAL Contributor, I can enter an issue into GitHub which will be subject to a NIST OSCAL issue resolution process.

Goals

• Design and document an issue resolution process
• Create an issue template

Dependencies

• Old issues need to be closed prior to the implementation of this issue resolution process
  • Some issues have already been tagged as "closable" and need to be closed by NIST personnel

Acceptance Criteria

• Verify that an Issue Resolution Process exists and has been tested by the NIST OSCAL team
• Verify that an issue template has been created and reviewed

Refine SP800-53 OSCAL extraction and enhancement

The current copy of SP800-53/53A, in OSCAL, is produced programmatically by XSLT running over the NVD XML, which maps its XML format. Results are consistent but could use further enhancement, if not by extending the XSLT then by post-process. Requirements include:

• Address duplication of 'withdrawn' data e.g. AC-13
• Infer and tag links between controls
• Infer and tag parameter assignments and parameter defaults
• Infer and tag "withdrawn" entries
• Add ID attributes everywhere
• Add a few 'number' properties missing but implicit in the source (e.g. on top-level 'objective' features) - cross-check the data for this
  • Clean correct complete data will support strong OSCAL declarations e.g. of inherited number assignments across controls, subcontrols and (certain) features

An earlier iteration of an XSLT for (some of) this is in lib/OSCAL-adjust.xsl.

Once this is done, the method for producing SP800-53 XML in OSCAL (the entire chain) should be documented and the results validated by close review.

In this process we may also identify needs for manual enhancement.

Explore BaseX as a demo platform

So far, we have run processes only in oXygen XML editor, or in some cases (for viewing XML) in an XSLT 1.0 processor in the web browser. (Some but not all browsers will support this without special settings.) Neither of these work directly under Github; so Github visitors cannot try them without downloading files and following expert-level instructions.

For further demonstrations, it would be good to get away from both an oXygen dependency, and the limits of XSLT 1.0 (a 1998 technology) -- especially given that we have several other options including open source options. Maintaining something under Github that can also be up and running somewhere (as a live demo) is better than maintaining something there, without giving visitors a chance to try it.

One option is an XML database such as BaseX, run as a web server. Advantages to BaseX:

• We can deliver demos over the web that require nothing but old-fashioned browsers to run
• BaseX is performant and capable of doing everything we need regarding profiling, selection, qualification, parameter injection, etc etc in layered MVC architecture
• RestXQ interfaces are sweet: basically a URI call is translated into XQuery in back
• It's pure XML/XQuery, all XDM inside, dovetails well with XSLT
• BaseX can integrate Saxon, which gives us XSLT 3.0 (this is huge)
• Runs under Maven

Disadvantages:

• We'd have to run it somewhere (in the cloud?) for the demos to work on the open Internet. If we wish to restrict access, this complicates things further.

There are other XML databases that could conceivably work well also but I think BaseX is an especially good fit. (I am not quite proposing a platform for an implementation. But we do need something more capable and more accessible for demonstrations.)

Update CSS to allow user-definable scaling

Future User Story: Would be useful to update CSS to allow scaling to be user-definable.

Refine content to create Pages in GitHub

Work to do once we have better documentation:

1. Create a branch named "nist-pages".
2. Move content to that branch.
3. Setup a webhook to publish to: https://pages.nist.gov/deploy

Goals:

Provide a useful collection of OSCAL documentation on https://pages.nist.gov that: 1) explains the concepts comprising OSCAL, 2) provides documentation on how to use OSCAL, and 3) decribes how to create and use the example catalogs and profiles we have created, and 4) describes how to create new content using OSCAL.

Acceptance Criteria:

• Verify that the site is deployed to https://pages.nist.gov
• Validate that the site provides documentation that addresses the goals above.

Add a "review" user story for Josh Lubell

Generate examples leveraging OSCAL

As a new user of OSCAL, I can quickly find on GitHub simple, well organized and relevant examples of how to represent a control catalog and profile in OSCAL.

Goals:

• Provide a complete catalog for 800.53 rev 4
• Provide examples of FedRAMP low, moderate and high baselines as catalog profiles based on these linked spreadsheets on FedRAMP.gov
• Develop both XML and JSON representations of the above
• Update documentation to direct visitors to these examples

Acceptance Criteria:

• Complete draft of all examples are provided under an examples folder in GitHub
• All examples validate according to OSCAL schema
• Top level and example readme files are created/updated to point users toward appropriate examples

Versioning mechanism for OSCAL schemas

Not sure if this has already been solidified. Using this as a starting point for a discussion on an appropriate versioning mechanism for all OSCAL schemas. Some thoughts below:

• Leverage existing revisioning approach (thinking in terms of Special Publication revisions)
• Take traditional semantic versioning approach
• Timed releases (e.g. month.year)

Add features such as frameworks and customizations

Future User Story: We need to consider features such as frameworks, customizations, text replacement, etc. Perhaps create a style sheet representing a pseudo catalog showing all controls that are called including any sub-controls that are included and inject the modeled replacements.

Create a testing framework to validate regressions

User story candidate: Create a testing framework to validate regressions.
Required resources:

• TBD
  Goals:

1. TBD
   Acceptance Criteria:
2. TBD