remove out-of-date information from the site

README.md

@@ -22,3 +22,7 @@ Every deployment includes updates to continuous monitoring.
 > __Compliance as Code.__
 
 The full website is online at [http://opencontrol.xyz](http://opencontrol.xyz).
+
+## Development
+
+This site is generated using [mkdocs](http://www.mkdocs.org/).

docs/faq.md

@@ -1,7 +1,5 @@
 # OpenControl: Questions
 
-<script async class="speakerdeck-embed" data-id="1b3d6494fb12408dbe8f1cfe65eca769" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>
-
 ## What?
 
 What license is this under?
@@ -55,7 +53,7 @@ declaration in Concourse made it a good fit for the semantics of OpenControl.
 Why didn't you use OpenSCAP?
 
 > The Security Content Automation Protocol (SCAP) is developed by the US Government to check for the presence of common vulnerabilities, or secure configurations on common technologies. OpenSCAP and OpenControl are extremely complementary - they are solving different problems. As the name implies, [OpenSCAP](https://github.com/OpenSCAP), a collection of open source SCAP tools provided by Red Hat, is about _automating_ whether or not technologies with SCAP profiles in fact possess the security claims or "benchmarks" provided by [NIST](https://web.nvd.nist.gov/view/ncp/repository) or have common vulnerabilities in [MITRE's database](https://cve.mitre.org/).
-> 
+>
 > If your organization already uses SCAP, OpenSCAP may be a great solution to run those tests, and then output the results to [Compliance Masonry](https://github.com/opencontrol/compliance-masonry), an OpenControl tool. You use Compliance Masonry to map and automation of the _results_ of those tests to the actual compliance documentation, which was always the missing piece from SCAP based systems. SCAP systems still required humans to manually entire information into static documentation. Via Compliance Masonry, OpenControl is [agnostic as to the source of your test results](https://github.com/opencontrol/compliance-masonry#long-term-plan-diagram) and whether not any compliance control is in fact implemented. It maps those controls to tests, and also renders the final compliance documentation.
 >
 > Also of note is that the SCAP standard is [extremely verbose and complex XML](http://scap.nist.gov/schema/scap/1.2/scap-source-data-stream_1.2.xsd). Developers of net-new technologies have usually not written benchmarks in SCAP, and as a result, benchmarks significantly lag behind technological development. By using YAML and creating a more developer focused framework, we hope that secure baselines evolve more quickly in parallel with SCAP enabled enterprise benchmarks provided by NIST.

docs/index.md

@@ -25,14 +25,14 @@ Every deployment includes updates to continuous monitoring.
 
 ## It's a schema.
 
-By adopting a standard approach to documenting "controls" (whether Technical, Operational, or Management) we can rapidly build a community of vendors and operators. You can see [the current (and evolving) OpenControl schema here.](schema)
+By adopting a standard approach to documenting "controls" (whether Technical, Operational, or Management) we can rapidly build a community of vendors and operators. You can see [the current (and evolving) OpenControl schema here](https://github.com/opencontrol/schemas).
 
 ## It's a set of tools and best practices.
 
 Right now we're excited about:
 
- * [Concourse.ci](http://concourse.ci) (see an example at [https://dragon.somegood.org](https://dragon.somegood.org))
- * GitBook (see how 18F has used this to produce the [System Security Plan for Cloud.Gov](https://compliance.cloud.gov))
+ * [Concourse CI](http://concourse.ci)
+ * [GitBook](https://www.gitbook.com/) (see how 18F has used this to produce the [System Security Plan for cloud.gov](https://compliance.cloud.gov))
 
 There are more details about how to use this set of tools to [build a continuous authorization pipeline](pipelines.md).
 
@@ -44,3 +44,9 @@ another schema, and operators who use the OpenControl process to authorize their
 systems.
 
 You can see the [full list of current members here.](members)
+
+## Background
+
+<iframe width="560" height="315" src="https://www.youtube.com/embed/hb3gonG2oFA" frameborder="0" allowfullscreen></iframe>
+
+[slides](https://speakerdeck.com/joshuamckenty/all-things-open-opencontrol)

docs/members.md

@@ -10,11 +10,11 @@ ___
 
 ### Pivotal, Inc.
 #### Product: __Pivotal Cloud Foundry__
-#### OpenControl Repo: [https://github.com/cloudfoundry-community/compliance](https://github.com/cloudfoundry-community/compliance)
+#### OpenControl Repo: [https://github.com/opencontrol/cf-compliance](https://github.com/opencontrol/cf-compliance)
 
 ### Amazon Web Services (via 18F)
 #### Product: __Amazon Web Services__
-#### OpenControl Repo: [https://github.com/18F/cg-controls/tree/master/components/AWS](https://github.com/18F/cg-controls/tree/master/components/AWS)
+#### OpenControl Repo: [https://github.com/opencontrol/aws-compliance](https://github.com/opencontrol/aws-compliance)
 
 ### GovReady BPC
 #### Product: __GovReady Toolkit__
@@ -55,7 +55,7 @@ ___
 
 ### US Government NIST (via 18F)
 #### Product: __NIST 800-53__
-#### OpenControl Repo: [https://github.com/18F/cg-controls/blob/master/standards/NIST-800-53.yaml](https://github.com/18F/cg-controls/blob/master/standards/NIST-800-53.yaml)
+#### OpenControl Repo: [https://github.com/opencontrol/NIST-800-53-Standards](https://github.com/opencontrol/NIST-800-53-Standards)
 
 ___
 Want to join? Simply [submit a pull request](https://github.com/opencontrol/opencontrol.github.io/compare) to this document and add yourself.

docs/pipelines.md

@@ -1,35 +1,13 @@
 # OpenControl Pipelines
 
 Continuous Authorization pipelines can be constructed using the
-open source [Concourse.ci](https://Concourse.ci) tool.
-There is a running example of this at [https://dragon.somegood.org](https://dragon.somegood.org).
+open source [Concourse CI](https://Concourse.ci) tool.
+
 ![OpenControl Pipeline Screenshot](img/screenshot.png)
 
 The [example pipeline is available on github.](https://github.com/opencontrol/example-pipelines)
 
-The notional architecture of the OpenControl pipeline is below.
-![Pipeline Architecture](img/OpenControl%20Architecture.png)
-
 ## Key Tools
 
-OpenControl systems, components and authorizations are defined using YAML. So
-much of the pipeline is simply merging of various YAML files. This is performed
-using a tool called ["Spruce"](https://blog.starkandwayne.com/2015/10/08/introducing-spruce-a-more-intuitive-spiff).
-
-Spruce merges yaml files from left to right, so the template for the system
-authorization will always be listed first. Files of each of the required schemas
-will come next, and finally an "override" file for system-specific controls
-will be merged last. (This file would also include any plan-specific metadata such
-  as Authorizing Official, SSP Author, etc.)
-
-Once a complete system-security-plan (SSP) YAML has been generated, it can be
-transformed into a variety of formats. For human-readable documentation, the YAML
-should be converted to Markdown, and then passed into GitBook. GitBook can output
-HTML, PDF, or various ePUB formats.
-
-Producing configuration for your continuous monitoring tools can be generated directly
-from the SSP YAML, using various python libraries.
-
-Of course, most existing certifications are not yet documented in YAML, but in XML.
-So we use [ComplianceLib from GovReady](https://github.com/govready/compliancelib-python)
-to transform these XML files into YAML.
+* [Compliance Masonry](https://github.com/opencontrol/compliance-masonry)
+* [ComplianceLib](https://github.com/govready/compliancelib-python) — Most existing certifications are documented in XML, and ComplianceLib transforms these into YAML.

mkdocs.yml

@@ -5,6 +5,5 @@ remote_branch: master
 pages:
   - Intro: 'index.md'
   - FAQ: 'faq.md'
-  - Schema: 'schema.md'
   - Pipeline: 'pipelines.md'
   - Members: 'members.md'