SSP Import Statement

[brian-ruf]

User Story

As an SSP OSCAL Author, I would like way to refer to an authoritative profile without having a URL path to that profile.

Some profiles are an authoritative representation of an organization's baseline. Often there are a collection of High, Moderate, and Low baselines that are also updated periodically, thus different systems may need to refer to different versions of the baseline.

The challenge is when an authorization package (SSP, SAP, SAR, and POA&M) is handed off from one organization to another, the import-profile URL becomes invalid as each organization's copy may be on separate organizational Intranets.

An organization delivering an authorization package needs an alternative method for referring to an authoritative copy of a profile when the delivering organization's direct path to a profile is unreachable by the receiving organization, and the delivering party has no way to know the correct path of the profile for the receiving organization.

Goals

Provide a mechanism that enables an SSP to be shared between two or more organizations with a reference to an SSP that allows each organization to re-connect the appropriate SSP without being able to resolve the URI in the import-profile.

Dependencies

No response

Acceptance Criteria

• [ ] All OSCAL website and readme documentation affected by the changes in this issue have been updated. Changes to the OSCAL website can be made in the docs/content directory of your branch.
• [ ] A Pull Request (PR) is submitted that fully addresses the goals of this User Story. This issue is referenced in the PR.
• [ ] The CI-CD build process runs without any reported errors on the PR. This can be confirmed by reviewing that all checks have passed in the PR.

(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)

Revisions

No response

[iMichaela]

@brian-ruf Thank you for raising this issue. It is a valid issue. Do you have a proposal that is backwards computable? I will research possible solutions as well, but the first that comes to mind would be programatic - request to attache the profile as stand alone artifact or incorporate it in the backwater (similar to other artifacts that need to be submitted with an SSP package. Should we have a call to further discuss this issue? A better native solution (if not found today) can be provided with a major release of OSCAL. Looking forward to further discuss this issue. Any community member interested in this topic is invited to wight in and to participate in the proposed call as well.

[wendellpiez]

This is indeed an interesting problem.

For XML technologies, a "catalog" mechanism (no relation to OSCAL catalogs) is available to provide for this kind of indirection as well as related functionality (libraries, caching etc.). As it is fairly widely supported in XML toolchains I would recommend it as a stopgap when available (See https://en.wikipedia.org/wiki/XML_catalog). However, it is no help for the problem when not using appropriate tooling, or for interchange, and is unknown to JSON (AFAIK).

Since that is less helpful than I would like, I add one other observation. There are two problems here. First is the a matter of how common resources are named and the governance of name management; then there is the resolution/retrieval mechanism. If OSCAL has a solution to the first problem (e.g. rules about naming and discoverability of common resources), XML catalogs or other analogous mechanisms could potentially be deployed to address the second, as developers see fit.

@iMichaela's interesting proposal for interchange ground rules could also help, and could be tied in to a community approach to name management.

If it's any comfort, this problem emerging is a sign of healthy growth, IMHO.

Potentially related technologies: Formal Public Identifiers (now regarded as obsolete?), also Digital Object Identifiers.

[wendellpiez]

Hello again, apologies, still thinking. These latest suggestions aren't going to help for things that are not formally published. Hm.

I also think we need to know more. Is the problem that the import links break, or that the links do not point unambiguously to anything and hence cannot be repaired when they break? Or both?

@iMichaela's idea implies there is a grey zone between 'published and available resource' (such as a truly standard profile in a public repository) and 'my surrogate, please use this' (such as a version or profile of a public profile with some small but super-important tailoring). If such zones cannot be eliminated they must be managed. Yet at the same time, an organization's delta or variance from a published/standard baseline is supposed to be important information, which the profile model is designed to expose.

I think it comes down to who gets to define which profile an SSP uses. If a sender cannot guarantee an SSP works to a profile known to the receiver, what use is that? The receiver needs to able to stipulate the profile, or the sender's claim of implementation is not as meaningful. In other words, related to the question of the dereferencing (identifying and importing the correct profile artifact with its dependencies) is what do you get when you have dereferenced, and how is that useful?

Because profiles (of course) can deal with the technical aspects of profiling, but not problems of control governance - who designs the profile and how is it made available, to whom.

DOIs might still help in some circumstances. :-)

[brian-ruf]

@iMichaela and @wendellpiez I would love to discuss this, and appreciate the early brainstorming and questions!

@wendellpiez to answer your questions, it is at least the latter has the potential to be both. At a minimum it is that the import link can break when an SSP is passed from one organization to another.

Background

Usually an Agency has published High, Moderate, and Low baselines that all of their systems must use. the authorizing official (or a process approved by the AO) decides which of those three baseline a system uses.

A system's OSCAL SSP can point to a locally resolvable copy of a profile, then deliver that SSP to an assessor or authorizing official, where the profile URL is not reachable. Their tools can try to infer from the file name which baseline was intended, but the potential for ambiguity exists. Especially if there have been updates to the baseline/profile over time.

---

Concept

I really like where Wendell is going with the formal public identifiers. I was thinking along similar lines - using the existing metadata/document-id[@scheme] fields.

Baseline/Profile authors can assign a document-id / scheme value pair appropriate for the community of system owners expected to consume the organization's baselines. Profile authors can then update the document-id with each new published version of the baseline.

SSP authors can then reference that document-id / scheme pair when identifying an applicable profile. If this information is embedded in a local copy of a profile, tools can cite it in the SSP as a fallback option for when the import-profile/@href value is unreachable.

---

Proposed Solutions

Assuming the above concept makes sense, there is a way to accomplish this today with no changes to the OSCAL syntax, but it forces the use of a URI fragment in the import-profile/@href flag and a resource for the profile in the SSP.

Using Existing OSCAL Syntax

SSP authors can use a URI fragment in the import-profile/@href that points to an SSP resource for the profile as has been modeled previously. The SSP authoring tool can simply include the published profile's document-id / scheme pair in the SSP resource as provided by existing OSCAL syntax. (/system-security-plan/back-matter/resource/document-id)

When tools encounter an import-profile/@href with a URI fragment, they can continue to try the resource/rlink/@href as usual, but fall back to a document lookup via a document-id / scheme pair if the @href value is unreachable.

When using document IDs in this way, SSP authors are prevented from putting a direct link to a profile in the import-profile/@href field and must use the URI fragment / resource approach.

More Flexible Solution

If we wanted to offer SSP authors the ability to use document-ids for linking profiles without forcing the use of resources, we could add a document-id / scheme pair to the SSP's import-profile assembly.

Under OSCAL 1.x.x the document-id / scheme pair would be optional and the @href would continue to be required, representing a non-breaking change. The document ID simply becomes optional additional content that could be used if an href value fails to resolve.

Under OSCAL 2.x.x the import-profile constraint could then be changed to require either the @href or the document-id / scheme pair to be present; and continue to allow both to be present.

Final Thoughts

The first solution is available immediately and can simply become a point of education. It can remain a viable option, even if we elect to expand the import-profile assembly. That expansion would mean both solutions are available to SSP authors.

Also, if we elect to expand the import-profile assembly additional decision points must be addressed, such as whether to make the document-id / scheme pair into a child field or flags for XML (they'd be children either way in JSON/YAML), and whether to allow just one document-id / scheme pair or an array of them.

[aj-stein-gsa]

Background

Usually an Agency has published High, Moderate, and Low baselines that all of their systems must use. the authorizing official (or a process approved by the AO) decides which of those three baseline a system uses.

A system's OSCAL SSP can point to a locally resolvable copy of a profile, then deliver that SSP to an assessor or authorizing official, where the profile URL is not reachable. Their tools can try to infer from the file name which baseline was intended, but the potential for ambiguity exists. Especially if there have been updates to the baseline/profile over time.

Concept

I really like where Wendell is going with the formal public identifiers. I was thinking along similar lines - using the existing metadata/document-id[@scheme] fields.

I appreciate the thought and effort that you put into this issue, @brian-ruf, but I will say for now, to reiterate a similar approach proposed to FedRAMP staff before, that this particular approach will not meet the use cases and their requirement for FedRAMP automation, within and separate of the platform. I will try to update this issue accordingly for upstream NIST maintainers and the community to know, but I thought it is worth repeating here since you put forth a detailed proposal.

More to follow in the coming months.

[brian-ruf]

@aj-stein-gsa I had several use cases in mind when I wrote this, which is why I did not call out FedRAMP specifically.

[aj-stein-gsa]

@aj-stein-gsa I had several use cases in mind when I wrote this, which is why I did not call out FedRAMP specifically.

I get you, I am just giving the FedRAMP take, carry-on.

[wendellpiez]

This is a complex problem with several facets.

It also probably requires a multipronged approach.

FPIs are as I understand it obsolete or obsolescent - however they have two virtues: 1. they can actually be coined (albeit not registered) without permission, while 2. they are nonetheless unambiguous enough as strings to continue to serve disambiguation purposes without a top-down authority. Hence they continue to be used in some contexts e.g. deep inside tooling such as XML Catalogs.

The OASIS Catalog mechanism is an invaluable asset but also only part of the solution (XML!), while also it arguably serves to move, not hide the problem. (Although personally I am afraid that adding to OSCAL semantics has the same issue.)

DOIs and other indirected referencing schemes could also play a role.

What about alternative URI schemes?

The range of options plus what @aj-stein-gsa says suggests to me that this warrants further study. Much depends on exactly which problem we're solving for whom, 'broken links' being a bit vague. I'd also like to see the actual problems in broader context. Is this really something that a well-governed indirection or link-description mechanism would solve or are the issues deeper than that?

As stated (it seems to me), the problem is in partner organizations not being clear with each other about what they mean when they say "the HIGH profile" (for example) and specifically, what is meant by "the" in that phrase. There is a world of difference between the published HIGH and any tailoring of it (i.e. any of its 'overlays'), not because there's a big difference (the worlds can be similar) but because the extent of the difference is unknowable without looking.

Bottom line is, if you don't control the profile, you don't control the baseline. So on whose server does that document live?

And if you don't know what the baseline looks like, is it okay to make what amount to educated guesses? If an SSP is evaluated against not its own 'original' profile but a new or synthetic one, what then? In general, what is the strategy for evaluating an SSP whose baseline is in question? Is a baseline ever negotiable? The murkiness of my understanding of the world here is part of what makes me think broader discussion is needed.