Scope of OpenControl

[JJediny]

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.

Key	Value
nodeType	Root; Compute; SoftwareComponent; DBMS; Database; Webserver; WebApplication; BlockStorage; ObjectStorage; Load Balencer
capabilities	OperatingSystem; Endpoint; Endpoint.Admin; Endpoint.Public; Scalable; Endpoint.Database; Attachment; network.Linkable; network.Bindable; OperatingSystem; Container.Docker
relationships	HostedOn; ConnectsTo; AttachesTo; RoutesTo; network.LinksTo; network.BindsTo

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...

[JJediny]

I'll add my pitch for what I hope OpenControl would set the goal to be (IMHO)...

OpenControl = Compliance-as-Code The output of OpenControl should yield BOTH automated documentation and automated auditing, akin to and/or producing actual SCAP content OpenSCAP. Otherwise it is just documentation for developers; and documentation alone will never be a valid representation of reality without some form of auditability. OpenControl SHOULD NOT be at all redundant with Infrastructure-as-Code solutions, but it SHOULD provide a symbiotic mapping/model with such solutions.

Configuration Management = Infrastructure-as-Code

[mogul]

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...

These are all good points to raise, but I think to make any progress on them we might be better served by breaking them up into separate issues each representing a problem to be solved. So I'm only commenting on a few elements below...

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:

It was never our intention to limit the set of potential controls to just NIST 800-53; that just happens to be what we had in front of us for sample data. The standards are already parameterized... It sounds like you think that the satisfies part of the schema needs to be made more general? Or more explicit?

How to manage/combine controls when inheriting/applying controls to/from various levels within the architecture?

Right now our best idea for this is control_origins, although this is essentially mirroring what's in the FedRAMP template. Maybe we can refactor this part of the schema to achieve what you're after?

I'll add my pitch for what I hope OpenControl would set the goal to be (IMHO)...

This is very much in line with what we've been thinking about CM all along, and well-stated! We initially targeted people producing documentation, but we also want to target people responsible for auditing both the docs and the system... Ideally we can automate everything that doesn't require humans. For automated auditing, I don't believe SCAP is enough. This is why we went for BDD/Gherkin in the current Compliance Masonry implementation: The Gherkin steps can themselves be callouts to SCAP, Selenium, etc... We want to leave the actual implementation of the verification wide open. That said, although that pathway exists, we don't have bandwidth now to fill in our own BDD tests for cloud.gov, so it's not getting a workout and iteration based on real-world attempted usage.

[gregelin]

+1 on @JJediny write-up. Information systems are mini-organizations and documentation of controls requires documenting all aspects of organization.

[gregelin]

@mogul Is there any good writeup on BDD in OpenControl and Compliance Masonry?

[geramirez]

@gregelin, a couple of the OpenControl repos have BDD tests -- https://github.com/opencontrol/cf-compliance/tree/master/BDD

Is that what you're looking for?

[shawndwells]

No activity on this discussion for over two years. Closing for inactivity. Feel free to reopen as appropriate!