OSCAL Implementation: Component Definition

[akarmel]

User Story:

As an OSCAL component owner or provider, I am able to publish an OSCAL "Component Definition" (as per the diagram below) that associates a component in an OSCAL implementation with an OSCAL Profile, identifying the specific controls or parts of controls implemented by the component from the Profile. Mappings to multiple Profiles can be handled either through multiple mappings in a single "component definition" or through multiple "component definitions".

Goals:

1. Per the following representative diagram describing the elements of the OSCAL implementation schema, develop an OSCAL implementation "component definition" that associates a component in an OSCAL implementation with an OSCAL Profile.

Defined by the system owner/administrator
+----------------------------------+
| System Specification             |    
| + -----------------------------+ |
| | Aggregated into Capabilities | |        
| | +-------------------------+  | |
| | | Component Specification |  | |
| | +------|------------------+  | |
| +--------|---------------------+ |
+----------|-----------------------+
           |
          \/
+----------------------+
| Component Definition |
+----------------------+
Provided by the component owner or provider

Dependencies:

None.

Acceptance Criteria

1. OSCAL Implementation schema has been developed to support the OSCAL "Component Definition" associating a component in an OSCAL implementation with an OSCAL Profile.
2. OSCAL Implementation schema has been sufficiently documented to describe the functions contained therein.
3. OSCAL Implementation schema PR has been reviewed by the OSCAL Team and merged into the OSCAL GitHub repo.

[iMichaela]

6/28/2018 Status

Reviewed the user story to reflect the scenario discussed during the meeting.

[shawndwells]

On 6/28/18 4:33 PM, Michaela Iorga wrote: Reviewed the user story to reflect the scenario discussed during the meeting.

Out of curiosity, what meeting? Have been monitoring GitHub and various mailing lists in hopes of learning if/when OSCAL community calls and meetings are. Did I miss an announcement/invite?

[iMichaela]

@shawndwells: The meetings mentioned in our comments are NIST-internal meetings. Thank you for your interest in our project. We are very interested in collaborating, in different ways, with other parties. Please let me or @david-waltermire-nist know in which way would you like to support our effort, and we will integrate you.

[iMichaela]

July 18 Status Update (Sprint 12 Acceptance Meeting)

The issue was not assigned to any member of the team in Sprint 12 and we will push the issue to Sprint 13

[anweiss]

Notes being compiled in https://hackmd.io/x43sK8IvSyOhW3no7fdh2w?both

[iMichaela]

8/30/2018 Status Meeting

@wendellpiez , @anweiss @JJediny will continue on refining the prototype model and generate data sets to test against this model.

[anweiss]

My current approach has been to analyze Microsoft's plethora of Audit Reports -> https://servicetrust.microsoft.com/Documents/ComplianceReports. There's a lot of great data in there that spans FedRAMP, ISO, HIPAA, etc. I've been trying to identify the "component definition" equivalents in that data and correlating those equivalents to applicable elements of TOSCA that might be useful in our actual model for "component definition". Interestingly enough, what I'm finding is that most of their "component definitions" are pretty high-level; just a few paragraphs in many cases with a sprinkling of architecture diagrams. Given that, I think we need to be a bit more specific as to who our intended consumers/producers of implementation are. Ultimately, if "component definitions" are simply passed through to assessment and assessment results, then the "component definitions" themselves aren't nearly as meaningful to a risk professional as are other elements of "implementation" and "assessments/assessment results". However, producers of implementation (both the org itself and CSPs/ISVs) may feel it necessary to document everything under the sun for a specific component which could easily detract from the organization's ability to effectively assess risk. The "middle ground", so to speak, is going to be a challenge to figure out ... and we're just talking about the "component definition" in this case.

[wendellpiez]

Sprint 13 Progress September 27 2018

Most work this Sprint on this Issue is represented in notes we have exchanged or not as the case may be. 😁

However we have made progress - so much that I am (now) thinking that the component definition (not the "declaration") might be potentially very small and simple, and most of the work will be done by modeling "capabilities" either/both within the component declaration (not "definition") and/or cross-linked with components.

I am thinking of a "capability map". Components could be either named in line or linked. This would give us a way to connect controls (being addressed/implemented) with the components (and settings) on which they depend. Indexing such a map would provide useful inputs for SSPs such as Control Summaries, tables of responsibilities/roles, configurations, etc.

[anweiss]

09/27/2018

Continuing to prototype with the initial "component definition" mock-up that was developed a couple weeks ago. Added a few comments to that working doc.

[iMichaela]

9/26/2018

This work will continue in Sprint 14. See https://hackmd.io/x43sK8IvSyOhW3no7fdh2w?view for progress.

[trevor-vaughan]

@anweiss Sorry about that, didn't mean to edit the HackMD doc.

Anyway, my comment was:

If something like YAML is proposed for the markup, there really should be a way to 'include' text as well as provide internal cross-references to other components. Otherwise, this is too unweildy for average folks.

This is one of the main issues that I had with OpenControl. The ability to automatically cross-map inside the document and to have an 'include' structure simply wasn't there.

We fell back to ReStructuredText for our docs and I'm hoping that we don't have to do some hybrid munge with OSCAL in the end.

[anweiss]

@trevor-vaughan no worries at all! the YAML is being used purely to provide a human-readable mock up of some potential data elements to be included in those "implementation" sub-layers. And totally agree in that being able to both cross-reference within the document and include text from external sources is definitely something that should be supported.

[trevor-vaughan]

@anweiss I just realized that a concrete example might be useful.

This is what we currently have for one component of the stack (ssh) https://simp.readthedocs.io/en/master/security_mapping/components/ssh/ssh.html and, as you can see, it auto-links back to the referencing policy under each control.

My hope is to be able to link back not only the prose but the technical implementation in a seamless document but that's going to need to be driven by an ability to cobble everything together from disparate sources.

As far as I can tell, this is in line with the 800-18 approach just incredibly tedious if you have to keep it in more than one location.

[anweiss]

This is helpful, thanks! The linking you've described is likely going to be provided by the "component specification" sub-schema as described at a high-level in the notes.

[iMichaela]

10/4/2018

This issue is still in the experimentation phase (@anweiss ) @wendellpiez has some ideas/concerns:

1. can create a small component fast and start piloting
2. XML or JSON might not be the interface of choice for the data that a component needs to capture. Can MD, YAML, etc.
   @anweiss - we need more consensus on the structure first.
   @david-waltermire-nist - we have to start somewhere to address this problem. Tooling can address human's concerns regarding the format.
   We will discuss this issue outside of this meeting by using examples. @anweiss generated example in Comparing JSON examples produced from the metaschema using multiple tools #244, and metashema driven approach is working.
   @anweiss will provide a data set by COB Friday 10/5/2018, that @wendellpiez can use to move forward with the modeling the component.

[anweiss]

Here's some initial mock data based on the "component definition" model from the HackMD notes: https://gist.github.com/anweiss/8afd321b6bf2a9d4e1679657a1b8f2fe ... CC @wendellpiez. I've only included one component and one control for brevity. Some thoughts from my prototyping thus far:

• Both provisioning and validation mechanisms should include some sort of id prop so they can be cross-referenced
• Given that SCAP is a likely option for provisioning and validation mechanisms, constructs that allow for external references should be considered (e.g. refs to data stream, OVAL, XCCDF, etc) CC @david-waltermire-nist ... probably best reserved for discussions related to SCAP 2.0
  • Other provisioning and validation mechanisms should also be allowed
• for implemented parameters, some sort of choice or conditional value should be allowed (as highlighted by the example referencing AC-10 Param 2 which allows for a multi-value constraint)
• I believe itemId was kind of a catch-all for parts, props, etc, but wasn't sure
• value fields should allow for multiple data types as this would potentially allow for somewhat stricter data typing constraints

[brian-ruf]

Updated SSP / Component Diagrams

OSCAL FR-SSP (v4).pdf

[wendellpiez]

Having suggested the name "status" I am now thinking about other possibilities.

• mode="potential" (can do)
• mode="provisional" (should do)
• mode="implementation" (is doing)

Another possibility: applicability='potential' | provisional | implemented'.

If you think 'provisional' doesn't really mean "as provisioned", I will listen.

[brian-ruf]

Thank you @wendellpiez! I like "provisional" and "implemented". I think there were some strong arguments for avoiding the term "potential", which was part of why I was thinking"defined" or "definition".

In any case, I tend to believe clusters of terms like this are more intuitive if they are either all verbs or all nouns. In this case, I think think most suggestions are verbs of being, so I'd like to suggest "defined","provisional", and "implemented", with the grammar test being that you can say something "is defined", "is provisional", or "is implemented".

[wendellpiez]

@brianrufgsa understood: these are hard choices to make especially given the temptations of debates over metaphysics (to say nothing of epistemology).

I like defined | provisional | implemented especially if there is a nice alignment (perhaps nominally enforceable) between (notions of) "provisional" and "is provisioned". Do you have a current feeling regarding the name of the flag?

[brian-ruf]

After a long back and forth in email between me, @wendellpiez, and @iMichaela I'd like to propose the following for the three attribute uses:

@status="definition" for the vendor to indicate what a product/service can do (all possible security settings)

@status="specification" for the various provisioning information that might be provided. (eg. one specification for FISMA Moderate, another for PCI, one for GDRP, etc.)

@status="actual" (or no @status attribute) to indicate the content reflects how the product is actually configured within the given system.

This applies to both the <characteristics> and <satisfaction> elements.

Please note, I believe the use of "specification" here deviates slightly from above. @anweiss are you OK with that change?

[anweiss]

@brianrufgsa works for me

[brian-ruf]

New glitch as I'm working on the Metaschema. To better fit the "big picture", I think I need to reverse the satisfaction and control elements in the component definition.

I think satisfaction should be an element with control and sub-control, so it would look like this:
<control id='ia-2'> <satisfaction> <p>A description of how IA-2 is satisfied by this component.</p> </satisfaction> </control>
The other way causes Metaschema complications (or I'm still novice with our Metaschema to understand how to simplify it.)
Thoughts?
Concerns?

[wendellpiez]

I like your thinking, but how about if we use another name besides `control` even a placeholder for now, so as to avoid complications regarding how "control" is defined in the different layers (schemas)?

[brian-ruf]

Makes sense. Without deviating too far - and in order to keep moving forward - I'll use 'control-satisfaction' instead of 'control'. We can change it later.

[brian-ruf]

After a conversation with Wendell, I plan is now to flatten this and just use "satisfaction" and add an @id attribute, rather than group "control" or "control-satisfaction" elements under "satisfaction". There would just be multiple satisfaction elements at that first level, instead of them being grouped.

There have been several small changes, so I've updated the Component Anatomy diagram and am attaching it here.
OSCAL Component Definition Anatomy (v4).pdf

[brian-ruf]

2/7/2019 - This structure is now represented in the SSP metaschema developed for issue #267.

[anweiss]

I've started to compile a list of ideas for merging the initial component definition prototype with @brianrufgsa's SSP model. Feel free to take a look at https://hackmd.io/VjzeOpEKQoWe_-9uCI6pKg

[brian-ruf]

@anweiss I like there this is going, I'm mostly tracking with you, but wanted to touch on two points:

First I can agree with a component file external to an SSP up to a point. At some point, the actual components are selected and configured. Those details need to be in the SSP. Also, those details will often require a system-specific modification to the generic satisfaction language. That system-specific portion should reside in the SSP, leaving the more generic write-up untouched in the external component file.

Second, parameter values are intended to "fill in the blank" for a requirement statement. Auditors review actual settings against requirement statements.

Your syntax seems to mix a components "actual setting" (which demonstrates compliance) with the requirement statement.

The link is very helpful to auditors; however, re-using the same syntax is dangerous. I think it is important to use clearly different syntax so as to not confuse a requirement of "15 minutes" with the "15" setting that satisfies the requirement.

Somewhat related to the above, my thought process was to capture all the security-relevant settings of a component in the sub-element of within the SSP. This would only include the actual settings, and could be linked to the external file for unused settings/choices.

Putting the two topics together, I see a link to the external component file, and only see the components element in the SSP as containing the system-specific component details (not the entire component definition). To link component settings to parameters, I see something like this:

<components>
   <component id="abc" href="//link/to/external/component/file">
      <!-- origin, validation, and provisioning are referenced in the external file -->
      <characteristics context="implementation">
         <setting id="abc-timeout">
            <value>15</value>
            <unit>minutes</unit>
            <satisfies param-id="ac-2_prm_1" />
            <satisfies param-id="ac-4_prm_2" />
         </setting>
      </characteristics>
      <satisfaction control-id="ac-2" context="implementation">
         <p>This is copied initially from the external component file's generic explanation.</p>
         <p>It is then tailored as needed to describe the implementation in this specific system.</p>
      </satisfaction>
   </component>
</components>

I'd enjoy the opportunity to discuss this further.

[anweiss]

All great points @brianrufgsa and agree with you! I like your proposal above. A lot of context (both system owner context and assessor context) can also be provided by the declarations model.

[david-waltermire]

The concepts in this issue will be document on the OSCAL website in issue #363. Closing this issue.