Cleanup NIST SP800-53 R4 catalog and low/moderate/high profiles

[akarmel]

User Story:

As an OSCAL consumer that needs 800-53 data, I have an accurate and usable OSCAL catalog and profiles for each 800-53 baseline (low/moderate/high).

Goals:

1. Improve the data quality of the 800-53 catalog and profiles (@wendellpiez)

   • Design, document and implement a clean ID naming scheme

     The following format will be used for IDs

     {control-id|subcontrol-id}{part}{outline level}

     [part] - smt (statement), obj (Assessement Objectives), prm (Parameter)

     Examples:
     ac-1_smt_a
     ac-1_smt_a.1
     ac-1_smt_a.1
     ac-2.6_obj_a
     ac-2.6_obj_a.1
     ac-1_prm_1
     ac-1.1_prm_1

     • No terminal dots
     • Use outline level letters and/or numbers (in lowercase) separated by dots
     • Implicit number for top level objectives will use letters explicitly.
     • Underscores will separate fields

   • Support the following parameter fields:

     • label (1)(required) - text from SP800-53rev4
     • desc (0-to-many:catalog + profile) - a textual description of the parameter
     • requirement (0-to-1:profile) - A textual description of a constraint on the allowed values (e.g., every 3 months)
     • value (0-to-1:catalog + profile) - The actual value(s) to be used for the parameter.

   • Create parameter entries for selection parameters using the valid values as the label

   • Remove baseline impact and priority properties out of current controls

     • Data should be moved to the respective 800-53 low/moderate/high profiles
     • Use add to append a property to the control in the respective profile

   • Establish link relationships for all link elements in the 800-53 catalog

     Example: <link rel="related" href="#ac.3"/>

   • Design a reference list within the catalog model and move all document references to use this new feature

     • This feature must minimally capture the same information that is captured under the same citation

     Example: <link rel="reference" href="#ref1"/>

2. Review updated 800-53 catalog and profile for any remaining anomalies (@iMichaela)
   • Cleanup any paragraph or other anomalies

Dependencies:

None.

Acceptance Criteria

• All content changes defined under the goal 1 have been made
• All anomalies identified during team reviews under goal 2 have been fixed

[wendellpiez]

There are a bunch of Unicode "replacement characters" \u65533 (�) in the NVD source; these must be found and fixed. (Most seem to be an error for a right-facing quote or other "upper ASCII" character. If systematic (if this is due for example to an ISO8859-1 file being parsed as Unicode) it could be corrected in the parse. If not, some hand work is required.

[wendellpiez]

Testing shows if it's a garbled parse, it is unfortunately upstream from the NVD XML, so we will have to disambiguate and map these characters. (There appear to be 36 of them total.)

[iMichaela]

04/26/2018 - Sprint 10 Progress Report
Goal: Review updated SP800-53 catalog and profile for any remaining anomalies
Progress: Waiting for the dependencies to be completed (goals 1)
Complete: 0%
Open Issues: none at this time

[brian-ruf]

4/26: Based on a conversation between Wendell, Peter, and myself (Brian), we provided a recommendation to Michaela and Dave that we adopt FedRAMP's parameter IDs for standardized parameter IDs in OSCAL.

[wendellpiez]

4/26/2018 Sprint 10 Progress Report

Goal: Improve the data quality of the 800.53 catalog and profiles
Progress: We have sketched out methods and identified (some or most) problem areas
Complete: 5%
Open Issues: @david-waltermire-nist and I should complete a list of known issues in the data, with proposed solutions, enabling me to update the (NVD XML -> OSCAL) extraction pipeline to reflect these changes. We plan to do this either tomorrow 4/27 or early next week. This will give us something to circulate for validation/verification and exposure of still-unknown issues.

[david-waltermire]

We discovered that selection parameters are not supported in the current SP 800-53r4 catalog examples. This pertains to issue #66. @wendellpiez is going to sketch and implement this feature before we meet the week of 4/30.

[wendellpiez]

5/2/2018 Sprint 10 Progress Report

Goal: Improve the data quality of the 800.53 catalog and profiles
Progress: Now through the punchlist: everything has been addressed, including modeling selection parameters
Complete: catalog: 85%; profiles 0% (much smaller job)
Open Issues: Newly generated file in my repo needs to be reviewed for completeness and correctness

The NVD XML->OSCAL extraction/enhancement pipeline currently produces the following output running over rev4:
https://raw.githubusercontent.com/wendellpiez/OSCAL/feature-datamapping/working/SP800-53/SP800-53rev4-OSCAL-current.xml

A 'publish' directory also placed there (temporarily) also shows the catalog in HTML (selection parameters not yet supported)

Needs:

• review by @iMichaela , @david-waltermire-nist and stakeholders for correctness and completeness;
• review with @david-waltermire-nist of adherence and (slight) adjustments to specs;
• review by the team regarding the modeling and expression of ID values, links and references, and (new!) selection parameters

NB @brianrufgsa I put pointers in the parameter labels to their points of insertion. As of yet they are still one-to-one. If they can be refactored now is the time to think about it. (BTW, parameters can now link to parameters by way of the selection mechanism. So that could be useful.)

What I did (quick summary): updated ID assignments; removed unneeded properties; added link relations; rewrote references as links to a 'references' tail section; implemented selection parameters including models and data extraction (including quasi-parsing of nested parameters in text inputs); mapped and handled character problems in a "correction" XSLT

Once the changes are accepted we need new Issues (tasks) on updating schema docs, XSLTs and CSS.

Note also 0% on updating the SP800-53 baselines, which come next.

[brian-ruf]

5/2: Matched all labels to parameters in accordance with naming convention. (100%) Nearly complete decomposing nested parameters. (80%) Working in database with plan to export to XML for incorporation in 800-53 catalog and High, Moderate, Low baselines.

[david-waltermire]

I just integrated our notes from the engineering meeting into the user story.

[david-waltermire]

@brianrufgsa Just to be clear, are you are working towards adding content to the FedRAMP profiles not modifications to the SP 800-53rev4 profiles?

[wendellpiez]

@david-waltermire-nist actually that is an important point, since the parameter labels and descriptions currently show hooks for @brianrufgsa, but perhaps do not (in the form given) belong in a published catalog.

Cleaned-up and proper values for the catalogs is a different question from the FedRAMP values. The info here is useful, and we can pull it out (into a profile layer), but maybe we also need (separate question) canonical descriptions and labels for parameters in the catalog (the SP800-53 baselines have no parameter assignment/modification tmk).

[brian-ruf]

@david-waltermire-nist,

I can't fully accomplish the FedRAMP piece without the parameter references. I pro-actively went ahead and assigned them via a script, following our convention. Let's discuss today after we get through status. If we don't want/need what I'm doing for the 800-53 parameters, that's fine. It still helps me make progress on the FedRAMP work.

[david-waltermire]

@wendellpiez The PR in #158 does not show the progress you are reporting. Did you leave out committing the SP 800-53rev4 catalog updates in this branch?

[iMichaela]

5/2/2018 - Sprint 10 Progress Report
Goal: Review updated SP800-53 catalog and profile for any remaining anomalies
Progress:
1. Started reviewing NVD XML->OSCAL output file per @wendellpiez 's request
2. Waiting for the dependencies to be completed.
Complete:
1. 40%
2. 0%
Open Issues: none at this time

[wendellpiez]

5/9/2018 Sprint 10 Progress Report

Goal: Improve the data quality of the 800.53 catalog and profiles
Progress: Now through the punchlist: everything has been addressed, including modeling selection parameters
Complete: catalog: 100%; profiles 100%
Open Issues: Files need to be sanity checked; also exposed is a potential issue with regularity of IDs assigned to SP800-53 objectives. (See below. Currently the IDs are regular, but they show that the represented numbers of the objectives, are not.)

The PR includes miscellaneous schema updates as well as corrected samples for SP800-53.

Exposed by the ID normalization is an issue with irregularities in the represented numbering of objectives. (Statements look okay.) So the generated ID is aligned with numbering given on the components inside some controls, but not others.

not aligned:

<part class="objective" id="ac-1_obj_a.1.">
                  <prop class="name">AC-1(a)(1)[1]</prop> ...

aligned:

<part class="objective" id="si-6_obj_a.">
               <prop class="name">SI-6(a)</prop> ....

probably more are not aligned, than aligned. I am not sure this is a concern.

An alternative would be to rewrite these IDs systematically off the given names (instead of basing them on the given hierarchy): they would still function as IDs for linking purposes. So objective AC-1(a)(1)[1] would have id=ac-1_obj_a.1.1 while SI-6(a) would have id=si-6_obj_6.a (notwithstanding the fact that the schemes are different). This could help prevent surprise and confusion.

[david-waltermire]

@wendellpiez I would prefer to have the hierarchy be correct and to base the labels off of that., We may need to add markup to set what label value to use.

[wendellpiez]

May 14 Sprint 10 Progress Report

See PR #163 comments for more detailed notes tracking the remaining issues. Thanks to @david-waltermire-nist and @brianrufgsa for help here.

Issues have now been resolved (as tracked on that page) while a couple have spun out to modeling issues (and will be noted and entered as such). A couple of new enhancements have also been made.

Progress: catalogs 100%; profiles 100%

For inspection at https://github.com/wendellpiez/OSCAL/tree/master/examples/SP800-53:

• SP800-53-rev4-catalog.xml SP800-53 catalog
  • special attn to id values (whether clean/correct)
  • also control, subcontrol and group titles (converted to title case)
  • new 'selection' parameter support
  • other abbreviations and improvements
• Next to it, three profile XML documents, one for each baseline, as declared in NVD source
  • Control Priority is now represented in the profile (as a patch/amendment), not the catalog

[iMichaela]

@wendellpiez Would the task of creating hierarchically correct IDs be easier if the control's ID is inherited fully and the 'obj' appears as a prefix? So objective AC-1(a)(1)[1] would have id=obj_ac-1.a.1.1 and objective SI-6(a) would have id=obj_si-6.a.

[iMichaela]

5/17/2018 - Sprint 10 Progress Report
Goal: Review updated SP800-53 catalog and profile for any remaining anomalies
Started reviewing, per @wendellpiez comment above, the SP800-53-rev4-catalog.xml SP800-53 catalog at: https://github.com/wendellpiez/OSCAL/tree/master/examples/SP800-53
Findings:

1. control class id is formated using period (e.g. ) and not a dash (e.g. )
2. param IDs are formatted using underscore (e.g. ) and not a period (e.g )
3. item IDs have trailing periods that need to be removed:
4. more trailing periods in all sub-statements:
5. Trailing periods in the AC-1a.1.
6. [OK, NOTED]: objective IDs do not follow the user story desciption (see above), but rather what I suggested in my comment above. Not sure if the initially decided approch changed during previous meeting I missed. We need consistency with all statements and parameters IDs.
7. objective's class name: AC-1(a)(1) is not consistent with the control's class name : AC-1a.1.. One uses parenthesis while the second uses periods
8. objective IDs have trailing periods (e.g. ; )
9. some objective IDs start with obj_ (e.g.) while others start with s_obj_
   NOTE: All findings listed above persist within all other controls
   Complete:

1. (catalog) 100%
2. (profiles) 0%
   Open Issues: none at this time

[wendellpiez]

@iMichaela Nope, in this case producing either value (for a synthetic identifier) is the same amount of effort.

Unfortunately the current best example for examination is not in the master branch of my repo. Ouch! My apologies for that: I provided the wrong link. Check https://github.com/wendellpiez/OSCAL/tree/feature-800-53-refactor/examples/SP800-53

[david-waltermire]

@wendellpiez The references are still located at the bottom of the catalog document. The rest of the catalog looks good from what I can see. Not 100% done, but maybe 99%.

[wendellpiez]

I did the references! Checking myself now -- oops they were done but not copied over now see wendellpiez@52db08b

[iMichaela]

** 5/24/2018 Sprint 10 Progress Report **
Propose discussing the following issues to determine if the implementation is done per designe:

Goal: Review updated SP800-53 catalog and profile for any remaining anomalies
(catalog) 100%
(profiles) 100%
Open Issues: none at this time

[david-waltermire]

@iMichaela Regarding your comments above:

1. The titles in the OSCAL catalog appear to be correct. The are not concatenated as in SP 800-53 rev4. I searched for a case where they might be and could not find any. Please post an issue with specific instances if you find any.
2. We have issue Document Use of Parameters in Catalog and Profile models #190 to address better documentation on the use of parameters. The label use in your second and third examples is correct, but not well documented. The first example is a problem that we need to resolve, since the label there does not add any value. I have created issue Fix malformed and redundant parameter content #191 to address this.
3. We have not attempted to structure parameters in objectives. Not sure what else to do here at this point in time as we do not have a need to do more given our current scope. If you'd like work done on this, please create a user story that requests the desired functionality. Please include some use cases for how these parameters will be used to help with the design.
4. The assessment "objects" are currently being modeled as a list. Not sure what else to do here at this point in time as we do not have a need to do more given our current scope. Maybe more can be done when we get into assessment. Do you have a user story in mind? If so, would you post one?

[iMichaela]

@david-waltermire-nist Regarding your comments above:

1. • I have no strong opinion about the concatenation to match the original document - I just listed it as different while reviewing the OSCAL catalog

If the team disagrees with me, I respect it, but I would like us to give a full consideration to the problem. I will create an issue after further discussing it.
3 & 4.- that is fine as long as the documentation properly describes that the elements of the are choices to select from. I personally think treating the objectives' parameters similar to the controls' parameter will better support the assessment layer when a selection will have to be made and documented how will it be performed.
If the team disagrees with me, I respect it, but I would like us to give full a consideration to this problem. I will create an issue after further discussing it.

[wendellpiez]

With apologies if this is unhelpful, here's some (not beginner-level) XPath (evaluated over the current SP800-53 catalog XML):

//control[@id='ac-11']/title returns "Session Lock"
//control[@id='ac-11']/string-join((parent::*/title,title),': ') returns "Access Control: Session Lock"

So the values can be calculated for display.

With regard to the second question, we now actually have two questions:

1. Whether to make label optional (after all) sc Fix malformed and redundant parameter content #191;
2. Whether to give "SELECTION" and "ASSIGNMENT" explicitly as labels in SP800-53.

I think any consistent solution is fine but I note also (in case this helps address your concern @iMichaela) that in the SP800-53 data (XML version), an XPath expression //param[select] returns only the parameters offering selections, whereas //param[empty(select)] returns only the parameters that don't. So the labels too could be dynamically generated.

Agree that it would be awesome to see functional requirements regarding all and any special structures in SP800-53 -- this kind of thing can be low-hanging fruit 🍌 🍎 🍐 for implementation, and can showcase the advantages of machine readability.