Changing Schema about compliance-masonry

[gregelin]

@geramirez The term "Governor" is a bit unclear. What does it mean in this context? Do we have a glossary.

[geramirez]

@gregelin originally we defined a governor as a (link to inspect how [a component is] actually configured to run, live... config files, live tests, kanban board, role roster, etc) Basically, it's an artifact that proves that a control is implemented. When we start creating automated tests we'll hook into the governors.

However, if the name is unclear we could change it to something more intuitive. Maybe just artifact perhaps? Thoughts?

[Gergues]

In some systems that would be name "Qualifier" (some FDA documents)
"Qualifier" : Rule(x) is satisfied by Implementation(Xn).
Or : Xn is a list of implementations that satisfied rule x.

The name artifact will require a link or item of sort ,but that can be implicit with the nature of the system. [ RBACS implies users, groups, policies etc. so the number of artifacts may not match the number of rules and in many case will be one to many]

In any case the name is irrelevant as we know what is means.

[openprivacy]

Would "conform to server baseline" be a Rule satisfied by running e.g, OpenSCAP with the appropriate profile, or would each separate test in the profile have its own rule? The latter is better for granularity and control, but of course duplicates work of other projects.

[gregelin]

@geramirez I think "governor" is an OK term. Here are some other possibilities:

• controllers
• services
• endpoints
• configurations
• inspectors
• providers
• interfaces
• accessors

[gregelin]

Two thoughts on the general structure:

1. Can we the example with more than one component? My concern is if this structure is in a file by itself or part of a larger yaml file with multiple components. If the latter, "component" and "system" and "documentation_complete" are all on the same level.
2. I can't figure out how I feel about using the "AC-2" as both key and identifier. It definitely affects how you write a parser. I think it is important for Compliance-Masonry to have a consistent approach to whether or not we always have a key and a value vs. key that is also a value position dependent. I think consistency is more important than the choice, and I think providing example code is important.

[geramirez]

I ended up going with configuration as a replacement for governor because it seems like the most straightforward word. The point of Qualifier/Governors/etc is to provide proof that the system is configured properly.

Also, I made some minor changes to the schema and updated the issue with fleshed-out examples.

@openprivacy

Would "conform to server baseline" be a Rule satisfied by running e.g, OpenSCAP with the appropriate profile, or would each separate test in the profile have its own rule?

I think using the masonry schema you could probably put each test into a configuration/governor or just use the results of entire profile.

[mogul]

I think based on these potential destinations for the URLs, "configuration"
is maybe over-specific. How about "verification"?
config files, live tests, kanban board, role roster,

On Mon, Nov 16, 2015 at 3:25 PM Gabriel Ramirez [email protected]
wrote:

I ended up going with configuration as a replacement for governor because
it seems like the most straightforward word. The point of
Qualifier/Governors/etc is to provide proof that the system is
configured properly.

Also, I made some minor changes to the schema and updated the issue with
fleshed-out examples.

@openprivacy https://github.com/openprivacy

Would "conform to server baseline" be a Rule satisfied by running e.g,
OpenSCAP with the appropriate profile, or would each separate test in the
profile have its own rule?

I think using the masonry schema you could probably put each test into a
configuration/governor or just use the results of entire profile.

—
Reply to this email directly or view it on GitHub
#85 (comment)
.

Authored entirely by thumb

[gregelin]

@mogul Is the "governor" the actual "verification" of the settings/service for that which delivers the verification (e.g., the "verifyer")?

[mogul]

Yeah, the idea is that if you're an auditor, this is where you'd go to inspect the actual configuration or process being applied and verify that the SSP is accurate. I said "kanban board" as a potential destination because some of the processes are non-technical. And if/when we get SCAP information flowing through this pipeline, I think they'll be pointers to the output of tests, not configuration.

[gregelin]

@mogul @geramirez
Can we add a couple of actual examples in this thread of target artifacts? Thanks for examples.

• The term "Governor" suggests and actor/agent/something that does something.
• "Configuration" suggests settings/something that can be adjusted.
• "Verification" suggests a result, an artifact/evidence/assessment/result.

[geramirez]

I like verification, it seems to convey a more precise meaning than configuration. Let's try it
.

[joshuamckenty]

When Diego and I were chatting about this in Berlin, I noted that the “human-readable” aspects of the configuration detail are likely to be different from the “machine-validated” tests that can be run to prove this configuration. So my hunch is that we’ll need to separate validated_by from reference.

On Nov 17, 2015, at 7:39 AM, Gabriel Ramirez [email protected] wrote:

I like verification, it seems to convey a more precise meaning than configuration. Let's try it
.

—
Reply to this email directly or view it on GitHub #85 (comment).

[dlapiduz]

verification and validated_by both sound good... not sure where the term governor came from but it definitely has its issues.

The more human readable that we make the yaml the better...

[geramirez]

@joshuamckenty do you mind going into more detail about this. I think you bring up a really important distinction.

So my hunch is that we’ll need to separate validated_by from reference

Right now we have references, which we are using as links to information about a component. These references are different than validations, which essentially prove that components are satisfying the control requirements.

Are you saying that there should be two different types of validations? such as:

1. Validations that point to human-readable system/component configurations
2. Validations that point to machine-validated tests of system/components

... or that we should be using

1. references as pointers to human-readable system/component configurations, and
2. validations as pointers to machine-validated tests of system/components?

[gregelin]

@geramirez I agree with @joshuamckenty that there will be controls that human_validated and machine_validated. In fact, a human_validated control in one organization may be machine_validated in another.

I think references are citations. A reference refers to another document/artifact. Government frequently incorporate an external source by reference. You see this all the time in contracts and also in polices. So, I think it is best to align with that trend. I write, "I think" because, incorporation by reference in government contracts and policies also gets really annoying where one is chasing down reference after reference to establish proper interpretation. We've all probably had moments of exasperation looking at full page of clauses incorporated by reference.

My feeling is a reference definitely can be used to "link to information about a component."

Maybe the question is if a validation is a type of reference that links to direct evidence proving a control implemented (e.g. human_validated and/or machine_validated), or is validation a description of evidence that may include a reference specific evidence?

[geramirez]

I like the former. How about adding something like this to the schema:

verifications:
  EC2_Verification_1: # ID of verification
    name: EC2 Verification 1  # Name of verification
    url: Verification 1 URL #  URL of the verification
    type: URL # type of reference (will affect how it's rendered in the documentation)
    validated_by: Validator X # Name or ID of validator human or machine 

[joshuamckenty]

I love this. Ending up with an index of “validated_by” actors, with the best of verifications that they provide, will be super valuable in shared-responsibility SSPs such as those composing CF, AWS, and various other SAAS-provided systems.

Any thoughts on a common scheme for those IDs? Ala OpenID / OAuth URL or LDAP OU?

On Nov 23, 2015, at 6:35 AM, Gabriel Ramirez [email protected] wrote:

I like the former. How about adding something like this to the schema:

verifications:
EC2_Verification_1: # ID of verification
name: EC2 Verification 1 # Name of verification
url: Verification 1 URL # URL of the verification
type: URL # type of reference (will affect how it's rendered in the documentation)
validated_by: Validator X # Name or ID of validator human or machine
—
Reply to this email directly or view it on GitHub #85 (comment).

[afeld]

Is this still relevant?

[gregelin]

It might be worth shifting such discussions to a format like an RFC and email list.

[joshuamckenty]

Bret and Noah and Jez and I discussed this at length yesterday (delegated validation) - I think an RFC format would be fantastic. Did you volunteer? :)

On Jul 1, 2016, at 12:24 AM, Greg Elin [email protected] wrote:

It might be worth shifting such discussions to a format like an RFC and email list.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[afeld]

This conversation is a bit wandering, so I'm going to close it in favor of breaking out to more specific issues/proposals. Let's do any schema change proposals in https://github.com/opencontrol/schemas, and any open-ended discussions (e.g. "should we do RFCs?") in https://github.com/opencontrol/discuss. Thanks!