Closed JJediny closed 5 years ago
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
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.
+1 on @JJediny write-up. Information systems are mini-organizations and documentation of controls requires documenting all aspects of organization.
@mogul Is there any good writeup on BDD in OpenControl and Compliance Masonry?
@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?
No activity on this discussion for over two years. Closing for inactivity. Feel free to reopen as appropriate!
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:
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:
nodeType
orcapabilities
.relationships
.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):
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...