Scope of OpenControl about discuss HOT 6 CLOSED

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

from discuss.

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.

from discuss.

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

from discuss.

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

from discuss.

@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?

from discuss.

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

from discuss.