SSP Import Statement #2061
Comments
|
@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. |
|
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. |
|
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. :-) |
|
@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. BackgroundUsually 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. ConceptI really like where Wendell is going with the formal public identifiers. I was thinking along similar lines - using the existing Baseline/Profile authors can assign a SSP authors can then reference that Proposed SolutionsAssuming 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 Using Existing OSCAL SyntaxSSP authors can use a URI fragment in the When tools encounter an When using document IDs in this way, SSP authors are prevented from putting a direct link to a profile in the More Flexible SolutionIf 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 Under OSCAL 1.x.x the Under OSCAL 2.x.x the Final ThoughtsThe 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 Also, if we elect to expand the |
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. |
|
@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. |
|
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. |
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-profileURL 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
(For reviewers: The wiki has guidance on code review and overall issue review for completeness.)
Revisions
No response
The text was updated successfully, but these errors were encountered: