While the current community is small and primarily focused on their day to day work; the concept/appeal/potential of Open Control is immense. Open Control (to me atleast) establishes the fundamental concept needed to make compliance-as-code a reality; in that it takes a "component" first/focused approach to the component <-> control relationship.

My hope with the issue is to discuss the current and potential scope/domain of OpenControl. Highlight some potential areas where it could be expanded to be more functional/practical for use as compliance-as-code that could generate a documentation needed for traditional SSP/Auditor needs.

Control References

Currently OpenControl is limited to mapping to NIST 800-53 controls, for standard SSP(s) and FEDRAMP usage this is sufficient but the schema should address other control regimes like some of those referenced in various SCAP content:

    References:
      oval:    # OVAL vulnerability ID
      cce:     # CCE vulnerability ID
      nist:     # NIST-800 Control ID
      disa:    # DISA STIG ID
      cis:      # Center for Internet Security ID
      ossrg:  # General Purpose Operating System SRG
      ?pci:     # Payment Card Industry Data Security Standard (PCI DSS)
      ?hipaa: # Health Insurance Portability and Accountability Act
      ?sox:    # Sarbanes-Oxley Act of 2002 (SOX)

See issue on OpenScap Security Guide

Topology

System Interconnections, relationships, and architecture are hard to define in code but it is an essential need to bridge the gap between actual system architecture and its security documentation.
While difficult I think there is atleast one open standard that does this well. OASIS TOSCA specification/standard was created for application stack portability across cloud providers; one aspect of it is how it manages to codify topology using a relationship/node model:

1. Each "component" self identifies as a nodeType or capabilities.
2. Each "component" then declares its relationship to other components throughrelationships.

Reference Architecture

How to manage/combine controls when inheriting/applying controls to/from various levels within the architecture?
IDEA
level: Infrastructure, Platform, Software, Others? (Monitoring, Security, etc.)

Components & Policies

How to manage components and policies in yaml, as currently Policies are handled else where as Markdown or Word Documents?
IDEA
type: Component, Policy

People/Organizations/Roles

Fundamental to SSP(s) is who's responsible and "separation of duties". How could OpenControl best handle hybrid component ownership/maintenance models. Also how could traditional roles/responsibilities be integrated into documentation for boundary accreditation/inheritance and the like?

Ports/Protocols/Inventories

These are other common data points within an SSP too?

This last one is the most obvious example of overlap with config management; but all of the items above are examples of whereby expanding the scope/domain of OpenControl would overlap and/or be redundancy with actionable Configuration Management and Automation solutions like (just an off the cuff list):

• Ansible
• BOSH
• Brooklyn (Apache)
• Capistrano
• CFengine
• Chef
• Docker
• Fabric
• Puppet
• Saltstack
• Terraform
• TOSCA (OASIS / Openstack Heat)

So I think one fundamental Question for the OpenControl model, is how it can best serve as that overlay for documentation but then be extendable/pluggable/mappable/etc to these various solutions rather then requiring redundancy in data points.

I know this issue is all over the place but I think aside from the governance policy discussion #5 this is a major unknown and may lead to others thinking OpenControl is/will be something that it is not...

Hi All,

I took a look at Open Control in the past and really wanted to like it but it was just too unweildy for what I needed.

I would like to work to get Open Control into SIMP (https://github.com/NationalSecurityAgency/SIMP or https://github.com/simp).

Our present security documentation is generated from RestructuredText since that was easier for our users to deal with overall and is automatically processed by ReadTheDocs. The latest version can be found at http://simp.readthedocs.io/en/master/security_conop/index.html and http://simp.readthedocs.io/en/master/security_mapping/index.html. This is generated from https://github.com/simp/simp-doc.

The last time we used Open Control, we found the following limitations:

1. Inability to link between sections promoting a great deal of copy/paste text

2. Inability to link directly to the referencing documentation

3. Inability to have easy overrides of sections

   • our approach is clunky, but seems to work easily for users

4. Inability to compose the SSP from an application point of view

   • We have over 100 individual modules controlling a large number of items across the system. We need some way to embed only the controls that are relevant to that module inside of that module (or another referencing module) and then compose all of those parts into a single document
   • I'll freely admit that this might be a huge oversight on my part
   • We also fail at this right now, but it's an ultimate goal of the project

5. Ability to run without connectivity to the Internet

   • The documentation can be generated offline but I'm missing how to hook the various compliance checks to an internal system of my choosing (GitLab, Bamboo, whatever...)

6. Inability to output to something that we could easily import to ReadTheDocs (RestructuredText)

We've recently added the ability to actually validate that our Puppet code parameters are correct per policy and we have a prototype working that will let us switch our entire parameter sets from a given policy to another at the change of a single variable.

Additionally, we're starting to work with the Inspec team from Chef to integrate Inspec directly into our acceptance testing framework.

Since we're pushing forward with so many compliance-focused components, it seemed like a good time to reach out and see if Open Control is right for the project.

Thanks in advance!

Right now we have the FedRAMP-Certifications repo. I'd like to expand the certifications to cover things like FISMA and 800-171/Controlled Unclassified.

One option would be to create multiple new repos, e.g. opencontrol/fisma-certifications, opencontrol/cui-certifications, but that seems unmanagable and slightly annoying.

Should a opencontrol/certifications be created instead?

e.g.

opencontrol/certifications
---- FedRAMP-low.yaml
---- FedRAMP-mod.yaml
---- FedRAMP-high.yaml
---- cui.yaml
---- etc

Has been incorporated into https://github.com/opencontrol/standards for over a year

NIST has done a relatively great job (IMHO) of translating/mapping the RMF to NIST-800-53 through the NIST Framework for Improving Critical Infrastructure Cybersecurity

Considering the highlevel controls are already mapped we should be able to parse out control enhancements `i.e. those additional questions based on whether a system is Low/Moderate/High) to their root control and map that back to the framework as a way to assess how a system is addressing RMF using the mappings provided by NIST

For reference only on existing control mappings:
https://gist.github.com/JJediny/65438415b5e38ac7560ad5f5597f1877

Updated: 1/13/2017 - Updated with Draft v1.1 https://www.nist.gov/cyberframework/draft-version-11
NIST CSF has three levels: Function -> Category -> Subcategory
###################
#  Subcategory  # 
###################
-
   Category: ID.AM
   Subcategory: 1
   Description:  Physical devices and systems within the organization are inventoried
   Component: 
   Control:
   - CM-8
-
   Category: ID.AM
   Subcategory: 2
   Description:  Software platforms and applications within the organization are inventoried
   Component:
   Control:
   - CM-8
-
   Category: ID.AM
   Subcategory: 3
   Description:  Organizational communication and data flows are mapped
   Component:
   Control:
   - AC-4
   - CA-3
   - CA-9
   - PL-8
-
   Category: ID.AM
   Subcategory: 4
   Description:  External information systems are cataloged
   Component:
   Control:
   - AC-20
   - SA-9
-
   Category: ID.AM
   Subcategory: 5
   Description:  Resources (e.g., hardware, devices, data, time, and software) are prioritized based on their classification, criticality, and business value
   Component:
   Control:
   - CP-2
   - RA-2
   - SA-14
-
   Category: ID.AM
   Subcategory: 6
   Description:  Cybersecurity roles and responsibilities for the entire workforce and third-party stakeholders (e.g., suppliers, customers, partners) are established
   Component:
   Control:
   - CP-2
   - PS-7
   - PM-11 
-
   Category: ID.BE
   Subcategory: 1
   Description:  The organization’s role in the supply chain is identified and communicated
   Component:
   Control:
   - CP-2
   - SA-12
-
   Category: ID.BE
   Subcategory: 2
   Description:  The organization’s place in critical infrastructure and its industry sector is identified and communicated
   Component:
   Control:
   - PM-8
-
   Category: ID.BE
   Subcategory: 3
   Description:  Priorities for organizational mission, objectives, and activities are established and communicated
   Component:
   Control:
   - PM-11
   - SA-14
-
   Category: ID.BE
   Subcategory: 4
   Description:  Dependencies and critical functions for delivery of critical services are established
   Component:
   Control:
   - CP-8
   - PE-9
   - PE-11
   - PM-8
   - SA-14
-
   Category: ID.BE
   Subcategory: 5
   Description:  Resilience requirements to support delivery of critical services are established for all operating states (e.g. under duress/attack, during recovery, normal operations)
   Component:
   Control:
   - CP-2
   - CP-11
   - SA-14
-
   Category: ID.GV
   Subcategory: 1
   Description:  Organizational information security policy is established
   Component:
   Control:
   - All
-
   Category: ID.GV
   Subcategory: 2
   Description:  Information security roles & responsibilities are coordinated and aligned with internal roles and external partners
   Component:
   Control:
   - PM-1
   - PS-7
-
   Category: ID.GV
   Subcategory: 3
   Description:  Legal and regulatory requirements regarding cybersecurity, including privacy and civil liberties obligations, are understood and managed
   Component:
   Control: 
   - All
-
   Category: ID.GV
   Subcategory: 4
   Description:  Governance and risk management processes address cybersecurity risks
   Component:
   Control:
   - PM-9
   - PM-11
-
   Category: ID.RA
   Subcategory: 1
   Description:  Asset vulnerabilities are identified and documented
   Component:
   Control:
   - CA-2
   - CA-7
   - CA-8
   - RA-3
   - RA-5
   - SA-5
   - SA-11
   - SI-2
   - SI-4
   - SI-5
-
   Category: ID.RA
   Subcategory: 2
   Description:  Cyber threat intelligence is received from information sharing forums and sources
   Component:
   Control:
   - PM-15
   - PM-16
   - SI-5
-
   Category: ID.RA
   Subcategory: 3
   Description:  Threats, both internal and external, are identified and documented
   Component:
   Control:
   - RA-3
   - SI-5
   - PM-12
   - PM-16
-
   Category: ID.RA
   Subcategory: 4
   Description:  Potential business impacts and likelihoods are identified
   Component:
   Control:
   - RA-2
   - RA-3
   - PM-9
   - PM-11
   - SA-14
-
   Category: ID.RA
   Subcategory: 5
   Description:  Threats, vulnerabilities, likelihoods, and impacts are used to determine risk
   Component:
   Control:
   - RA-2
   - RA-3
   - PM-16
-
   Category: ID.RA
   Subcategory: 6
   Description:  Risk responses are identified and prioritized
   Component:
   Control:
   - PM-4
   - PM-9
-
   Category: ID.RM
   Subcategory: 1
   Description:  Risk management processes are established, managed, and agreed to by organizational stakeholders
   Component:
   Control:
   - PM-9
-
   Category: ID.RM
   Subcategory: 2
   Description:  Organizational risk tolerance is determined and clearly expressed
   Component:
   Control:
   - PM-9
-
   Category: ID.RM
   Subcategory: 3
   Description:  The organization’s determination of risk tolerance is informed by its role in critical infrastructure and sector specific risk analysis
   Component:
   Control:
   - PM-8
   - PM-9
   - PM-11
   - SA-14
-
   Category: ID.SC
   Subcategory: 1
   Description:  Cyber supply chain risk management processes are identified, established, assessed, managed, and agreed to by organizational stakeholders
   Component:
   Control:
   - SA-9
   - SA-12
   - PM-9
-
   Category: ID.SC
   Subcategory: 2
   Description:  Identify, prioritize and assess suppliers and partners of critical information systems, components and services using a cyber supply chain risk assessment process
   Component:
   Control:
   - RA-2
   - RA-3
   - SA-12
   - SA-14
   - SA-15
   - PM-9
-
   Category: ID.SC
   Subcategory: 3
   Description:   Suppliers and partners are required by contract to implement appropriate measures designed to meet the objectives of the Information Security program or Cyber Supply Chain Risk Management Plan.
   Component:
   Control:
   - SA-9
   - SA-11
   - SA-12
   - PM-9
-
   Category: ID.SC
   Subcategory: 4
   Description:   Suppliers and partners are monitored to confirm that they have satisfied their obligations as required. Reviews of audits, summaries of test results, or other equivalent evaluations of suppliers/providers are conducted
   Component:
   Control:
   - AU-2
   - AU-6
   - AU-12
   - AU-16
   - PS-7
   - SA-9
   - SA-12
-
   Category: ID.SC
   Subcategory: 5
   Description:  Response and recovery planning and testing are conducted with critical suppliers/providers
   Component:
   Control:
   - CP-2
   - CP-4
   - IR-3
   - IR-4
   - IR-6
   - IR-8
   - IR-9
-
   Category: PR.AC
   Subcategory: 1
   Description:  Identities and credentials are issued, managed, revoked, and audited for authorized devices, users, and processes
   Component:
   Control:
   - AC-2
   - IA
-
   Category: PR.AC
   Subcategory: 2
   Description:  Physical access to assets is managed and protected
   Component:
   Control:
   - PE-2
   - PE-3
   - PE-4
   - PE-5
   - PE-6
   - PE-9
-
   Category: PR.AC
   Subcategory: 3
   Description:  Remote access is managed
   Component:
   Control:
   - AC‑17
   - AC-19
   - AC-20
-
   Category: PR.AC
   Subcategory: 4
   Description:  Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties
   Component:
   Control:
   - AC-2
   - AC-3
   - AC-5
   - AC-6
   - AC-16
-
   Category: PR.AC
   Subcategory: 5
   Description:  Network integrity is protected, incorporating network segregation where appropriate
   Component:
   Control:
   - AC-4
   - SC-7
-
   Category: PR.AC
   Subcategory: 6
   Description:  Identities are proofed and bound to credentials, and asserted in interactions when appropriate
   Component:
   Control:
   - AC-2
   - AC-3
   - AC-5
   - AC-6
   - AC-16
   - AC-19
   - AC-24
   - IA-2
   - IA-4
   - IA-5
   - IA-8
   - PE-2
   - PS-3

-
   Category: PR.AT
   Subcategory: 1
   Description:  All users are informed and trained
   Component:
   Control:
   - AT-2
   - PM-13
-
   Category: PR.AT
   Subcategory: 2
   Description:  Privileged users understand roles & responsibilities
   Component:
   Control:
   - AT-3
   - PM-13
-
   Category: PR.AT
   Subcategory: 3
   Description:  Third-party stakeholders (e.g., suppliers, customers, partners) understand roles & responsibilities
   Component:
   Control:
   - PS-7
   - SA-9
-
   Category: PR.AT
   Subcategory: 4
   Description:  Senior executives understand roles & responsibilities
   Component:
   Control:
   - AT-3
   - PM-13
-
   Category: PR.AT
   Subcategory: 5
   Description:  Physical and information security personnel understand roles & responsibilities
   Component:
   Control:
   - AT-3
   - PM-13
-
   Category: PR.DS
   Subcategory: 1
   Description:  Data-at-rest is protected
   Component:
   Control:
   - SC-28
-
   Category: PR.DS
   Subcategory: 2
   Description:  Data-in-transit is protected
   Component:
   Control:
   - SC-8
-
   Category: PR.DS
   Subcategory: 3
   Description:  Assets are formally managed throughout removal, transfers, and disposition
   Component:
   Control:
   - CM-8
   - MP-6
   - PE-16
-
   Category: PR.DS
   Subcategory: 4
   Description:  Adequate capacity to ensure availability is maintained
   Component:
   Control:
   - AU-4
   - CP-2
   - SC-5
-
   Category: PR.DS
   Subcategory: 5
   Description:  Protections against data leaks are implemented
   Component:
   Control:
   - AC-4
   - AC-5
   - AC-6
   - PE-19
   - PS-3
   - PS-6
   - SC-7
   - SC-8
   - SC-13
   - SC-31
   - SI-4
-
   Category: PR.DS
   Subcategory: 6
   Description:  Integrity checking mechanisms are used to verify software, firmware, and information integrity
   Component:
   Control:
   - SI-7
-
   Category: PR.DS
   Subcategory: 7
   Description:  The development and testing environment(s) are separate from the production environment
   Component:
   Control:
   - CM-2
-
   Category: PR.DS
   Subcategory: 8
   Description:  Integrity checking mechanisms are used to verify hardware integrity
   Component:
   Control:
   - SA-10
   - SI-7
   
-
   Category: PR.IP
   Subcategory: 1
   Description:  A baseline configuration of information technology/industrial control systems is created and maintained incorporating appropriate security principles (e.g. concept of least functionality)
   Component:
   Control:
   - CM-2
   - CM-3
   - CM-4
   - CM-5
   - CM-6
   - CM-7
   - CM-9
   - SA-10
-
   Category: PR.IP
   Subcategory: 2
   Description:  A System Development Life Cycle to manage systems is implemented
   Component:
   Control:
   - SA-3
   - SA-4
   - SA-8
   - SA-10
   - SA-11
   - SA-12
   - SA-15
   - SA-17
   - PL-8
-
   Category: PR.IP
   Subcategory: 3
   Description:  Configuration change control processes are in place
   Component:
   Control: 
   - CM-3
   - CM-4
   - SA-10
-
   Category: PR.IP
   Subcategory: 4
   Description:  Backups of information are conducted, maintained, and tested periodically
   Component:
   Control: 
   - CP-4
   - CP-6
   - CP-9
-
   Category: PR.IP
   Subcategory: 5
   Description:  Policy and regulations regarding the physical operating environment for organizational assets are met
   Component:
   Control: 
   - PE-10
   - PE-12
   - PE-13
   - PE-14
   - PE-15
   - PE-18
-
   Category: PR.IP
   Subcategory: 6
   Description:  Data is destroyed according to policy
   Component:
   Control: 
   - MP-6
-
   Category: PR.IP
   Subcategory: 7
   Description:  Protection processes are continuously improved
   Component:
   Control: 
   - CA-7
   - CP-2
   - IR-8
   - PL-2
   - PM-6
-
   Category: PR.IP
   Subcategory: 8
   Description:  Effectiveness of protection technologies is shared with appropriate parties
   Component:
   Control: 
   - AC-21
   - CA-7
   - SI-4
-
   Category: PR.IP
   Subcategory: 9
   Description:  Response plans (Incident Response and Business Continuity) and recovery plans (Incident Recovery and Disaster Recovery) are in place and managed
   Component:
   Control: 
   - CP-2
   - IR-8
-
   Category: PR.IP
   Subcategory: 10
   Description:  Response and recovery plans are tested
   Component:
   Control: 
   - IR-3
   - PM-14
-
   Category: PR.IP
   Subcategory: 11
   Description:  Cybersecurity is included in human resources practices (e.g., deprovisioning, personnel screening)
   Component:
   Control: 
   - PS
-
   Category: PR.IP
   Subcategory: 12
   Description:  A vulnerability management plan is developed and implemented
   Component:
   Control: 
   - RA-3
   - RA-5
   - SI-2
-
   Category: PR.MA
   Subcategory: 1
   Description:  Maintenance and repair of organizational assets is performed and logged in a timely manner, with approved and controlled tools
   Component:
   Control: 
   - MA-2
   - MA-3
   - MA-5
-
   Category: PR.MA
   Subcategory: 2
   Description:  Remote maintenance of organizational assets is approved, logged, and performed in a manner that prevents unauthorized access
   Component:
   Control: 
   - MA-4
-
   Category: PR.PT
   Subcategory: 1
   Description:  Audit/log records are determined, documented, implemented, and reviewed in accordance with policy
   Component:
   Control: 
   - AU
-
   Category: PR.PT
   Subcategory: 2
   Description:  Removable media is protected and its use restricted according to policy
   Component:
   Control: 
   - MP-2
   - MP-4
   - MP-5
   - MP-7
-
   Category: PR.PT
   Subcategory: 3
   Description:  The principle of least functionality is incorporated by configuring systems to provide only essential capabilities
   Component:
   Control: 
   - AC-3
   - CM-7
-
   Category: PR.PT
   Subcategory: 4
   Description:  Communications and control networks are protected
   Component:
   Control: 
   - AC-4
   - AC-17
   - AC-18
   - CP-8
   - SC-7
-
   Category: PR.PT
   Subcategory: 5
   Description:  Systems operate in pre-defined functional states to achieve availability (e.g. under duress, under attack, during recovery, normal operations).
   Component:
   Control: 
   - CP-7
   - CP-8
   - CP-11
   - CP-13
   - PL-8
   - SA-14
   - SC-6
-
   Category: DE.AE
   Subcategory: 1
   Description:  A baseline of network operations and expected data flows for users and systems is established and managed
   Component:
   Control: 
   - AC-4
   - CA-3
   - CM-2
   - SI-4
-
   Category: DE.AE
   Subcategory: 2
   Description:  Detected events are analyzed to understand attack targets and methods
   Component:
   Control: 
   - AU-6
   - CA-7
   - IR-4
   - SI-4
-
   Category: DE.AE
   Subcategory: 3
   Description:  Event data are aggregated and correlated from multiple sources and sensors
   Component:
   Control: 
   - AU-6
   - CA-7
   - IR-4
   - IR-5
   - IR-8
   - SI-4
-
   Category: DE.AE
   Subcategory: 4
   Description:  Impact of events is determined
   Component:
   Control: 
   - CP-2
   - IR-4
   - RA-3
   - SI -4
-
   Category: DE.AE
   Subcategory: 5
   Description:  Incident alert thresholds are established
   Component:
   Control: 
   - IR-4
   - IR-5
   - IR-8
-
   Category: DE.CM
   Subcategory: 1
   Description:  The network is monitored to detect potential cybersecurity events
   Component:
   Control: 
   - AC-2
   - AU-12
   - CA-7
   - CM-3
   - SC-5
   - SC-7
   - SI-4
-
   Category: DE.CM
   Subcategory: 2
   Description:  The physical environment is monitored to detect potential cybersecurity events
   Component:
   Control: 
   - CA-7
   - PE-3
   - PE-6
   - PE-20
-
   Category: DE.CM
   Subcategory: 3
   Description:  Personnel activity is monitored to detect potential cybersecurity events
   Component:
   Control: 
   - AC-2
   - AU-12
   - AU-13
   - CA-7
   - CM-10
   - CM-11
-
   Category: DE.CM
   Subcategory: 4
   Description:  Malicious code is detected
   Component:
   Control: 
   - SI-3
-
   Category: DE.CM
   Subcategory: 5
   Description:  Unauthorized mobile code is detected
   Component:
   Control: 
   - SC-18
   - SI-4
   - SC-44
-
   Category: DE.CM
   Subcategory: 6
   Description:  External service provider activity is monitored to detect potential cybersecurity events
   Component:
   Control: 
   - CA-7
   - PS-7
   - SA-4
   - SA-9
   - SI-4
-
   Category: DE.CM
   Subcategory: 7
   Description:  Monitoring for unauthorized personnel, connections, devices, and software is performed
   Component:
   Control: 
   - AU-12
   - CA-7
   - CM-3
   - CM-8
   - PE-3
   - PE-6
   - PE-20
   - SI-4
-
   Category: DE.CM
   Subcategory: 8
   Description:  Vulnerability scans are performed
   Component:
   Control: 
   - RA-5
-
   Category: DE.DP
   Subcategory: 1
   Description:  Roles and responsibilities for detection are well defined to ensure accountability
   Component:
   Control: 
   - CA-2
   - CA-7
   - PM-14
-
   Category: DE.DP
   Subcategory: 2
   Description:  Detection activities comply with all applicable requirements
   Component:
   Control: 
   - CA-2
   - CA-7
   - PM-14
   - SI-4
-
   Category: DE.DP
   Subcategory: 3
   Description:  Detection processes are tested
   Component:
   Control: 
   - CA-2
   - CA-7
   - PE-3
   - PM-14
   - SI-3
   - SI-4
-
   Category: DE.DP
   Subcategory: 4
   Description:  Event detection information is communicated to appropriate parties
   Component:
   Control: 
   - AU-6
   - CA-2
   - CA-7
   - RA-5
   - SI-4
-
   Category: DE.DP
   Subcategory: 5
   Description:  Detection processes are continuously improved
   Component:
   Control: 
   - CA-2
   - CA-7
   - PL-2
   - RA-5
   - SI-4
   - PM-14
-
   Category: RS.RP
   Subcategory: 1
   Description:  Response plan is executed during or after an event
   Component:
   Control: 
   - CP-2
   - CP-10
   - IR-4
   - IR-8
-
   Category: RS.CO
   Subcategory: 1
   Description:  Personnel know their roles and order of operations when a response is needed
   Component:
   Control: 
   - CP-2
   - CP-3
   - IR-3
   - IR-8
-
   Category: RS.CO
   Subcategory: 2
   Description:  Events are reported consistent with established criteria
   Component:
   Control: 
   - AU-6
   - IR-6
   - IR-8
-
   Category: RS.CO
   Subcategory: 3
   Description:  Information is shared consistent with response plans
   Component:
   Control: 
   - CA-2
   - CA-7
   - CP-2
   - IR-4
   - IR-8
   - PE-6
   - RA-5
   - SI-4
-
   Category: RS.CO
   Subcategory: 4
   Description:  Coordination with stakeholders occurs consistent with response plans
   Component:
   Control: 
   - CP-2
   - IR-4
   - IR-8
-
   Category: RS.CO
   Subcategory: 5
   Description: Voluntary information sharing occurs with external stakeholders to achieve broader cybersecurity situational awareness
   Component:
   Control: 
   - PM-15
   - SI-5
-
   Category: RS.AN
   Subcategory: 1
   Description:  Notifications from detection systems are investigated 
   Component:
   Control: 
   - AU-6
   - CA-7
   - IR-4
   - IR-5
   - PE-6
   - SI-4
-
   Category: RS.AN
   Subcategory: 2
   Description:  The impact of the incident is understood
   Component:
   Control: 
   - CP-2
   - IR-4
-
   Category: RS.AN
   Subcategory: 3
   Description:  Forensics are performed
   Component:
   Control: 
   - AU-7
   - IR-4
-
   Category: RS.AN
   Subcategory: 4
   Description:  Incidents are categorized consistent with response plans
   Component:
   Control: 
   - CP-2
   - IR-4
   - IR-5
   - IR-8
-
   Category: RS.MI
   Subcategory: 1
   Description:  Incidents are contained
   Component:
   Control: 
   - IR-4
-
   Category: RS.MI
   Subcategory: 2
   Description:  Incidents are mitigated
   Component:
   Control: 
   - IR-4
-
   Category: RS.MI
   Subcategory: 3
   Description:  Newly identified vulnerabilities are mitigated or documented as accepted risks
   Component:
   Control: 
   - CA-7
   - RA-3
   - RA-5
-
   Category: RS.IM
   Subcategory: 1
   Description:  Response plans incorporate lessons learned
   Component:
   Control: 
   - CP-2
   - IR-4
   - IR-8
-
   Category: RS.IM
   Subcategory: 2
   Description:  Response strategies are updated
   Component:
   Control: 
   - CP-2
   - IR-4
   - IR-8
-
   Category: RC.RP
   Subcategory: 1
   Description:  Recovery plan is executed during or after an event
   Component:
   Control: 
   - CP-10
   - IR-4
   - IR-8
-
   Category: RC.IM
   Subcategory: 1
   Description:  Recovery plans incorporate lessons learned
   Component:
   Control: 
   - CP-2
   - IR-4
   - IR-8
-
   Category: RC.IM
   Subcategory: 2
   Description:  Recovery strategies are updated
   Component:
   Control: 
   - CP-2
   - IR-4
   - IR-8
-
   Category: RC.CO
   Subcategory: 3
   Description:  Recovery activities are communicated to internal stakeholders and executive and management teams
   Component:
   Control: 
   - CP-2
   - IR-4

CRMs are provided by those IaaS/PaaS/SaaS providers that have already completed their system security documentation (usually FEDRAMP if you ever get to see it - or when inheriting from an agency run platform within an agency). They are basically the output of "we did all these things for this control, here is what you still have to do to fully implement this control".

OpenControl provides the ability to layer/combine multiple independent components (i.e. platforms/services/applications) together to create a complete system this is done through the concept of inheritance. So is the best approach to:

• Develop the CRM as yet-another certification or standard - which would make it more straightforward to speak directly to those responsibilities over the control generally?
• Develop a place for it as a stand-alone resource within the schema so it can be rendered separately

Any thoughts on how to handle standard revisions? For example NIST-800-53 is currently at revision 4 with revision 5 on the way, and it looks like -171 will be revised every year.

On the one hand, an assertion that a control is satisfied ought in some way to indicate the effective revision; but on the other hand I'd prefer to avoid having to go through my entire SSP changing 'standard: NIST-800-171r1' to 'NIST-800-171r2' next year and every year thereafter. (And on the third hand, being new to this game I'm not sure what sort of changes to expect between revisions...)

use the current verification key in opencontrol format with id for (examples):

• openscap
• inspec
• ansible
• chef
• puppet
• osquery

with a common:

• path
• cmd
• var(s)
• etc

schema to provide a common framework similar to test-kitchen - http://kitchen.ci/ verifier schema to provide a standardized means of validating a control

What is the appropriate way to document NIST 800-53 sub-elements in the component.yaml's?

In the FISMA guidance, we have controls with sub-elements. For example: AC-2

In the FedRAMP word templates, these sub-elements are broken out into tables:

In code I can do something like this:

- control_key: AC-2
  standard_key: NIST-800-53
  covered_by: []
  implimentation_status: none
  narrative:
   - text: |
        (a) some answer A

        (b) some answer for B

..... however, using fedramp-templater, these sub-elements do not get properly populated. Anyone tackle this yet?

Preparing to send out a post symposium email. Simple checklist.

• Draft email
• links to videos
• update webinar schedule
• general info links
• read after notes for specific todos
• ask others for thoughts/ideas
• Add all attendees to email list
• restrict email to attendees and registered parties. (Can we segment for who attended and who did not?)
• Finalize content
• email

In preparing to package OpenControl for Enterprise Linux, I need to set an installation path.

Not sure OpenControl content has been packaged for the enterprise yet, so not sure if install paths have been determined.

How does /usr/share/opencontrol/${VENDOR} sound?

e.g.
/usr/share/opencontrol/RedHat/{product1 product2 productX}
/usr/share/opencontrol/Docker/{product1 productX}

For Project Boise (#28), we're looking for who is actively using the OpenControl schema, Compliance Masonry, or any of the other tools under the OpenControl umbrella, and how they are being used. We are going to use this information to make the case for GSA renewing focus (and $$) on OpenControl, so it's important we hear from you.

If you're using it

• In what context is it being used? In a product, at a federal agency, etc.
• How is it being used? For example:
  • Are you using the schema files on their own?
  • Are you using Compliance Masonry or the FedRAMP Templater directly?
  • Have you built any other tooling around OpenControl, even if it's just internal?

If you're not using it, but are interested in doing so

• What are the barriers to doing so?
• What answers/features/permission would you need?

Feel free to respond here, or email me directly at [email protected]. Happy to keep your answers private, if you like - being able to say "it's in use at X number of agencies" is useful on its own. Please respond by 9/13. Thanks!

https://github.com/18F/GSA-Certifications/blob/master/LATO.yaml

I've seen this referenced a few places with no context. What is it? The repo doesn't provide any references or information (I can open an issue there if necessary).

@mogul @joshuamckenty @gregelin and others have brought up the idea of having an in-person get-together (in San Francisco?) in the fall to sync up about OpenControl. Starting this discussion to figure out the things that need figuring out. Will continue adding to this list.

• Location (18F SF office?)
• Duration (one day? two? three?)
• Agenda (what do we want to cover/accomplish?)
• Dates (September? we should set up a survey to see what works)
• Capacity (we'll probably need an open RSVP to figure out how much capacity we need)
• Planning (who's responsible for what planning?)

At Red Hat we've quietly been using ComplianceMasonry to generate SSP packages for FISMA baselines. We're going to open source our work, and I'm trying to find a home for upstream collaboration.

Is there an intent for OpenControl to host technology-specific content? For example, github.com/opencontrol/{rhel7 ubuntu-lts}?

(bump to @gregelin, as we spoke on this at RSA)

OpenControl Slack Code of Conduct

We are group of technologists, government staff, contractors and others in regulated fields passionately pursuing Compliance-as-Code.

We are developing a cmmunity and tools at http://open-control.org necessary to align security assessments and authorizations with modern, continuous software development and delivery.

We extend to you an invitation to join our Slack provided you agree to the following terms.

Respectful and professional discourse

At all times you will engage in conversations that are respectful of other Slack members -- and third parties -- and professional in tone. We are professionals pursing professional goals. Respect and professionalism includes civil conversation, allowing others opinions, and avoiding personal disparaging comments, and contributing usefully to the community topic: Compliance-as-Code.

Always respect a designated moderator.

Stay on target topic of each channel

No matter how many TIE fighters are at your back, stay on the target topic of each channel.

Encourage participation

Be biased toward conversation and participation. Be comfortable asking questions and providing answers.

Appropriate, minimal personal/business promotion

It's fine to let others in the community know about professional events, positions, new software releases and other developments that are highly relevant to the OpenControl and Compliance-as-Code community.

It's also cool to share and celebrate accomplishments and support for community members in their achievement of some milestone, life-event, or other leveling-up. (It's also OK to professionally rally the community in support of community members.)

It is not fine to spam channels with multiple announcements, multiple times each week.

Promotions for things not related OpenControl and Compliance-as-Code is restricted to appropriately designated channels.

Acceptance the organizers can update the conduct code

This policy is a "living" document, and subject to refinement and expansion in the future.

Respect for diversity

The OpenControl Slack is fine place for everybody regardless of race, religion, gender, identity, sexual orientation, technical ability, or employment situation.

Getting help

If you are experiencing technical problems or non technical problems (like harassment) contact Greg Elin (@gregelin) or another moderator.

We have a number of repositories with different (or no) license files, and should probably decide on one...or at least a default. At 18F, we use CC0 with an explanation at the top:

https://github.com/18F/open-source-policy/blob/master/LICENSE.md

Would be simplest for the 18F staff to go with CC0 for consistency on our side (since our contributions are public domain), but not sure if we want to pick something that addresses patents.

https://wiki.creativecommons.org/wiki/CC0_FAQ#May_I_apply_CC0_to_computer_software.3F_If_so.2C_is_there_a_recommended_implementation.3F

Thoughts?

I mentioned to many in the OpenControl community that I submitted a session to OpenStack Sydney about OpenControl, and asked for help voting up the session.

Wanted to say thank you to everyone who voted the session up -- and with HUGE excitement wanted to share that the session was selected!!

https://www.openstack.org/summit/sydney-2017/summit-schedule/events/20012/openstack-compliance-speed-and-agility-yes-its-possible

Pretty interesting how the broader commercial and international community is interested in how to use OpenControl to help with ATO paperwork generation.

So really, thank you! Nothing like the pressure of a conference talk to expedite the OpenControl pieces shipping in RHEL/EPEL :)

I understand that use of opencontrol/masonry has not kept pace with the real-world demands for Word document output that can be consumed by assessors and auditors. In the case of cloud.gov compliance, would you be able to share an example Word document that is acceptable to assessors and auditors so I can see where gaps are?

Ref: opencontrol/compliance-masonry#153

https://github.com/opencontrol/cf-compliance-DEPRECATED was deprecated three years ago. Time to remove it?

Not sure where this information should live, but we should put information about contributing (as a "maintainer" or otherwise) somewhere. Things like:

• We try to have all discussions about OpenControl in the open in GitHub (across various @opencontrol repositories) and Slack; very little should happen behind the scenes.
• We do all changes through pull requests. Even people with write access should ensure at least one other contributor reviews them.

Do I need to do anything special if my opencontrol.yaml references a variety of system dependencies and the dependencies component.yaml's are a mixture schema versions?

Let's use this issue to capture other events, conferences, workshops, camps of interest to us and Compliance-as-Code. Perhaps we should try to have OpenControl presence?

The https://github.com/opencontrol/PCI-DSS-Standards hasn't been touched for a few years, and the PCI-DSS content was incorporated into https://github.com/opencontrol/standards.

As a little spring cleaning, should the https://github.com/opencontrol/PCI-DSS-Standards repo be removed? Would it make sense to create an updated README for a little while?

(IMHO an updated readme is not needed, since the opencontrol/standards project has included PCI-DSS for at least 6mo)

Would be great to also format the DOD 8500.2 control list against the OpenControl schema

The current schema supports implementation_status, taken literately this means it can generate your still-need-to-do list otherwise known as the A Plan of Action and Milestones (POA&M).

It makes sense to use implementation_status other than complete to generate a csv file that could serve as a crude POA&M spreedsheet.

The OpenControl slack community is now live at https://opencontrol.slack.com

There is a self-inviter here: https://opencontrol-slack-inviter.herokuapp.com

This issue is to discuss migrating the communications from 18F slack channel.

Per discussion in opencontrol/schemas#61 ... we need to figure out a way to allow one to reference specific versions of a component file. A simple solution would be to create separate component.yml files for each version of the component and reference them accordingly in opencontrolyml. However, this breaks when one imports component controls from a Git repo rather than a local path.

@gregelin proposed a package management solution, but this could be more work than it's worth. Thoughts on this?

A question for federal contractors performing digital services/IT Modernization work for the Government: The ATO process at the end of development is an inevitable hurdle to overcome for successful project completion. What could help the contractor or project team achieve a smoother ATO?

Do you see any benefit in including the government contractor in the ATO process? Perhaps including NIST standards in RFQs? Or having them create the Compliance Masonry as part of a contract requirement?

I'm a GSA Contracting Officer hoping the better the process for the entire project team (contractor and Government). Thank you!

I've created a Save the Date email in MailChimp that I hope to send out tonight. Here it is:

SAVE THE DATE

10/20/2016
Open Control Gathering/Symposium

Thanks for your interest in an OpenControl live event!

Thursday, October 20, 2016, in Washington, DC
seems the best date and location with enough time to promote

We are group of technologists, government staff, contractors and others in regulated fields committed to Compliance-as-Code. We are developing tools necessary to align security assessments and authorizations with modern, continuous software development and delivery.

We want to build the OpenControl community (http://open-control.org) via a symposium or other social gathering this fall.

http://bit.ly/ocsymp-googlecal • http://bit.ly/ocsymp-ical

• OpenControllers

About OpenControl
Community, data, and tools for Compliance-as-Code
Web: http://open-control.org
Github: https://github.com/opencontrol
Slack: https://opencontrol.slack.com
Webinars: http://bit.ly/opencontrol-webinars

Our mailing address is:
OpenControl
2011 Crystal Drive
Suite 400
Arlington, VA 22202

(various unsubscribe information)

...especially those without a ton of compliance experience. I've spoken with multiple software vendors in that boat who are interested in using OpenControl, but aren't sure about where to start. Would be good to include some of the following:

• What is OpenControl / Compliance Masonry, and why should they care?
• The fact that they will likely be creating a Component
  • Where those files should live: under @opencontrol, or in a repository under their control
• That if they have federal customers already, it's likely that someone has done the hard part of writing up the narratives
  • They should reach out to their customers and ask if the relevant parts of the System Security Plan can be shared, which the vendor can then generalize and publish for other customers going forward.

This would likely look a lot like Compliance Masonry for the Compliance Literate, but with an audience of Not Compliance Literate Vendors. Not sure where said resource should live.

It would be useful to have a more comprehensive list of use cases for OpenControl data specification.

On this page:
https://github.com/opencontrol/compliance-masonry/blob/master/docs/masonry-for-the-compliance-literate.md

In the second to last paragraph, there is the sentence:
"Compliance Masonry templates can run executable specifications which are used to continuously monitor that systems behave in the way they’re documented."

I went looking for this functionality and I couldn't find anything anywhere about it (other than this statement) in the documentation. Has this been implemented? I apologize if it is there and I just missed it.

It's difficult for me to determine if the opencontrol framework supports the concept of overlays. An example overlay is the Privacy overlay from CNSSI 1253 Appendix F. There are other example overlays on https://www.cnss.gov/CNSS/issuances/Instructions.cfm.

From https://www.nist.gov/services-resources/software/baseline-tailor overlays are used in tailoring controls for different types of systems.

There is some nuance in overlays in that multiple can be applied to a system with conflicting customization.

I'm considering pre-processing tools that generate a standard for usage with the opencontrol framework.

Does opencontrol support the concept of overlays or tailoring without adjusting the standard?

Looks like Chef came out with a pretty slick open source compliance-as-code framework and DSL called InSpec (http://inspec.io/) which supports a number of OS's. This could be a nice complement to OpenControl in the form of BDD testing. Some ideas below:

• Tap in to InSpec by way of a Compliance Masonry plugin
• Include InSpec DSL resources alongside component.yaml definitions

It would be great to come up with a consensus on where OpenControl fits in to the actual generation of documentation. There have been some discussions on Slack in regards to removing the actual SSP documentation generation functionality from compliance-masonry, and instead use it solely for validation, gap analysis and converting yaml to various meta-formatted text (e.g. markdown and ReStructuredText which can be fed in to MkDocs, Jekyll, Readthedocs, etc). Do folks agree on this approach?

I’m going to be in DC for Project Boise (#28) meetings - let’s do an OpenControl get-together! Monday 7/31 at Elephant & Castle at 900 19th Street at 5:30pm. All are welcome.

https://www.yelp.com/biz/elephant-and-castle-washington-3

Hi folks!
Wanted to send you an update about what's happening at 18F. We have started an initiative with the (arbitrary) working title "Project Boise", whose goal is to "reduce the burden (time, cost, and pain) and improve the effectiveness of the federal government’s software security compliance processes." This is, we hope, very much in line with OpenControl, though may extend more broadly (to things like policy). Take a look at our project overview (https://boise.18f.gov) - would love your feedback! Feel free to leave comments here, shoot me an email, etc.

In our “Discovery” phase, we’re looking to talk to folks in the following areas:

• Chief Information Security Officers, cybersecurity policy/rule-makers, or others involved in shaping federal security compliance in or across agencies
• People who deal with a lot of ATOs, such as auditors/assessors
• Companies who build products that help with security compliance

If you fall into one of those categories, or have a connection with someone who does, please get in touch.

Thanks!
Aidan Feldman
[email protected]

Great work on this tool! Last week, a colleague discovered, that the SSP PDFs that are produced by Compliance Masonry do not include the NIST Control statements; just the implementation statements of the respective controls. This could prove rather cumbersome for our assessors. Is there way to include the NIST control statements for each control, right before the implementation statements? I couldn’t find an easy way of doing that.

The OpenControl project is no longer only 18F and hasn't been for some time (which is great!!). To reflect this, suggesting the OpenControl org permissions be restructured.

Currently there are four organizational teams (https://github.com/orgs/opencontrol/teams):

• 18F-contributors
• certification-maintainers
• opencontrol2016washdc-volunteers
• Red Hat Content Maintainers

Suggest the following:

1. Creation of net-new community-members team. Members would be able to be own tickets, be tagged in PRs, etc. Need a vehicle to recognize community participants and communicate with them.

2. Creation of repository maintainer teams, such as certification-maintainers , compliance-masonry-maintainers, etc. Members would have write-access to those repos. Currently it's to hard to track permissions and no clear way to give them out either. Also means interested parties could @repo-maintainers when asking for help, a quick PR review, etc.

In component.yaml, we define controls. Each control has a 'standard_key' and a 'control_key' and (among other things) a 'narrative' section.

Is it possible to have one component control definition to implement multiple standards' controls so that one narrative section could be used to satisfy the control requirements for multiple standards? Or one control that implements multiple required controls w/in one standard.

I've tried putting in multiple 'standard_key' and 'control_key' sections and that doesn't appear to work, I only get one section in the output document.

In order to make the process of targeting the correct and complete list of controls easier to understand for new users/components. Open Control should provide a cheatsheet/guide on some general types of SecOps tooling and to which controls they'd typically contribute to.

In order to effectively do this there needs to be an established taxonomy of component types. Based on some looking into one ready made framework could be the NIST Framework for Improving Critical Infrastructure Cybersecurity https://www.nist.gov/cyberframework. I went ahead an converted the spreadsheet into 3 yaml chunks for the Function -> Category -> Subcategory hierarchy:
https://gist.github.com/JJediny/65438415b5e38ac7560ad5f5597f1877

But that only serves as topic areas not discrete categories by which to curate a group of related/similar technologies that ideally share a common mapping to controls.

Other resources

https://cloudsecurityalliance.org/wp-content/uploads/2011/09/SecaaS_V1_0.pdf
https://downloads.cloudsecurityalliance.org/assets/research/security-as-a-service/csa-categories-securities-prep.pdf

https://cloudsecurityalliance.org/group/security-as-a-service/#_downloads

Has anyone imported the AICPA TSC for SOC2 into the standard format ala opencontrol/standards/blob/master/pci-dss.yaml?

About to start on that task soon, collaborators welcome.

In the current RedHat content repo, directory structure is used to breakout products:

https://github.com/opencontrol/RedHat/tree/master/OpenShift-v3
https://github.com/opencontrol/RedHat/tree/master/OpenStackPlatform

edit: Not sayin' this is the best practice or most ideal, just how we got started :)

If I understand the OpenControl schema for systems correctly, only url and revision can be passed as arguments:

https://github.com/opencontrol/schemas/blob/master/kwalify/opencontrol/v1.0.0.yaml#L53#L61

      systems:
        type: seq
        sequence:
          - type: map
            mapping:
              url:
                type: str
              revision:
                type: str

This forces us to create many content repos, e.g. redhat-rhel, redhat-openshift, redhat-jboss, instead of one per vendor.

Has there been a discussion on if this is desired? Should we update the schema to support a directory tree, e.g.:

  systems:
    - url: https://github.com/opencontrol/RedHat
      revision: master
      folder: tree/master/Product1

    - url: https://github.com/opencontrol/RedHat
      revision: master
      folder: tree/master/Product2

I have two clients each with an ATO and tus an SSP. It's reasonably straightforward to pull each family of controls into separate .md files in GitHub (well, I'm using GitLab now). The next step is to convert the controls into OC YAML Components, but this is not 1:1. Does a suggested mapping exist?

I understand that each site will have its differences, but there is likely to be a fair amount of commonality. If the process can be reduced to a script that handles 90% of the controls and a process for massaging the 20% that didn't "fit" correctly, I believe this may help facilitate adoption.

From the email:

[Company] has clients (or potentially has client) that would like to leverage opencontrol and compliance-masonry to speed up the ATO process. An example implementation might be running CF in AWS, and some apps on top of that. So one thing I'm working on is a HelloWorld-type app that demonstrates a complete SSP built up from various components.

The schema and tooling are great, but there are gaps more than a few areas of confusion. Before I dive in too deep on the schema or the Go code I should probably find out more where y'all are heading so we're not working at cross purposes.

Also of interest is the goal, per @NoahKunin, of "creating data structures that enable us to create continuous monitoring platforms". Some of the BDD examples are interesting, and I'd like to build on that with InSpec profiles that run against nodes or even the entire platform with inspec-aws. I'm also interested in how, potentially, Nessus scans are created and run as part of a pipeline.

So, that's what I'm up to. Are there any sources of information I should be tracking besides the repos and issues for opencontrol/compliance-masonry and opencontrol/schemas? I see that identity-idp has security committed in-place. Are there other examples that you'd recommend where this is happening?

A few questions in no particular order:

• http://opencontrol.xyz/pipelines/ references Spruce and has a notional architecture which includes it. Am I right that that is obsolete?
• This is a great diagram from @mogul: .
  • Does it still represent the design intentions?
  • Are "fork+append" and "fork+amend" still part of the envisioned workflow?
  • Probably nothing has been so useful to me this week than the sidebar comment "Certifications are just collections of references to standards" -- which was the "Oh! now I get it" moment for me.

Are there any YAML files of the three types of security compliance codes?

Consider tools like Gemnasium, Quantified Code, and Travis -- each covers some component of the compliance process. However, adding a verification for each requires adding a unique URL (i.e. pointing to the project page within Gemnasium, QC, Travis). It'd be handy if we could define component docs for each of these tools once and re-use them across projects, but there's no way to template that URL/project id/etc. One potential approach would be to add something to the opencontrol.yaml file:

dependencies:
    systems:
    - url: https://path/to/travis/docs
      parameters:
          badge: https://travis.thing/image/myproject

In order to enable broad collaboration on OpenControl among parties with overlapping (but potentially misaligned) interests in a common roadmap, we should come up with a lightweight governance process and a cadence for regularly meeting to update and surface concerns related to the roadmap.