Covers work completed in sprints #4 and #5.

Created Profile model prototype.
Created Catalog and Profile model documentation.
Imported initial FedRAMP profile,data.
Updated SP800-53r4, ISO 276001/2, and COBIT 5 catalog data.
Created a bunch of OSCAL examples.

README.md

@@ -1,36 +1,12 @@
 # Open Security Controls Assessment Language (OSCAL) 
 
-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 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)).
-
---------------
+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. 
 
 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.
+See [docs/prose/OSCAL-Overview.md](docs/prose/OSCAL-Overview.md) for an introduction to OSCAL and [docs/schema/oscal-tag-library.md](docs/schema/oscal-tag-library.md) for detailed information on the OSCAL data models and XML schema compositions.
 
+As the result of a new OSCAL initiative undertaken in May 2017, this repository was updated in August 2017. 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.

docs/README.md

@@ -0,0 +1,11 @@
+# OSCAL Documentation Materials
+
+This part of the repository contains OSCAL documentation and related supporting files.
+
+The 'docs' subdirectory contains the following:
+
+ * '[graphics](graphics)' - graphics files for reference by OSCAL documentation, and source files for generating particular graphics
+ * '[presentations](presentations)' - Microsoft Powerpoint slides for OSCAL presentations, some with notes
+ * '[prose](prose)' - Prose files (e.g., Markdown format) with narrative on OSCAL (OSCAL overview, how-to steps, etc.)
+ * '[schema](schema)' - OSCAL schema documentation, as further detailed in [schema/readme.md](schema/readme.md)
+

docs/prose/OSCAL Overview.md → docs/prose/OSCAL-Overview.md

@@ -5,9 +5,9 @@ This is an overview of the Open Security Controls Assessment Language (OSCAL). I
 
 Before discussing OSCAL, it is important to define three key OSCAL terms:
  * *Control*: A safeguard or countermeasure designed to satisfy a set of defined security and/or privacy requirements. While this is based on the NIST Special Publication (SP) 800-53 definition of "control", in the context of OSCAL it refers to a similar kind of requirement from a control catalog. 
- * *Catalog*: A set of security control definitions. Examples include the hundreds of controls in NIST SP 800-53, the 100+ controls in ISO 27002, and the practices in COBIT 5. 
- * *Profile*: A set of security requirements; also called a baseline or overlay. Examples include the control baselines in NIST SP 800-53, the FedRAMP baselines, and the PCI DSS requirements. A profile is basically selecting a set of security requirements from one or more control catalogs.
-
+ * *Catalog*: A set of security control definitions. Examples include the hundreds of controls in NIST SP 800-53 Revision 4 Appendix F, the 100+ controls in ISO 27002, and the practices in COBIT 5. 
+ * *Profile*: A set of security requirements, where meeting each requirement necessitates implementing one or more security controls. Also called a baseline or overlay. Examples include the control baselines in NIST SP 800-53, the FedRAMP baselines, and the PCI DSS requirements.
+ 
 ## Major challenges in security controls assessment
 
 OSCAL is attempting to address a number of challenges around security controls and security controls assessment. The core challenge, and one of the primary reasons for creating OSCAL, is that concepts like security controls and profiles are represented today largely in proprietary ways. In many cases they are written in prose documents that are imprecise, lead to differences in interpretation, and are not machine-readable, meaning that the prose instructions require someone to do data entry into a tool in order for the tool to use the information. 
@@ -29,9 +29,9 @@ The plans for OSCAL involve seven components, as depicted in the following diagr
 ![OSCAL layers](/docs/graphics/oscal-layers.png "OSCAL Layer Diagram")
 
 Here are the current definitions for each component. As the project progresses, these definitions may evolve. They are included here to indicate the overall body of work for OSCAL and not the finalized details of each component.  
- * *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). Combining assessment objectives and methods with security controls has been done because some control catalog formats, such as COBIT 5, address assessment information directly. Others have it separately, like 800-53A. Including assessment objectives within the OSCAL catalog model simplifies the entire OSCAL operational model.
- * *Profile*: Defines a set of security requirements, where meeting each requirement necessitates implementing one or more security controls. The profile format will allow for selecting security controls using a number of different mechanisms as well as tailoring those controls (e.g., assigning parameter values, modifying requirements). A profile can include controls from more than one catalog, so an organization could have a single profile that references controls from several catalogs.
- * *Implementation*: Defines how each profile item is implemented. 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.
+ * *Catalog*: In addition to defining a set of security controls, may also define objectives and methods for assessing the controls (e.g., NIST SP 800-53A). Combining assessment objectives and methods with security controls has been done because some control catalog formats, such as COBIT 5, address assessment information directly. Others have it separately, like 800-53A. Including assessment objectives within the OSCAL catalog model simplifies the entire OSCAL operational model.
+ * *Profile*: The profile format will allow for selecting security controls using a number of different mechanisms as well as tailoring those controls (e.g., assigning parameter values, modifying requirements). A profile can include controls from more than one catalog, so an organization could have a single profile that references controls from several catalogs. For more information on the relationship between profiles and catalogs, see [Profile-Catalog-Relationship.md](Profile-Catalog-Relationship.md).
+ * *Implementation*: 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.
  * *Assessment*: Describes how the system assessment is to be performed.
  * *Assessment Results*: Records the findings of the assessment.
  * *Metrics*: Defines metrics and measurements for understanding the effectiveness of the system’s security. 
@@ -52,14 +52,6 @@ Standardized OSCAL catalog and profile models should also be beneficial to sever
  * *Auditors/assessors*: perform audits/assessments on demand with minimal effort
  * *Policy personnel*: identify systemic problems that necessitate changes to organization security policy
 
-## The relationship between the OSCAL catalog and profile models
-
-To understand the relationship between the OSCAL catalog and profile models, consider the trivial conceptual example in the figure below. This example represents the NIST SP 800-53 low baseline. The catalog defines the possible security controls within the scope of NIST SP 800-53. The profile indicates which security controls from the catalog are required to be compliant with the low baseline. Using OSCAL formats for the catalog and profile makes the mappings between the catalog and the profile explicit and machine readable. 
-
-![trivial_example](/docs/graphics/profile-catalog-mapping-trivial-example.png "Trivial Example of Profile and Catalog Mapping")
-
-OSCAL provides a standarized, machine-readable profile with clear semantics. OSCAL allows profiles to be generated using the same interoperable format regardless of the underlying catalogs that are being used, like ISO 27001/2 and COBIT 5. 
-
 ## OSCAL deliverables
 
 The OSCAL project is producing several types of deliverables, including the following:

docs/prose/Profile-Catalog-Relationship.md

@@ -0,0 +1,7 @@
+# The relationship between the OSCAL catalog and profile models
+
+To understand the relationship between the OSCAL catalog and profile models, consider the trivial conceptual example in the figure below. This example represents the NIST SP 800-53 low baseline. The catalog defines the possible security controls within the scope of NIST SP 800-53. The profile indicates which security controls from the catalog are required to be compliant with the low baseline. Using OSCAL formats for the catalog and profile makes the mappings between the catalog and the profile explicit and machine readable. 
+
+![trivial_example](/docs/graphics/profile-catalog-mapping-trivial-example.png "Trivial Example of Profile and Catalog Mapping")
+
+OSCAL provides a standarized, machine-readable profile with clear semantics. OSCAL allows profiles to be generated using the same interoperable format regardless of the underlying catalogs that are being used, like ISO 27001/2 and COBIT 5.