OpenControl Agenda topics

[its-a-lisa]

Output rendering

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?

document the development process

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 For substantial changes, we suggest opening an issue with a proposal before submitting a pull request. This way, the maintainers can focus on "what problem is this trying to solve?" and "is this the best way to do so?" without getting bogged down in the code itself.

create a welcome for vendors

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

Standard versioning and revisions

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

Create a verifier toolkit

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

Create a beta POA&M output

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.

Generate a Risk Management Framework (RMF) output

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

How to best to use Customer Responsibilities Matrices (CRM) in Schema

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

subdirectory structures in component repos

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

Include NIST control statements in output?

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.

update opencontrol org permissions

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:

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.

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.

One component control definition to implement multiple standards controls?

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.

Compliance Masonry templates can run executable specifications

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.

OpenControl edit workflow for non-technical users?

Some of the people responsible for writing controls documentation might have trouble following the OpenControl edit workflow of editing YAML files in source control because it's different from their current workflows (e.g. writing controls in a word doc) and YAML and git are new things that are easy to make mistakes with. Has anyone else encountered this issue in their work on OpenControl? Do you have any recommendations for handling it?

We could potentially support entering controls into a spreadsheet (or Word template?) and automatically converting that into OpenControl docs. But it's not clear to me that that would be much better than just having clear instructions for how people can edit yaml in source control.

Set of partials == complete?

For example, suppose we look at "Limit system access to authorized users" (800-171 3.1.1), and we apply it to desktop users. Part of the solution comes from the security policy saying this is required, but that, by itself, is not sufficient. Part of the solution comes from the system configuration that requires authentication. Again, that, by itself is good, but not sufficient. We also want a regular configuration audit that verifies that the configuration is actually applied and active. The combination of all three of these means the issue is covered.

It might be that I need to change how I have set up the OpenControl data. I am trying to split it out by various parts (security policy, active directory configuration, audit, etc). At one of my customer organizations, they have different roles responsible for these different parts, and it is convenient for each role to have a OpenControl set for which that person is responsible.

The key thing I want to avoid is duplication of data. As an example, the network underlies many systems. I do not want to have to duplicate the network onto desktops, individual (or clusters) of servers, etc just to be able to show that the security controls provided by the network are part of (not all of!) the needed controls. Note that not all systems are connected to the organization's network; cloud-based systems should not inherit much (if anything) from the network OpenControl data.

Risk assessment schema: Extend to three question types and provide validation

My review of the VA's risk assessment questionnaire shows there is at least three types of answer responses.

Text SingleOption MultiOption Recommendations If the YAML scheme does not have these three data response types, it will need to be extended to do so.

The YAML scheme also needs to provide the capability for data quality validation (i.e. for NULL, REQUIRED, MIN=1, MAX=1 responses) via scripts.

See specific example the three question response types, with data validation specified.

Translation of RiskVision controls spreadsheet to opencontrol YAML

We need to be able to import/export opencontrol YAML into such tools as RiskVision.

A sample RiskVision spreadsheet is located here, as well as recommendations on expanding the YAML scheme to accompdate the three response types ( text / single option / multiple-option)

https://github.com/vistadataproject/documents/tree/master/python#riskvision-schema-translation-to-yaml

OpenControl template

Originally posted by @timothy-spencer in #65 (comment):

I'm trying to make a template project that people can copy, add their app, and then use the mostly prepopulated opencontrol data while they are filling out their SSP by following along in the generated opencontrol gitbook as they work through their SSP. The text in the different sections should give them example content they can cut and paste in, or will give directions on what documents they should read to understand how to fill something out.

https://github.com/18F/gcp-appengine-template/blob/dev/README.md#ato-and-compliance-considerations

However, I have a few problems:

The opencontrol format is kind of undocumented (like how are you supposed to actually represent where to look for a control that you have inherited?), so I keep having to puzzle over how/where to write about things. Everybody seems busy, so I have yet to get anybody to give a serious look at the controls that I have written up so far. :-( I think that I have documentation that ISSOs will like, but I don't know for sure. The project is truly mostly aimed at the GSA LATO. It all maps back to 800-53 and all, so it ought to be relatively portable, but those are the only 24 controls that I have spent any time on at all. Nobody has actually used this project yet besides me. I'm not quite done with everything, so there are still rough spots. I'd like to think that having all this info prepopulated for somebody would save them a ton of time. I have spent a couple of months struggling with this, but if I had to do it again, I feel like I could just use this thing to zip through the process as I understand it.

Anyways, not sure if this is useful or not, but that's been my approach. I am trying to snowplow the difficulties away by creating most of the documentation up front in language that (I hope) security people will understand.

public SSPs?

I'm working on a project that involves natural language processing of System Security Plans (SSPs; #65). While I will be working with SSPs from within the agency, I'm looking for others that I can test with. Do you know of any SSPs / platform SSP templates that are publicly accessible? @Jkrzy just pointed me to the Azure one via @anweiss - wondering if there are others. Thanks!

As someone who isn't able to sign up for accounts, I want to be able to follow / participate in OpenControl

Currently, OpenControl has a few ways we do group communications:

GitHub issues, specifically in this repository Google Group Slack - join page The problem with all of these is that they require having/creating an account with that service, which is something people in many government agencies can't do freely. The requirements here are:

Users can to subscribe and reply to (at least a subset of) OpenControl discussions The above requires only an email address; email confirmation is good, but no "account creation" or acceptance of terms of service beyond that Easy and free/cheap for OpenControl to operate

Map Components to Multiple Certifications

Repost from certifications and standards repo,

Is there a way to use the same component file to track compliance with two certifications that use different marking taxonomies (e.g PCI and FISMA or SOC2 and FISMA)? If so, can someone share an example, love it.

I'm working on a project to maintain compliance with a couple different standards and certifications related to PKI. I'm not so much interested in writing an SSP (or CPS in the PKI world) as much as maintaining compliance with the standards when they change. Depending on the standard, they might be in the same format (RFC 3647) or just a bullet list. I wanted to use opencontrol to do this. It's not FISMA, but still a federal system and I'm not interested in FISMA it's outside of my scope.

code for parsing SSPs?

I'm looking around for open source code that parses SSPs / control information in various formats, regardless of what they do with those once parsed.

FedRAMP Challenges

Vendors must over scope controls in order to be "safe". Misunderstanding of control inheritance. RFI and RFP Challenges Privacy Act, Public PII, and Confidentiality 3PAO Policy Agencies Don't Know FedRAMP

[joshuamckenty]

This is a great list - is this the output of a meeting or brainstorm session? What's the context?