Describe the bug

The JSON representation of baseline profiles only contain XML rlinks (example) for the catalog back-matter resource.

There should be an rlink to a JSON representation of that catalog with an application/oscal.catalog+json media type (example with a currently incorrect extension due to reported issue).

Who is the bug affecting?

Anyone using JSON representations of baseline profiles.

What is affected by this bug?

The ability to resolve catalog controls for baseline profiles.

When does this occur?

Always

Describe the bug

I am not 100% certain this is intentional or not, but when converting the FedRAMP OSCAL Registry from Excel to XML:

• FedRAMP Values are enclosed in <fedramp-values/>
• FedRAMP Threats are enclosed in <fedramp-threats/>
• FedRAMP Information Types are enclosed in <infomation-types/>

Is this intentional?

Who is the bug affecting?

Ongoing validation tooling in the medium-term future, but not currently impacting me at this time, potentially not others as well.

What is affected by this bug?

N/A

When does this occur?

N/A

How do we replicate the issue?

Review files in Github

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

Expected behavior (i.e. solution)

Consistency in the trees being prefix with FedRAMP, unless otherwise needed.

Other Comments

N/A

I noticed that in several FedRAMP profiles, in the profile's metadata, the role id for the document creator has been misspelled parpared-by, not prepared-by. This has propagated into exports into JSON and YAML versions (for FedRAMP Low and FedRAMP LI-SaaS). As for FedRAMP Moderate, it only shows in the JSON.

https://github.com/GSA/fedramp-automation/search?q=parpared-by

Action Item

This is a ...

• fix - Something needs to be different.

This relates to ...

• Other

Describe the problem or enhancement

This is a follow-on for ongoing development effort for the NIST OSCAL CI/CD to address ongoing work that was not complete for #103.

Goals:

When common document instances are converted between XML and JSON and YAML in the NIST OSCAL CI/CD system, file paths are presumed to be similar and then extensions are switched out by a perl-based regex that does the file extension substitution. This has broken for a period, which led to the linked issue and relevant issue for the NIST OSCAL content repo, usnistgov/oscal-content#59.

Dependencies:

None

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.

• This is a ...

  • concern - I think something needs to be different.
  • question - I didn't understand something.
  • kudos - I found something helpful and want to encourage it in future FedRAMP publications.
  • request - I would like to see something additional provided.

• This relates to ...

  • the FedRAMP OSCAL Registry (Excel File)
  • the Guide to OSCAL-based FedRAMP Content (PDF)
  • the Guide to OSCAL-based FedRAMP System Security Plans (SSP) (PDF)
  • the Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP) (PDF)
  • the Guide to OSCAL-based FedRAMP Security Assessment Reports (SAR) (PDF)
  • the Guide to OSCAL-based FedRAMP Plan of Action and Milestones (POA&M) (PDF)
  • the FedRAMP SSP OSCAL Template (JSON or XML Format)
  • the FedRAMP SAP OSCAL Template (JSON or XML Format)
  • the FedRAMP SAR OSCAL Template (JSON or XML Format)
  • the FedRAMP POA&M OSCAL Template (JSON or XML Format)
  • General/Overall
  • Other

NOTE: For feedback related to the OSCAL syntax itself, please create or add to an issue in the NIST OSCAL Repository.

• Where, exactly?
  • For the registry, please indicate the tab and cell, or other clear identifier
  • For the guide, please indicate the section number and printed page number (lower right corner)
  • For the OSCAL XML or JSON files, please indicate XML or JSON; and indicate the line number, field id, or other clear location identifier

Section 4.5 page 13 Digital Identity Determination

Properties (OSCAL <prop>)

• security-eauth-level
• identity-assurance-level
• authenticator-assurance-level
• federation-assurance-level

• What is your feedback?

The assurance level property values indicated (i.e., 1, 2, 3) are not the same parlance as that used in SP 800-63.

The initialisms used in SP 800-63 are

• IAL1, IAL2, IAL3
• AAL1, AAL2, AAL3
• FAL1, FAL2, FAL3

Those are the most likely to be recognized rather than the disembodied "1", "2", "3".

• What version of OSCAL are you using? (Check our info on supported OSCAL versions)

1.0.0

• What action would you like to see from the FedRAMP PMO?

Use SP 800-63 parlance for assurance level values.

Action Item

This is a ...

• enhancement - Something could be better.

This relates to ...

• the Modeling a FedRAMP SSP in OSCAL Guide (PDF)
• the FedRAMP SSP OSCAL Template (JSON Format)
• the FedRAMP SSP OSCAL Template (XML Format)

Describe the problem or enhancement

The OSCAL syntax currently lacks the ability to capture document revision history.
NIST recognizes this and intends to add revision history to the syntax under metadata, making it available for all OSCAL files.

Goals:

Once NIST solidifies the syntax for document revision history, the Guide to OSCAL-based FedRAMP System Security Plans must be updated, along with the FedRAMP SSP OSCAL Templates.

Dependencies:

usnistgov/OSCAL#587

Acceptance Criteria

• NIST OSCAL Revision History Syntax and Documentation Published
• All FedRAMP Documents Related to OSCAL Adoption 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.

Other Comments

None.

Describe the bug

There is a slight mismatch between the example SSP's statement IDs (/system-security-plan/control-implementation/implemented-requirement/statement/@id by XPath) and how they ought to be assigned and match the corresponding IDs in the resolved catalog profiles. Per conversation here, this appears to be a minor issue in the example SSP, and the upstream OSCAL Metaschema models & schema, either M3 or M4, and example Rev4 and Rev5 content in oscal-content suggest this is the case.

This is a minor cosmetic fix but is useful for testing SSP validations, so I will surface this hear upstream as well.

Who is the bug affecting?

10x team that is writing validations against the examples SSPs as canonical test data.

What is affected by this bug?

See 18F#22 for more details.

This was detected analyzing updates with/for #44.

When does this occur?

Validations attempting to match lettered response points do not match because of the minor disparity in @id.

How do we replicate the issue?

Compare a resolved catalog profile and grep or search for differences between profile stmt. infix and appropriate smt. infix.

Expected behavior (i.e. solution)

That /system-security-plan/control-implementation/implemented-requirement/statement/@id match profile lettered response point FedRAMP extension declarations (/catalog/group/control/part/part[prop[@name='response-point']]/@id) for proper validation.

Other Comments

{Add any other context about the problem here.}

Action Item

This is a ...

• enhancement - Something could be better.

This relates to ...

• the FedRAMP OSCAL Registry (Excel File)
• the Guide to OSCAL-based FedRAMP Content (PDF)
• the Guide to OSCAL-based FedRAMP System Security Plans (SSP) (PDF)
• the Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP) (PDF)
• the Guide to OSCAL-based FedRAMP Security Assessment Reports (SAR) (PDF)
• the Guide to OSCAL-based FedRAMP Plan of Action and Milestones (POA&M) (PDF)
• the FedRAMP SSP OSCAL Template (JSON or XML Format)
• the FedRAMP SAP OSCAL Template (JSON or XML Format)
• the FedRAMP SAR OSCAL Template (JSON or XML Format)
• the FedRAMP POA&M OSCAL Template (JSON or XML Format)

Describe the problem or enhancement

Upon review of drafts of FedRAMP OSCAL-Based file guides, it would be prudent to show a more detail example of attachments, as alluded to in the drafts, but a fuller example with an example ZIP archive and a representative file structure within, could be of potential benefit.

Goals:

Better examples of real-world use of attachments in FedRAMP OSCAL document instances.

Dependencies:

N/A

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.

Action Item

This is a ...

• fix - Something needs to be different.

This relates to ...

• the FedRAMP OSCAL Registry (Excel File)
• Other

NOTE: For issues related to the OSCAL syntax itself, please create or add to an issue in the NIST OSCAL Repository.

Describe the problem or enhancement

We need to add back the FedRAMP values file, in addition to the experimental FedRAMP Extensions variant proposed in usnistgov/OSCAL#825 were postponed from inclusion in the NIST OSCAL 1.0.0 release. In the meantime, in order ensure continued use of these values from FedRAMP, we will restore the FedRAMP values removed in 1b10de0.

Goals:

To allow interoperability and flexibility with approaches until a permanent solution is achieved, in unison with NIST OSCAL imrprovements in the constraint mechanism.

Dependencies:

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.

Action Item

This is a ...

• fix - Something needs to be different.

This relates to ...

• General/Overall

Describe the problem or enhancement

There are two significant concerns with FedRAMP's current approach of prescribing identifiers for content FedRAMP requires in OSCAL files:

1. This does not maximize cooperation with other compliance frameworks.
2. NIST is considering a change to OSCAL IDs that would require a UUID in most cases.

For both of the above reasons, FedRAMP must move away from the use of required identifiers, and provide a different machine-readable method for ensuring FedRAMP-required content is present. This new method must not use identifiers, and must co-exist with other frameworks within the same files.

For example, if a system must be authorized for FedRAMP, DoD, and ISO-27001/2, a single SSP should be able to support all three compliance frameworks simultaneously.

Goals:

• Release CSP, 3PAOs and tool developers from the burden of using specific identifiers for FedRAMP compliance items within OSCAL.
• Ensure a replacement mechanism can co-exist with other compliance frameworks.

Dependencies:

None

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.

Other Comments

None.

Describe the bug

Per the FedRAMP blog post update, we must update the SA-4 and IR-3 controls to match the recently updated FedRAMP SSP Templates in Microsoft Word DOCX formatting.

Who is the bug affecting?

All consumers of FedRAMP baselines and resolved catalog profiles from this official FedRAMP OSCAL profile source.

What is affected by this bug?

Any developer expecting the most current updates to match the recently published updates of the SSP templates in Word DOCX format.

When does this occur?

At all times.

How do we replicate the issue?

1. Clone this repository.
2. Download updated MS Word and Excel templates from the post and resources section.
3. Reference the data discrepancies.

Tracker issue for publication of guidance docs. Used to close outstanding issues awaiting documentation updates.

Closes #37.
Closes #39.
Closes #42.
Closes #102.

Describe the bug

Load fedramp data types JSON and validate against Oscal JSON Schema using AJV

Who is the bug affecting?

Anyone attempting to use fedramp info types json in an oscal oriented program

What is affected by this bug?

Standards are misconstrued. Nearly approaching OSCAL doesn't really provide the benefits as intended from OSCAL adoption.

When does this occur?

When Validating Fedramp infor types agains OSCAL informtation-type model

How do we replicate the issue?

{What are the steps to reproduce the behavior?

Load fedramp data types JSON and validate against Oscal JSON Schema using AJV

And See Validation error.

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

Expected behavior (i.e. solution)

Fedramp Info-types should validate as OSCAL information-types

Update baselines after NIST OSCAL announcement of 1.0.0 release and add developer documentation for following update procedure for future coordination with NIST development team.

Describe the bug

FEDRAMP-POAM-OSCAL-Template.json does not validate against oscal_poam_schema.json.

Who is the bug affecting?

All users of the FEDRAMP-POAM-OSCAL-Template.json file.

What is affected by this bug?

FEDRAMP-POAM-OSCAL-Template.json

When does this occur?

Occurs when you attempt to validate the file against the schema.

How do we replicate the issue?

Validate FEDRAMP-POAM-OSCAL-Template.json against oscal_poam_schema.json

Expected behavior (i.e. solution)

FedRAMP-POAM-OSCAL-Template.json should validate against oscal_poam_schema.json

Other Comments

None

Describe the bug

There is inconsistent application of XML namespaces and the OSCAL @ns attribute in the FedRAMP values documents still extant in the repository.

Who is the bug affecting?

This was surfaced by interactions with the 10x ASAP developer team @danielnaab and @GaryGapinski in the course of code review in these comments for ongoing development in 18F#91.

What is affected by this bug?

Proper processing of Schematron validation and Schematron/XSLT unit testing by other parties that dynamically process FedRAMP values statements on the fly.

When does this occur?

When using XSLT processing as mentioned above.

How do we replicate the issue?

1. Clone the 18F/fedramp-automation fork.
2. Checkout the branch in the above pull request and/or checkout code at commit 705d6d2.
3. Run the XSpec test harness and confirm similar errors like running the XSpec test harness here fail similarly.

Expected behavior (i.e. solution)

Clear delineation between FedRAMP values files' XML Namespace (xmlns) and the OSCAL @ns attribute for signifying extension fields.

Other Comments

None at this time.

Action Item

Establish the use of Architectural Decision Records.

This is a ...

• fix - Something needs to be different.
• ✔️ enhancement - Something could be better.
• investigation - Something needs to be investigated further.

This relates to ...

• ✔️ Other

NOTE: For issues related to the OSCAL syntax itself, please create or add to an issue in the NIST OSCAL Repository.

Describe the problem or enhancement

Lack of clarity around key around technical design decisions and how they impact how others will use this work.

Goals:

Document important decisions around projects in this repository, especially to communicate technical design assumptions to downstream customers of code and artifacts here.

Dependencies

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.

Other Comments

Describe the bug

• Update baseline referenced in import-profile/@href URI pointing to outdated copy of baseline. (#121)
• Fix @ns attribute and perhaps registry items for attachments per FedRAMP OSCAL SSP guide.
• Issues with the response-point alignment, requires other fixes, not just in SSP, tracked in #108.
• An OSCAL developer following current guidance from the NIST OSCAL and FedRAMP guidance in documentation would set the security-sensitivity-level like so. (GSA/fedramp-automation/#122)
• Fix example SORN ID value that is awkward, even as an example, with the new prop syntax (<prop ns="https://fedramp.gov/ns/oscal" name="sorn-id" class="pta" value="[No SORN ID]"/>). (#125)
• Fix out of sync versions in baselines and templates before release. (#124)

<system-security-plan xmlns="http://csrc.nist.gov/ns/oscal/1.0"
   uuid="8c000726-ba93-480d-a221-8cb60df10c24">
  <metadata />
  <system-characteristics>
    <security-sensitivity-level>moderate</security-sensitivity-level>
  <system-characteristics>
</system-security-plan>

Per previous discussion, it should be this.

<system-security-plan xmlns="http://csrc.nist.gov/ns/oscal/1.0"
   uuid="8c000726-ba93-480d-a221-8cb60df10c24">
  <metadata />
  <system-characteristics>
    <security-sensitivity-level>fips-199-moderate</security-sensitivity-level>
  <system-characteristics>
</system-security-plan>

Who is the bug affecting?

Those using the documentation and reference examples to build their own OSCAL tooling and SSPs.

What is affected by this bug?

Current, clear, and exemplary use of OSCAL for SSP models.

When does this occur?

Always.

How do we replicate the issue?

Open the repository and review the examples.

Describe the bug

When enabling Github branch protection, this prevents the oscalbuilder automation user used by NIST and FedRAMP to automate validation and conversion of artifacts.

This is recommended for version control considerations with ATO in mind for GSA TTS ATO process (not specific to any sensitivity level), but will break our build process.

Who is the bug affecting?

FedRAMP CI/CD processes and organizational risk management and security engineering considerations.

What version of OSCAL are you using? (Check our info on supported OSCAL versions)

v1.0.0 pinned under current submodule.

What is affected by this bug?

FedRAMP Automation Team

When does this occur?

When FAT developers or 10x ASAP validation developers merge code, the subsequent automated artifact build will fail.

How do we replicate the issue?

1. Merge any pull request to master.

Expected behavior (i.e. solution)

The automated oscalbuilder process through Github Actions will not be rejected by branch protections.

• This is a ...

  • concern - I think something needs to be different.
  • question - I didn't understand something.
  • kudos - I found something helpful and want to encourage it in future FedRAMP publications.
  • request - I would like to see something additional provided.

• This relates to ...

  • the FedRAMP OSCAL Registry (Excel File)
  • the Guide to OSCAL-based FedRAMP Content (PDF)
  • the Guide to OSCAL-based FedRAMP System Security Plans (SSP) (PDF)
  • the Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP) (PDF)
  • the Guide to OSCAL-based FedRAMP Security Assessment Reports (SAR) (PDF)
  • the Guide to OSCAL-based FedRAMP Plan of Action and Milestones (POA&M) (PDF)
  • the FedRAMP SSP OSCAL Template (JSON or XML Format)
  • the FedRAMP SAP OSCAL Template (JSON or XML Format)
  • the FedRAMP SAR OSCAL Template (JSON or XML Format)
  • the FedRAMP POA&M OSCAL Template (JSON or XML Format)
  • General/Overall
  • Other: SSP-A04-FedRAMP-PIA-Template.docx

NOTE: For feedback related to the OSCAL syntax itself, please create or add to an issue in the NIST OSCAL Repository.

• Where, exactly?

  • For the registry, please indicate the tab and cell, or other clear identifier
  • For the guide, please indicate the section number and printed page number (lower right corner)
  • For the OSCAL XML or JSON files, please indicate XML or JSON; and indicate the line number, field id, or other clear location identifier

• What is your feedback?
  It in section 3.2 page 3, there are two Controls one embedded inside the other and in other cases, there are three or more document controls embedded inside each other.

Also, you should not give all the document controls the same Title or tag unless you intend it to repeat the same text from that control throughout the document. For example your Information System Name control.
To do this right and stop issues, remove the redundant Word Controls, and rename what is left behind as Explanation 1, Explination2, etc., then there are no issues. OR, just do all of us a favor and remove the Explanation document controls all together and format the cell left behind for text with italics.

• What version of OSCAL are you using? (Check our info on supported OSCAL versions)

• What action would you like to see from the FedRAMP PMO?

• Other information (e.g. detailed explanation, related issues, suggestions how to fix, links for us to have context, eg. slack, gitter, etc)
  It in section 3.2 page 3, there are two Controls one embedded inside the other and in other cases, there are three or more document controls embedded inside each other.

Also, you should not give all the document controls the same Title or tag unless you intend it to repeat the same text from that control throughout the document. For example your Information System Name control.
To do this right and stop issues, remove the redundant Word Controls, and rename what is left behind as Explanation 1, Explination2, etc., then there are no issues. OR, just do all of us a favor and remove the Explanation document controls all together and format the cell left behind for text with italics.

Also, if you are going to create a template, you should publish as a Word Template (*.dotx).

Per instruction of @zachbaldwin, update the FedRAMP Vendor Resource PDF.

This is a ...

• fix - Something needs to be different.
• enhancement - Something could be better.
• investigation - Something needs to be investigated further.

This relates to ...

• the FedRAMP OSCAL Registry (Excel File)
• the Guide to OSCAL-based FedRAMP Content (PDF)
• the FedRAMP OSCAL Vendor Resources (PDF)
• the Guide to OSCAL-based FedRAMP System Security Plans (SSP) (PDF)
• the Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP) (PDF)
• the Guide to OSCAL-based FedRAMP Security Assessment Reports (SAR) (PDF)
• the Guide to OSCAL-based FedRAMP Plan of Action and Milestones (POA&M) (PDF)
• the FedRAMP SSP OSCAL Template (JSON or XML Format)
• the FedRAMP SAP OSCAL Template (JSON or XML Format)
• the FedRAMP SAR OSCAL Template (JSON or XML Format)
• the FedRAMP POA&M OSCAL Template (JSON or XML Format)
• General/Overall
• Other

NOTE: For issues related to the OSCAL syntax itself, please create or add to an issue in the NIST OSCAL Repository.

Describe the problem or enhancement

Update document in response to vendor inquiries.

Goals:

See above.

Dependencies:

None.

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.

Other Comments

As a respondent to a new issue:

• it's often easier to delete options to select than it is to edit a checkbox in raw markdown, a note at the beginning to delete bullets not relevant is often easier to get right.:
  • editing to (in raw markdown - requires knowledge of markdown... to...
  • to indicate a selection, suggest asking users to delete whatever is not relevant to their submittal.
• Instead of using bold, use H3 or H4 in ### H3 #### H4 as it is visually cleaner to the respondent.
• for NOTE: suggest using >NOTE:
• other section e.g./example might be better to exclude and leave open-ended, as Additional Information.

Example of suggested fixes...

Please delete bullets/items not relevant to make a selection

This is a:

• concern - I think something needs to be different.
• question - I didn't understand something.
• kudo - I found something helpful and want to encourage it in future FedRAMP publications.
• request - I would like to see something additional provided.

This relates to:

• the FedRAMP OSCAL Registry (Excel File)
• the Modeling a FedRAMP SSP in OSCAL Guide (PDF)
• the FedRAMP SSP OSCAL Template (JSON Format)
• the FedRAMP SSP OSCAL Template (XML Format)
• General/Overall
• Other - Please edit

NOTE: For feedback related to the OSCAL syntax itself, please create or add to an issue in the NIST OSCAL Repository.

What is your feedback:

Specific comment on the Guidance?:

If so, please cite the document(s) and section(s):

• For the registry, please indicate the tab and cell, or another clear identifier
• For the guide, please indicate the section number and printed page number (lower right corner)
• For the XML and JSON files, please indicate the line number, field id, or another clear identifier

What action would you like to see from FedRAMP on this effort:

Additional Information:

Action Item

This is a ...

• investigation - Something needs to be investigated further.

This relates to ...

• General/Overall
• Other

NOTE: For issues related to the OSCAL syntax itself, please create or add to an issue in the NIST OSCAL Repository.

Describe the problem or enhancement

{A clear and concise description of the problem or enhancement.}

Goals:

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

Dependencies:

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

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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 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.}

Other Comments

{Add any other context about the problem here.}

Action Item

This is a ...

• enhancement - Something could be better.

This relates to ...

• the FedRAMP OSCAL Profiles and Catalogs (JSON or XML Format)

NOTE: For issues related to the OSCAL syntax itself, please create or add to an issue in the NIST OSCAL Repository.

Describe the problem or enhancement

Per vendor feedback, there needs to be better version information in the profiles in the /o:metadata/o:version field of the respective profiles and catalog. Currently, it is in our catalogs and baselines currently set to 1.3. Additionally, it is only apparent from the o:title field external file naming and directory structure that it is a 800-53 Revision 4 derived profile.

More investigation is needed to better accommodate metadata for downstream users to introspect the XML or JSON and know this information from the model data alone.

Goals:

Users have given feedback that they do not want to have to interpret version information and its relationship to 800-53B baselines (Rev 4 and Rev 5). Introspectable metadata would allow them to know this information without human interpretation and render it usable in programmatic analysis of catalogs and profiles as necessary.

Dependencies:

None known at this time.

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.

Other Comments

Tracking ticket for FedRAMP SSP Guide, Version 2 of August 1, 2020.

Action Item

This is a ...

• fix - Something needs to be different.
• enhancement - Something could be better. ✅
• investigation - Something needs to be investigated further.

This relates to ...

• the FedRAMP OSCAL Registry (Excel File)
• the Guide to OSCAL-based FedRAMP Content (PDF)
• the Guide to OSCAL-based FedRAMP System Security Plans (SSP) (PDF) ✅
• the Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP) (PDF)
• the Guide to OSCAL-based FedRAMP Security Assessment Reports (SAR) (PDF)
• the Guide to OSCAL-based FedRAMP Plan of Action and Milestones (POA&M) (PDF)
• the FedRAMP SSP OSCAL Template (JSON or XML Format)
• the FedRAMP SAP OSCAL Template (JSON or XML Format)
• the FedRAMP SAR OSCAL Template (JSON or XML Format)
• the FedRAMP POA&M OSCAL Template (JSON or XML Format)
• General/Overall
• Other

NOTE: For issues related to the OSCAL syntax itself, please create or add to an issue in the NIST OSCAL Repository.

Describe the problem or enhancement

When defining the recommended attachment approach in FedRAMP Guides for OSCAL, the recommended rlink strategy for only the authorization boundary is specified. The nature of CORS for remote HTTP and HTTPS access would make recommending o:rlink resources not embedded in the SSP increasingly difficult to validate in a minimal way using XSLT alone.

More context on this issue is summarized after technical review with 10x developers summarized in Github issue 18F#74.

Goals:

Make usable, achievable criteria for attachment validation in a platform-agnostic way more explicit in FedRAMP Guidance for OSCAL documents.

Dependencies:

None.

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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 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.}

Other Comments

N/A

Action Item

This is a ...

• enhancement - Something could be better.

This relates to ...

• General/Overall

Describe the problem or enhancement

FedRAMP has an excel spreadsheet with applicable laws, regulations, standards, and guidance. This should be converted to OSCAL back-matter citation syntax to better enable tools to access it.

Goals:

Convert the FedRAMP Laws and Regulations file to OSCAL.

Dependencies:

None

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.

Action Item

This is a ...

• enhancement - Something could be better.

This relates to ...

• Other

NOTE: For issues related to the OSCAL syntax itself, please create or add to an issue in the NIST OSCAL Repository.

Describe the problem or enhancement

Make use of Github groups to manage repos and assign tickets using our issue templates.

Acceptance Criteria

• An admin group to maintain user ownerships.
• A group for developers with write privileges.
• Documented audit proceedures in the repository.

Hello,

It seems that some of the files here are no longer valid OSCAL (assuming latest head of https://github.com/usnistgov/OSCAL is correct). Not only set/set-param issues needs to be fixed.

It seems that @id parameter on the root element needs to be reformatted as well. Seems that uuid- prefix is missing.

I am getting following errors, when trying to validate GSA files:

./baselines/xml/FedRAMP_MODERATE-baseline-resolved-profile_catalog.xml:2: element catalog: Schemas validity error : Element '{http://csrc.nist.gov/ns/oscal/1.0}catalog', attribute 'id': '7723d8ef-9667-4ae5-8316-0ce2d81a67d0' is not a valid value of the atomic type 'xs:NCName'.
./baselines/xml/FedRAMP_MODERATE-baseline-resolved-profile_catalog.xml fails to validate

./baselines/xml/FedRAMP_HIGH-baseline-resolved-profile_catalog.xml:2: element catalog: Schemas validity error : Element '{http://csrc.nist.gov/ns/oscal/1.0}catalog', attribute 'id': '0a8a1cf0-d22d-4a80-9f57-08483cdd6f37' is not a valid value of the atomic type 'xs:NCName'.
./baselines/xml/FedRAMP_HIGH-baseline-resolved-profile_catalog.xml fails to validate

./baselines/xml/FedRAMP_LI-SaaS-baseline-resolved-profile_catalog.xml:2: element catalog: Schemas validity error : Element '{http://csrc.nist.gov/ns/oscal/1.0}catalog', attribute 'id': '8b898586-6ae4-4685-8e32-600755fe556b' is not a valid value of the atomic type 'xs:NCName'.
./baselines/xml/FedRAMP_LI-SaaS-baseline-resolved-profile_catalog.xml fails to validate

Reproducer

I used my own version of oscalkit, as that's easiest to use:

   for f in `find | grep '\.xml$'`; do oscalkit validate $f; done

Nevertheless, the errors can be reproduced using any XSD validator with latest schemafiles from oscal

NOTE: For feedback related to the core OSCAL syntax itself, please create or add to an issue in the NIST OSCAL Repository.

Please delete bullets/items not relevant to make a selection

This is a:

• concern - I think something needs to be different.
• question - I didn't understand something.

This relates to:

• the FedRAMP OSCAL Registry (Excel File)
• the Guide to OSCAL-based FedRAMP System Security Plans (PDF)
• the FedRAMP SSP OSCAL Template (JSON Format)
• the FedRAMP SSP OSCAL Template (XML Format)

Specific Location

The guidebook and template are missing details for specifying the primary and alternate data center locations. This information is usually provided "free form" in section 10 of the FedRAMP templates.

What action would you like to see from the FedRAMP PMO on this issue:

FedRAMP should clarify the syntax for defining data center locations in a machine-readable format. This will better enable automation of SAP development.

Once defined, this information should be added to the Guide to OSCAL-based FedRAMP System Security Plans, and example syntax/content added to the FedRAMP OSCAL Template.

Additional Information:

FedRAMP is in discussion with NIST about this issue. There is currently no clean way to provide this data in a machine-readable format.

NIST is considering changes to the document metadata syntax (for all OSCAL layers/models), which will allow locations to be identified separate from people or organizations.

Action Item

This is a ...

• enhancement - Something could be better.

This relates to ...

• the Guide to OSCAL-based FedRAMP System Security Plans (PDF)
• General/Overall

Describe the problem or enhancement

Currently OSCAL is designed to be complete. This means it is difficult to just provide OSCAL-based inventory data outside the context of a complete OSCAL-based SSP file.

NIST is currently working on an approach that provides OSCAL content authors the ability to represent just a portion of an OSCAL file, while still enforcing OSCAL syntax and allowing format conversion.

Once NIST has solidified their approach to OSCAL file fragments, the FedRAMP guide will be updated.

Goals:

Establish clear guidance for FedRAMP stakeholders to extract OSCAL-based inventory information from a larger OSCAL-based SSP, such that the inventory representation is standardized across FedRAMP stakeholders while retaining OSCAL compliance.

Ensure FedRAMP's guidance updated when NIST publishes this change as part of the OSCAL 1.0.0-milestone3 Release later this year.

Dependencies:

usnistgov/OSCAL#590

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.

Other Comments

None.

Action Item

This is a ...

• enhancement - Something could be better.

This relates to ...

• the FedRAMP OSCAL Registry (Excel File)
• FedRAMP Baselines

Describe the problem or enhancement

Create a mechanism that indicates the FedRAMP-required response points for each control within the FedRAMP baselines, such that a tool reading the FedRAMP baseline (profile) is able to "know" which statement parts to present to SSP authors.

For example, with 800-53 Revision 4, FedRAMP currently requires responses at the following statement parts:

• part a, part b.1, and part b.2 for all -1 controls (AC-1, AT-1, etc.)
• lettered parts (a, b, c, etc.) for all controls with lettered parts
• the control itself where there are no lettered parts exist.
  (Note: 800-53r4 currently has numbered parts as subordinate to lettered parts within control definitions. In other words there are no controls that have numbered parts without also having lettered parts.)

While the response points can be observed by a human looking at the legacy MS Word template, or coded as rules into a tool, there is no clear machine-readable mechanism for FedRAMP to communicate or change the expected response points for each control.

This enhancement would enable SSP tools to provide response fields at the correct level of granularity required by FedRAMP for each control, and allow FedRAMP to use different response points (when compared to the current pattern of requirements), for future 800-53 releases.

Goals:

• Define a mechanism to clarify the required response point for an individual control as required by FedRAMP.
• Update FedRAMP baselines to reflect the appropriate response point for all FedRAMP-required controls.

Dependencies:

None.

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.

Action Item

This is a ...

• enhancement - Something could be better.

This relates to ...

• the FedRAMP OSCAL Registry (Excel File)
• the Guide to OSCAL-based FedRAMP System Security Plans (PDF)
• the FedRAMP SSP OSCAL Template (JSON Format)
• the FedRAMP SSP OSCAL Template (XML Format)

Describe the problem or enhancement

Within the back-matter assembly available within every OSCAL file, NIST currently provides separate citation and resource syntax, where citations point to external items of interest and resources are more for attached files.

NIST is considering collapsing those for simplicity by merging the citation syntax into resource. If NIST decides to move forward with this change, FedRAMP will need to redefine how the relevant portions of the OSCAL-based FedRAMP SSP is reflected.

This will impact laws, regulations, standards, and guidance references and possibly a few other citations.

Goals:

Ensure the FedRAMP materials are updated to reflect these changes, when NIST publishes this change as part of the OSCAL 1.0.0-milestone3 Release later this year.

Dependencies:

usnistgov/OSCAL#587
(NOTE The title for that issue in the OSCAL repo is miss-leading; however, this topic is discussed in the issue.)

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.

Other Comments

None.

Describe the bug

There is duplication of content in this repo and the official usnistgov/oscal-content repo for content artifacts, specifcally the NIST baselines. As it stands, there is not complete parity between the FedRAMP customized baselines in the form of catalog and profiles here and there in the NIST repository.

Per discussion with the NIST development team (@david-waltermire-nist and @wendellpiez) it only makes sense to maintain the canonical version here in the FedRAMP repository starting with an incoming PR from me (on behalf of FedRAMP) until further notice.

Who is the bug affecting?

Anyone who is relying on different copies of the FedRAMP baselines and wishes to keep current will find different conflicting copies of the catalog and baseline profiles.

What is affected by this bug?

The consistency of content in different locations.

When does this occur?

Whenever viewing the different repositories.

How do we replicate the issue?

1. Visit this repo.
2. Visit the github.com/usnistgov/oscal-content repo.
3. Open the baselines for fedramp.gov and compare to find significant disparities.

Expected behavior (i.e. solution)

Find one official copy of the FedRAMP catalog and baseline profiles.

Action Item

This is a ...

• fix - Something needs to be different.

This relates to ...

• the FedRAMP OSCAL Registry (Excel File)
• the Guide to OSCAL-based FedRAMP System Security Plans (PDF)
• the FedRAMP SSP OSCAL Template (JSON Format)
• the FedRAMP SSP OSCAL Template (XML Format)

Describe the problem or enhancement

NIST is updated the @name flag in several places where a title field is better suited than an @name flag. This also addresses concerns where the @name flag was required, but of NCname data type, which could not accept spaces.

NIST is changing the @name flag to a title element for the following assemblies in the OSCAL syntax:

• authorized-privilege
• component
• information-type
• leveraged-authorization
• service

In relation to this, NIST is also adding an @id flag, and a title field to the protocol assembly, but is leaving the @name flag as-is.

Goals:

Ensure the Guide, Registry, and templates are updated to reflect these syntax changes.

Dependencies:

usnistgov/OSCAL#535

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.

Other Comments

None

Describe the bug

The baseline OSCAL profiles responsible parties section references unknown UUIDs.

Many profiles list 4aa7b203-318b-4cde-96cf-feaeffc3a4b7 as values for the prepared-by and fedramp-pmo roles, yet the FedRAMP PMO party in those profiles has a UUID of 8cc0b8e5-9650-4d5f-9796-316f05fa9a2d.

Who is the bug affecting?

Anyone using baseline OSCAL profiles.

What is affected by this bug?

The ability to resolve responsible parties in baselines.

When does this occur?

Always.

• This is a ...

  • concern - I think something needs to be different.
  • question - I didn't understand something.
  • kudo - I found something helpful and want to encourage it in future FedRAMP publications.
  • request - I would like to see something additional provided.

• This relates to ...

  • the FedRAMP OSCAL Registry (Excel File)
  • the Guide to OSCAL-based FedRAMP Content (PDF)
  • the Guide to OSCAL-based FedRAMP System Security Plans (SSP) (PDF)
  • the Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP) (PDF)
  • the Guide to OSCAL-based FedRAMP Security Assessment Reports (SAR) (PDF)
  • the Guide to OSCAL-based FedRAMP Plan of Action and Milestones (POA&M) (PDF)
  • the FedRAMP SSP OSCAL Template (JSON or XML Format)
  • the FedRAMP SAP OSCAL Template (JSON or XML Format)
  • the FedRAMP SAR OSCAL Template (JSON or XML Format)
  • the FedRAMP POA&M OSCAL Template (JSON or XML Format)
  • General/Overall
  • Other

• Where, exactly?

Throughout the guides, wherever there are compound paths (where predicates contain paths).

• What is your feedback?

Wherever long compound paths appear in the registry, instead provide decomposed variants.

Example: System Owner's Name in section 4.6 (for Table 3.1) is (now) shown to be

/*/metadata/party[@uuid=[/*/metadata/responsible-party[@role-id="system-owner"]/party-uuid]]/party-name

(btw there is also a little bug in there!)

Same thing, decomposed:

let $system-owner-assignment := /*/metadata/responsible-party[@role-id="system-owner"]
return /*/metadata/party[@uuid=$system-owner-assignment/party-uuid]/party-name

(This is XPath syntax but we could also use English or pseudocode to express the variable binding.)

Or even

let $system-owner-assignment := /*/metadata/responsible-party[@role-id="system-owner"]
let $system-owner := /*/metadata/party[@uuid=$system-owner-assignment/party-uuid]
return $system-owner/party-name

This would make the paths more intelligible and sensible.

• What action would you like to see from the FedRAMP PMO?

Consider whether and how syntax might be further explained and improved on, and execute revisions of the guides accordingly. This info is extremely useful, but as given one has to be more or less an expert in XPath to take advantage of it.

Since as it seems there are also bugs in these paths, perhaps this should all be done systematically, perhaps until the paths themselves can be validated operationally (for example with the help of the XSLT under development).

• Other information (e.g. detailed explanation, related issues, suggestions how to fix, links for us to have context, eg. slack, gitter, etc)

n/a

Describe the bug

There are some broken URLs in the README and obsolete contact information.

Who is the bug affecting?

Anyone reading the README when visiting the content when landing on github.com/GSA/fedramp-automation which shows the README.

What is affected by this bug?

Clarity of support steps and access to recommended reading.

When does this occur?

Always.

How do we replicate the issue?

1. Visit the repository.
2. Read the README.md file provided by default.

Expected behavior (i.e. solution)

I expect read the initial README file and find the correct information.

• This is a ...

  • concern - I think something needs to be different.
  • question - I didn't understand something.
  • kudos - I found something helpful and want to encourage it in future FedRAMP publications.
  • request - I would like to see something additional provided.

• This relates to ...

  • the FedRAMP OSCAL Registry (Excel File)
  • the FedRAMP OSCAL Registry (XML)
  • the Guide to OSCAL-based FedRAMP Content (PDF)
  • the Guide to OSCAL-based FedRAMP System Security Plans (SSP) (PDF)
  • the Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP) (PDF)
  • the Guide to OSCAL-based FedRAMP Security Assessment Reports (SAR) (PDF)
  • the Guide to OSCAL-based FedRAMP Plan of Action and Milestones (POA&M) (PDF)
  • the FedRAMP SSP OSCAL Template (JSON or XML Format)
  • the FedRAMP SAP OSCAL Template (JSON or XML Format)
  • the FedRAMP SAR OSCAL Template (JSON or XML Format)
  • the FedRAMP POA&M OSCAL Template (JSON or XML Format)
  • General/Overall
  • Other

NOTE: For feedback related to the OSCAL syntax itself, please create or add to an issue in the NIST OSCAL Repository.

• Where, exactly?
  • For the registry, please indicate the tab and cell, or other clear identifier
  • For the guide, please indicate the section number and printed page number (lower right corner)
  • For the OSCAL XML or JSON files, please indicate XML or JSON; and indicate the line number, field id, or other clear location identifier

FedRAMP XML values file

One potential location, as expressed as an XPath query, would be here.

//f:value-set/cardinality

• What is your feedback?

Per conversation with @brianrufgsa, in order to ease development of validation tooling with Schematron, or any other XML-based tools that will look at the FedRAMP XML values directly, it might be prudent to evaluate bringing in the cardinalities expressed in the FedRAMP OSCAL Registry Excel files as <cardinality/> element for applicable <value-set/> items where the cannonical OSCAL implementation does not specify them (and a user relies on defaults) or FedRAMP wishes to override the explicitly set NIST OSCAL default.

The layout can be something simple, potentially like this.

   <value-set name="control-implementation-status">
      <cardinality min="1" max="1">
      <formal-name>Control Implementation Status</formal-name>
      <description>The implementation status of the control.</description>
      <binding pattern="implemented-requirement/annotation[@name='implementation-status']/@value"/>
      <allowed-values allow-other="no">
         <enum value="implemented" short-label="Implemented">Implemented</enum>
         <enum value="partial" short-label="Partial">Partially Implemented</enum>
         <enum value="planned" short-label="Planned">Planned</enum>
         <enum value="alternative" short-label="Alternative">Alternative Implementation</enum>
         <enum value="not-applicable" short-label="N/A">Not Applicable</enum>
      </allowed-values>
   </value-set>

In some cases, as discussed, we would want a max attribute that is unbounded and not an integer value, to align with the registry in Excel and existing Metaschema definitions/style as exposed in XSD. I just picked attachment-type as an example, without much intention.

   <value-set name="attachment-type">
      <cardinality min="0" max="unbounded">
      <formal-name>Attachment Type</formal-name>
      <description>Identifies the type of attachment.</description>
      <binding pattern="resource/prop[@name='type'][@ns='https://fedramp.gov/ns/oscal']"/>
      <allowed-values allow-other="yes">
         <enum value="law" short-label="Law">Law or Statute</enum>
         <enum value="regulation" short-label="Regulation">Regulation or Directive</enum>
         <enum value="standard" short-label="Standard">Industry Standard</enum>
         <enum value="guidance" short-label="Guidance">Guidance</enum>
         <enum value="pii" short-label="P.I.I.">Privacy Impact Information</enum>
         <enum value="policy" short-label="Policy">Polciy</enum>
         <enum value="procedure" short-label="Procedure">Procedure</enum>
         <enum value="guide" short-label="Guidance">Guidance Document</enum>
         <enum value="pia" short-label="P.I.A.">Privacy Impact Assessment</enum>
         <enum value="rob" short-label="R.O.B.">Rules of Behavior</enum>
         <enum value="plan" short-label="Plan">Plan</enum>
         <enum value="system-security-plan" short-label="SSP">System Security Plan</enum>
         <enum value="artifact" short-label="artifact">Artifact</enum>
         <enum value="evidence" short-label="evidence">Evidence</enum>
         <enum value="screen-shot" short-label="screen">Screen Shot</enum>
         <enum value="image" short-label="image">Image</enum>
         <enum value="tool-report" short-label="Report">Tool Report</enum>
         <enum value="raw-tool-output" short-label="Raw">Raw Tool Output</enum>
         <enum value="interview-notes" short-label="Notes">Interview Notes</enum>
         <enum value="questionnaire" short-label="Questions">Questions</enum>
         <enum value="report" short-label="Report">Report</enum>
      </allowed-values>
      <remarkas>Not all values apply to all FedRAMP artifacts.</remarkas>
   </value-set>

• What action would you like to see from the FedRAMP PMO?

Begin a conversation here. Per discussion with @brianrufgsa, I would like to add cardinality for one of the relevant items to start, probably control-implementation-status, as our validation work needs it

• Other information (e.g. detailed explanation, related issues, suggestions how to fix, links for us to have context, eg. slack, gitter, etc)

Action Item

This is a ...

• fix - Something needs to be different.

This relates to ...

• the Guide to OSCAL-based FedRAMP System Security Plans (PDF)
• the FedRAMP SSP OSCAL Template (JSON Format)
• the FedRAMP SSP OSCAL Template (XML Format)

Describe the problem or enhancement

NIST changes the syntax for setting parameters in profile from set-param to simply set. Currently the SSP syntax still uses set-param.

NIST intends to update the SSP syntax to match the profile syntax. This will require changes to the FedRAMP OSCAL guide and templates.

Goals:

Update the OSCAL-based FedRAMP guide and templates to reflect NIST's syntax change, when they publish it as part of the OSCAL 1.0.0-milestone3 Release later this year.

Dependencies:

usnistgov/OSCAL#568

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.

Other Comments

None.

Action Item

This is a ...

• fix - Something needs to be different.
• enhancement - Something could be better.
• investigation - Something needs to be investigated further.

This relates to ...

• the FedRAMP OSCAL Registry (Excel File)
• the Guide to OSCAL-based FedRAMP Content (PDF)
• the Guide to OSCAL-based FedRAMP System Security Plans (SSP) (PDF)
• the Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP) (PDF)
• the Guide to OSCAL-based FedRAMP Security Assessment Reports (SAR) (PDF)
• the Guide to OSCAL-based FedRAMP Plan of Action and Milestones (POA&M) (PDF)
• the FedRAMP SSP OSCAL Template (JSON or XML Format)
• the FedRAMP SAP OSCAL Template (JSON or XML Format)
• the FedRAMP SAR OSCAL Template (JSON or XML Format)
• the FedRAMP POA&M OSCAL Template (JSON or XML Format)
• General/Overall
• Other

NOTE: For issues related to the OSCAL syntax itself, please create or add to an issue in the NIST OSCAL Repository.

Describe the problem or enhancement

Per request from the 10x ASAP P3 Team and 18F#69, the team recommends we select a valid software license for the repository, like other open-source in general and NIST OSCAL resources in particular

Goals:

• FedRAMP developers and downstream consumers want the FedRAMP PMO to determine a license for the source code repository to understand re-usability of the validation software and additional fedramp-automation material in the repo.

Dependencies:

• Official GSA FedRAMP staff guidance.

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.

Other Comments

Recommended default TTS/18F license per organizational policy is Creative Commons CC0 public domain license.

Action Item

This is a ...

• enhancement - Something could be better.

This relates to ...

• the FedRAMP OSCAL Registry (Excel File)
• the Guide to OSCAL-based FedRAMP System Security Plans (PDF)
• the FedRAMP SSP OSCAL Template (JSON Format)
• the FedRAMP SSP OSCAL Template (XML Format)

Describe the problem or enhancement

Currently the ability to indicate a document label, such as "Controlled Unclassified Information (CUI)", is handled as a FedRAMP Extension to OSCAL.
The NIST OSCAL Team is considering adding the syntax for this to the core OSCAL syntax,. Once that happens, FedRAMP's OSCAL Guide, Registry, and templates will need to be updated to reflect this change.

Goals:

Ensure FedRAMP's OSCAL materials to reflect core OSCAL syntax for document labeling, when NIST publishes this change as part of the OSCAL 1.0.0-milestone3 Release later this year.

Dependencies:

usnistgov/OSCAL#600

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.

Other Comments

None.

Action Item

This is a ...

• enhancement - Something could be better.

This relates to ...

• General/Overall

Describe the problem or enhancement

A reciprocity exists between FedRAMP and DoD where a CSP can achieve a FedRAMP authorization, then DoD adjudicated the package by focusing only on the additional IL4 or IL5 requirements.

DISA indicates it would be helpful to have guidance regarding the additional content that should appear in an OSCAL-based FedRAMP package when it is intended for further adjudication by DoD after a FedRAMP authorization.

This may be a larger effort; however, we should start by investigating and quantifying the additional information requirements.

Goals:

• Identify the information requirements for DOD reciprocity in a FedRAMP OSCAL authorization package

Dependencies:

None.

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.
• Level of effort defined and attached to this issue

Action Item

This is a ...

• enhancement - Something could be better.

This relates to ...

• Other

Describe the problem or enhancement

NIST has an oscalbuilder user user that is shared in our build process. In consultation with NIST OSCAL developers, it is clear that is not sustainable in the long-term and we should fix our copy of the CI/CD system to use its own user.

Goals:

Clear separation of concerns and least privilege for users (even if automated) .

Dependencies:

• GSA Policy requirements for automated accounts in Github.
• Implementation possibilities for provisioning and ongoing management.

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.

Action Item

This is a ...

• enhancement - Something could be better.

This relates to ...

• General/Overall
• Other

Describe the problem or enhancement

Establish basic CI/CD functionality within the fedramp-automation repository.

Goals:

• validate OSCAL content relative to the NIST OSCAL syntax
• convert provided formats to alternate formats (XML -> JSON, or JSON -> XML)
• validate if non-OSCAL XML, JSON, and transforms are well-formed

Dependencies:

None.
This relates to usnistgov/OSCAL#639.

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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 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.}

Action Item

This is a ...

• enhancement - Something could be better.

This relates to ...

• the Guide to OSCAL-based FedRAMP Content (PDF)
• the Guide to OSCAL-based FedRAMP System Security Plans (SSP) (PDF)
• the Guide to OSCAL-based FedRAMP Security Assessment Plans (SAP) (PDF)
• the Guide to OSCAL-based FedRAMP Security Assessment Reports (SAR) (PDF)
• the Guide to OSCAL-based FedRAMP Plan of Action and Milestones (POA&M) (PDF)
• the FedRAMP SSP OSCAL Template (JSON or XML Format)
• the FedRAMP SAP OSCAL Template (JSON or XML Format)
• the FedRAMP SAR OSCAL Template (JSON or XML Format)
• the FedRAMP POA&M OSCAL Template (JSON or XML Format)

Describe the problem or enhancement

Our current documentation, and a significant subset of example resources, repeatedly hyperlink to external assets, from NIST OSCAL documents. Checking these can be exhaustive and error-prone via manual review of the documents, baselines, and templates. Automated checks can help flag and programmatically replace as many links as possible.

Goals:

Documentation references are important, and keeping them close as possible and relevant to block of text or code without using references and citations that distance them from that material, would be ideal.

Dependencies:

None

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.

Describe the bug

Transfer bug report from usnistgov/oscal-content#73 by @grosven.

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.

When does this occur?

N/A

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

N/A

Describe the bug

Fedramp baselines are still using oscal milestone 3 please update to RC1

Who is the bug affecting?

anyone trying to use fedramp baselines & latest version of oscal

What is affected by this bug?

baselines require milestone3=>RC1 conversion to interop with latest oscal

Expected behavior (i.e. solution)

Update Baseline Json files

Action Item

This is a ...

• enhancement - Something could be better.

This relates to ...

• General/Overall

Describe the problem or enhancement

The rules and checklists to perform manual adjudication of FedRAMP authorization packages are well defined. Many of them can be fully automated, especially the initial checks for completeness.

Where the review rules and checklists can be automated, there are many approaches. Ideally, our approach should allow these rules to be published and re-used by tool developers. This offers several high-level advantages:

1. Reduce the level of effort for tool developers
2. Ensure consistency of content validation across tools.
3. Easily publish updates to our validation checks that can be instantly incorporated into existing tools.
4. Provides the ability for stakeholders to validate their content before submission to the PMO

Goals:

• Identify and prioritize validation rules
• identify a technology/standard for creating and publishing validation rules
• produce guidance on adopting validation rules

Dependencies:

None.

Acceptance Criteria

• All FedRAMP Documents Related to OSCAL Adoption 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.

• Validation rules identified

• Technology/standard selected

• documentation provided

Other Comments

OSCAL is designed with schematron validation in mind. Schematron is a 4th generation language (4GL), which can be used by most modern programming languages.

It was designed to provide a common syntax for defining business rules/validation activities on XML content, separate from the presentation logic and UI logic.

Describe the bug

There is some inconsistency in three places about how we have AC-1(a) and AC-1(b) elements that correspond to the current FedRAMP SSP templates in OSCAL. For AC-1 and AC-2 the structure of all response points for AC-1 look like this in OSCAL:

• AC-1
  • Part A
  • Part B(1)
  • Part B(2)

It should in fact look like this, like the FedRAMP SSP Word Templates and guidance suggests:

• AC-1
  • Part A(1)
  • Part A(2)
  • Part B(1)
  • Part B(2)

To fix, FedRAMP will need to:

• Fix the baselines
• Fix the template SSP example
• Update the example snippet in the FedRAMP OSCAL guides

Who is the bug affecting?

Public sector OSCAL developers who reported this issue via email.

What is affected by this bug?

Consistency issues with mismatches and mapping FedRAMP data to DoD CCIs.

When does this occur?

Always.

How do we replicate the issue?

1. Clone this repo.
2. Review baselines and template SSP.

         <part id="ac-1_smt" name="statement">
            <p>The organization:</p>
            <part id="ac-1_smt.a" name="item">
               <prop ns="https://fedramp.gov/ns/oscal"
                     name="response-point"
                     value="You must fill in this response point."/>
               <prop name="label" value="a."/>
               <p>Develops, documents, and disseminates to <insert type="param" id-ref="ac-1_prm_1"/>:</p>
               <part id="ac-1_smt.a.1" name="item">
                  <prop name="label" value="1."/>
                  <p>An access control policy that addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and</p>
               </part>
               <part id="ac-1_smt.a.2" name="item">
                  <prop name="label" value="2."/>
                  <p>Procedures to facilitate the implementation of the access control policy and associated access controls; and</p>
               </part>
            </part>

      <implemented-requirement control-id="ac-1" uuid="eee8697a-bc39-45aa-accc-d3e534932efb">
         <prop ns="https://fedramp.gov/ns/oscal" name="planned-completion-date" value="2020-11-27Z"/>
         <prop name="implementation-status" value="planned">
            <remarks>
               <p>Describe the plan to complete the implementation.</p>
            </remarks>
         </prop>
         <prop name="control-origination" value="system-specific"/>
         <statement statement-id="ac-1_smt" uuid="240fa015-01df-4741-bff5-6958c7fb85e5">
            <by-component component-uuid="60f92bcf-f353-4236-9803-2a5d417555f4"
               uuid="d9d1ce66-ff47-474d-8596-5fdf2af60179">
               <description>
                  <p>Describe how the control is satisfied within the system.</p>
               </description>
               <set-parameter param-id="ac-1_prm_1">
                  <value>[replace with list of personnel or roles]</value>
               </set-parameter>
               <set-parameter param-id="ac-1_prm_2">
                  <value>[specify frequency]</value>
               </set-parameter>
               <set-parameter param-id="ac-1_prm_3">
                  <value>[specify frequency]</value>
               </set-parameter>
            </by-component>
         </statement>
         <statement statement-id="ac-1_smt.a" uuid="fb4d039a-dc4f-46f5-9c1f-f6343eaf69bc">
            <by-component component-uuid="60f92bcf-f353-4236-9803-2a5d417555f4"
               uuid="3f5612a4-cd1d-4c47-8cae-75d2eaa332cd">
               <description>
                  <p>Describe how Part a is satisfied within the system.</p>
                  <p>Legacy approach. If no policy component is defined, describe here how the
                     policy satisfies part a.</p>
                  <p>In this case, a link must be provided to the policy.</p>
                  <p>FedRAMP prefers all policies and procedures be attached as a resource in the
                     back-matter. The link points to a resource.</p>
               </description>
               <link href="#090ab379-2089-4830-b9fd-26d0729e22e9" rel="policy"/>
            </by-component>
            <by-component component-uuid="F25E84BF-3E57-48C3-AC0B-7A567B3AF79E"
               uuid="2CF56836-6834-49A9-96CD-4F49C17AAB01">
               <description>
                  <p>Describe how this policy component satisfies part a.</p>
                  <p>Component approach. This links to a component representing the Identity
                     Management and Access Control Policy.</p>
                  <p>That component contains a link to the policy, so it does not have to be linked
                     here too.</p>
               </description>
            </by-component>
            <remarks>
               <p>The specified component is the system itself.</p>
               <p>Any control implementation response that can not be associated with another
                  component is associated with the component representing the system.</p>
            </remarks>
         </statement>
         <statement statement-id="ac-1_smt.b.1" uuid="b46f97ec-55c1-4249-a9b9-3a228f1e3791">
            <by-component component-uuid="60f92bcf-f353-4236-9803-2a5d417555f4"
               uuid="767666cb-e558-484b-81ca-b0209932425c">
               <description>
                  <p>Describe how Part b-1 is satisfied.</p>
               </description>
            </by-component>
         </statement>
         <statement statement-id="ac-1_smt.b.2" uuid="59c67969-3d5c-45f1-8e3e-1e642249633f">
            <by-component component-uuid="60f92bcf-f353-4236-9803-2a5d417555f4"
               uuid="5a869308-1625-4d92-9ed8-ff5d8bd13656">
               <description>
                  <p>Describe how Part b-2 is satisfied.</p>
               </description>
            </by-component>
         </statement>
      </implemented-requirement>

Expected behavior (i.e. solution)

The baseline part/response-points and and the template SSP implemented-requirement/statement/@statement-ids align properly with current expectations and data structure of Word-formatted FedRAMP SSP templates.