Covers work completed in sprint usnistgov#3.

Imported initial SP800-53r4, ISO 276001/2, and COBIT 5 catalog data.
Created initial OSCAL Catalog model.

.gitignore

@@ -1 +1,7 @@
 .DS_Store
+
+# Proprietary files not to be propagated
+vault
+
+*/working/**/*.pdf
+

README.md

@@ -1,33 +1,36 @@
-# OSCAL
-Open Security Controls Assessment Language (OSCAL) 
+# Open Security Controls Assessment Language (OSCAL) 
 
-The Cloud First policy established by the U.S. Federal CIO in December 2010, mandates that agencies take full advantage of cloud computing benefits to maximize capacity utilization, improve IT flexibility and responsiveness, and minimize cost. By 2012, a subsequent report to Congress showed that more than half of all federal agencies had adopted cloud computing for at least one application. The rapid adoption of cloud computing under this mandate is not voiding any of the agencies’ FISMA requirements for adequate security and privacy protection of data. 
-
-NIST is proposing the development of the Open Security Controls Assessment Language, or OSCAL, a hierarchical, formatted, XML-based (and JSON translation) schema that provides a standard for encoding different categories of information pertaining to the security controls’ implementation and assessment process.  
+NIST is proposing the development of the Open Security Controls Assessment Language, or OSCAL, a hierarchical, formatted, XML-based (and JSON translation) schema that provides a standard for representing different categories of information pertaining to the publication, implementation, and assessment of security controls.
 
 OSCAL aims to:
-1.	Standardize the description of a control based upon the standard used (NIST SP 800.53, ISO/IEC 27001/2, PCI, SOX, etc), 
-2.	standardize the reporting format of a security control implementation for a particular ‘technology’ (cloud computing, cyber physical systems, mobile, etc.) – for an Overlay (see NIST SP 800-53 R4 for more details) -  or for a particular ‘scope’ or 'purpose' for which the control is implemented (e.g. the control is implemented for physical access or logical access to a, b, c layers). 
-3.	standardize the format of the documented assessment criteria, 
-4.	standardize the format of the metrics and measurements for the continuous monitoring of the control, and 
-5.	other custom information standardization.
+1. Standardize control, implementation, and assessment information using open, machine-readable formats. 
+1. Normalize the semantics of controls and profiles/baselines/overlays across multiple control catalogs (e.g., NIST SP 800-53, ISO/IEC 27001/2, COBIT 5).
+1. Provide interoperable formats to ensure that OSCAL information is used by tools in consistent ways.
+1. Promote adoption of OSCAL by tool developers by ensuring that OSCAL information is easy to create, use, and customize. 
+
+OSCAL consists of a number of layers:
+
+![OSCAL layers](docs/graphics/oscal-layers.png "OSCAL Layer Diagram")
+
+Starting from the bottom on the left, the OSCAL layers are:
+  * __Catalog__: Defines a set of security controls (e.g., NIST SP 800-53 Appendix F); may also define objectives and methods for assessing the controls (e.g., NIST SP 800-53A).
+  * __Profile__: Defines a set of security requirements, where meeting each requirement necessitates implementing one or more security controls; also called a _baseline_ or _overlay_.
+  * __Implementation__: Defines how each profile item is implemented for a given system component (System Security Plan).
+  * __Assessment__: Describes how the system assessment is to be performed.
+  * __Assessment Results__: Records the findings of the assessment.
+
+OSCAL will also integrate with: 
+  * __Metrics__: Defines metrics and measurements for understanding the effectiveness of the system’s security.
+  * __Mechanism__: Describes methods used to monitor the system’s current security state (e.g., Security Content Automation Protocol (SCAP)).
 
 --------------
-General Notes, 20170313:
-Most recent additions are example xml file and schema extensions for a system-implementation. (MI - ?)
-The system-implementation example includes tags from FedRAMP template and links to another hypothetical document that contains an enumerated list of system components. (MI - ?)
-The component list is included in "attachment 13" of the FedRAMP template; referred to as a component inventory. (MI - ??)
-I am trying (for expedience) to (re)use structures already defined in the OSCAL-core schema.  (MI - ?)
-In system-implementation, statements defined for security control catalog are reused as statements for implementing the security controls. (MI - ?)
-
-NOTES on schema:
-OSCAL-core contains the information structures that are most highly developed
-OSCAL-common contains link definitions and some additional structures to facilitate human readability (MI - ?)
-OSCAL-extensions define information structures outside the core that are unique to specific catalogs or other specifications.
-
-NOTES on processing of guidance information:
-Since the function of profile (overlay) xml documents is to select, augment, and sometimes overwrite requirements/controls, schemas and XML examples require further development in terms of explicit methods for reconciling specific tags that come from multiple sources.  The OSCAL-core schema document defines a RationaleChangeType information object that includes restrictions for augmenting, changing, or scoping-out (eliminating) text.
-
-NOTES on (re)use of authorization bodies of evidence (MI - ?):
-System implementation documents should include a method to capture links to pre-existing bodies of evidence (e.g. a component ID with links to a FedRAMP authorization number) referring that a system or system component has been assessed before.  When accessible, such links are associated with increased levels of trust in the component.  The scope of an assessment process may be greatly reduced by accepting pre-existing bodies of assessment evidence and focusing on assessment of new (untested) or modified components.  Closely related, are component links or aliases to CPE names, SWID names, and other standardized identifiers; which may be associated with known vulnerabilities (e.g. CVEs).
+
+This repository consists of the following directories pertaining to the OSCAL project:
+  * [docs](docs): Documentation graphics, prose, and presentation slides
+  * [working](working): Development artifacts (e.g., XML, XSLT, CSS, script, Markdown, and sample files, plus supporting files); additional documentation is posted under [working/doc](working/doc): 
+  * [sources](sources): Resources used to produce OSCAL artifacts that are not maintained by the OSCAL project (e.g., a copy of the NIST SP 800-53 control data feed schema)
+
+## Update August 10th, 2017
+
+As the result of a new OSCAL initiative undertaken starting in mid-May, this repository has been updated. With this effort, we are stressing the agile development of a *minimal* format that is both generic enough to capture the breadth of data in scope (controls specifications), while also capable of ad-hoc tuning and extension to support peculiarities of both (industry or sector) standard and new control types.