publish: Issue 468 364 478 integration (#492)

generated from commit 6b7360b

.circleci/config.yml

@@ -256,6 +256,7 @@ jobs: # a collection of
       - install-maven-dependencies
       - install-jq
       - install-prettyjson
+      - install-xmllint
       - run:
           name: Generate OSCAL converters
           command: |

assets/css/main.css

@@ -4124,17 +4124,17 @@ div.OM-map p {
   margin: 0ex; }
 
 span.OM-lit {
-  font-family: serif;
+  font-family: 'Source Sans Pro', sans-serif;
   font-weight: normal;
   font-style: normal; }
 
 span.OM-emph {
-  font-family: serif;
+  font-family: 'Source Sans Pro', sans-serif;
   font-weight: normal;
   font-style: italic; }
 
 span.OM-cardinality {
-  font-family: serif;
+  font-family: 'Source Sans Pro', sans-serif;
   font-weight: normal;
   font-style: normal;
   color: #205493; }

docs/index.html

@@ -380,13 +380,88 @@ <h1>The OSCAL Architecture</h1>
 
     <p>In particular, the design of the OSCAL Profile layer, in relation to the Catalog layer, reflects the use of control catalogs as outlined in NIST SP800-53 – specifically the concept of <em>baselines</em> and <em>overlays</em> over a base catalog. And then, as we see in the real world, overlays on the overlays. In OSCAL, <a href="profile">profiles</a> are generalized to be applicable to any set of information presented in catalog form. Thus, the idea of tailoring in application can be applied not only to security guidelines in general, but also in mixed environments that have to address requirements in more than one catalog at a time.</p>
   </li>
-  <li><strong>Implementation:</strong> Defines how each profile item is implemented for a given system component. This can represent a machine-readable system security plan in OSCAL format. It will also support transforms from the machine-readable form to a human-readable version.</li>
-  <li><strong>Assessment:</strong> Describes how the system assessment is to be performed.</li>
-  <li><strong>Assessment Results:</strong> Records the findings of the assessment.</li>
-</ul>
+  <li>
+    <p><strong>Implementation:</strong> Defines how each profile item is implemented for a given system component. This can represent a machine-readable system security plan in OSCAL format. It will also support transforms from the machine-readable form to a human-readable version.</p>
+  </li>
+  <li>
+    <p><strong>Implementation:</strong> The OSCAL implementation layer consists of two models: The component definition (planned) and the system security plan (SSP).</p>
+
+    <p>The <em>component definition</em> model, which is currently under development, will allow for the definition of a set of <em>components</em> that each provide structured information about a distinct hardware, software or services offering; or specific policy, proceedure, or compliance artifact.</p>
+
+    <p>Each defined component describes where appropriate:</p>
 
-<p>As the project <a href="/OSCAL/learnmore/roadmap/">progresses</a>, these definitions are expected to evolve; they are included here to indicate the current status within OSCAL and may not the represent the final definitions for each model.  The above is a high-level explanation of the basic constructs supported by OSCAL. These constructs exist in all OSCAL bindings (e.g., XML, JSON). At this time, the material covers OSCAL controls, catalogs, and profiles. Additional OSCAL constructs will be added as they are developed and matured.</p>
+    <ul>
+      <li>Information about the organization that provides, developes, and manages the thing described by the component;</li>
+      <li>Characteristics of the component, such as its name, version, model, last-modified date, etc;</li>
+      <li>Details about the controls that could be satisfied by the component;</li>
+      <li>Configuration options for achieving specific security or privacy objectives; and</li>
+      <li>Assessment tests or scripts that may be used to validate the component’s implementation.</li>
+    </ul>
+
+    <p>The component definition model will also allow grouping related components into capabilities, and documenting how the combination of components in a capability together could satisfy specific controls that are not fully satisfied by a single component on its own.</p>
+
+    <p>A component can be used to document and share: 1) proof of compliance for a secuirty requirement for hardware or software, such as FIPS 140-2 validated cryptography, 2) to document information about how a hardware, software, or service offering supports specific security or privacy controls, or 3) demonstrate how a policy or proceedure implements a given set of security or privacy controls. These component definitions can be used by organizations implementing the things defined by the component to provide a significant amount of details needed when documenting a systems security and privacy control implemention in a system security plan.</p>
+
+    <p>The SSP model, which has been released as a draft, enables full modeling of highly granular SSP content, including points of contact, system characteristics, and control satisfaction descriptions. At a more detailed level, this includes the system’s authorization boundary, information types and categorization, inventory, and attachments. In terms of control satisfaction, it models control parameter values, responsible roles, implementation status, control origination, and a description of control satisfaction at a level of the granularity down to a specific control statement. Control satisfaction can be defined for the system as a whole or for individual implemented components.</p>
+
+    <p>The component and SSP models are designed to work together. As specific components are selected for use within a system, the content of the relevant component definition files inform and populate the use of these components within the SSP model. The SSP model can also be used to represent systems that do not define information at the granularity of a specific compoent, where component definitions do not exist.</p>
+  </li>
+  <li><strong>Assessment:</strong> Is a planned model that will describe how a system assessment is to be performed.</li>
+  <li><strong>Assessment Results:</strong> Is a planned model that will record the findings of a specific assessment.</li>
+</ul>
 
+<p>The OSCAL layers described above provide a high-level explanation of the OSCAL models. As the project <a href="/OSCAL/learnmore/roadmap/">progresses</a>, the features of these models are expected to evolve; these layer descriptions are included here to indicate the current status of the related models within OSCAL and may not the represent the final features supported by each model. XML, JSON, and YAML formats for each model will be provided when the model is released.</p>
+
+<p>The following is the release state of each model, along with download links for the latest versions of schema for each model in XML and JSON formats. YAML is also supported through conversion between JSON and YAML, but YAML schemas are not yet provided because a suffecient YAML schema language has not been identified.</p>
+
+<table>
+  <thead>
+    <tr>
+      <th style="text-align: left">Layer</th>
+      <th style="text-align: left">Model</th>
+      <th style="text-align: left">State (<a href="/OSCAL/learnmore/roadmap/">Milestone</a>)</th>
+      <th style="text-align: left">Formats</th>
+    </tr>
+  </thead>
+  <tbody>
+    <tr>
+      <td style="text-align: left">Catalog</td>
+      <td style="text-align: left">Catalog</td>
+      <td style="text-align: left">Draft Released (1.0.0 M1)</td>
+      <td style="text-align: left"><a href="https://github.com/raw/usnistgov/OSCAL/master/xml/schema/oscal_catalog_schema.xsd">XML</a>, <a href="https://github.com/raw/usnistgov/OSCAL/master/json/schema/oscal_catalog_schema.json">JSON</a>, YAML</td>
+    </tr>
+    <tr>
+      <td style="text-align: left">Profile</td>
+      <td style="text-align: left">Profile</td>
+      <td style="text-align: left">Draft Released (1.0.0 M1)</td>
+      <td style="text-align: left"><a href="https://github.com/raw/usnistgov/OSCAL/master/xml/schema/oscal_profile_schema.xsd">XML</a>, <a href="https://github.com/raw/usnistgov/OSCAL/master/json/schema/oscal_profile_schema.json">JSON</a>, YAML</td>
+    </tr>
+    <tr>
+      <td style="text-align: left">Implementation</td>
+      <td style="text-align: left">Component Definition</td>
+      <td style="text-align: left">Under Development (1.0.0 M3)</td>
+      <td style="text-align: left"><a href="https://github.com/raw/usnistgov/OSCAL/master/xml/schema/oscal_component_schema.xsd">XML</a>, <a href="https://github.com/raw/usnistgov/OSCAL/master/json/schema/oscal_component_schema.json">JSON</a>, YAML</td>
+    </tr>
+    <tr>
+      <td style="text-align: left">Implementation</td>
+      <td style="text-align: left">System Security Plan</td>
+      <td style="text-align: left">Draft Released (1.0.0 M2)</td>
+      <td style="text-align: left"><a href="https://github.com/raw/usnistgov/OSCAL/master/xml/schema/oscal_ssp_schema.xsd">XML</a>, <a href="https://github.com/raw/usnistgov/OSCAL/master/json/schema/oscal_ssp_schema.json">JSON</a>, YAML</td>
+    </tr>
+    <tr>
+      <td style="text-align: left">Assessment</td>
+      <td style="text-align: left">Assessment Plan</td>
+      <td style="text-align: left">Planned (2.0.0)</td>
+      <td style="text-align: left">XML, JSON, YAML</td>
+    </tr>
+    <tr>
+      <td style="text-align: left">Assessment Results</td>
+      <td style="text-align: left">Assessment Results</td>
+      <td style="text-align: left">Planned (2.0.0)</td>
+      <td style="text-align: left">XML, JSON, YAML</td>
+    </tr>
+  </tbody>
+</table>
 
 
 </div>

docs/profile/index.html

@@ -352,7 +352,7 @@ <h1>Profile</h1>
 <ul>
   <li>Which controls are <em>selected</em> from the catalog and thereby considered to be in scope for the application;</li>
   <li>How the control selection should be <em>organized</em> and represented, including whether and how competing control definitions are to be resolved and merged;</li>
-  <li>Whether and where any controls are to be <em>configured</em> or modified; this includes setting parameter values for a catalog but also potentially amending the language given in controls and subcontrols, to describe their application in the system.</li>
+  <li>Whether and where any controls are to be <em>configured</em> or modified; this includes setting parameter values for a catalog but also potentially amending the language given in controls to describe their application in the system.</li>
 </ul>
 
 <p>See <a href="/OSCAL/resources/examples/profiles/">examples</a> of OSCAL profiles.</p>