Create centralized certifications repo?

[shawndwells]

Right now we have the FedRAMP-Certifications repo. I'd like to expand the certifications to cover things like FISMA and 800-171/Controlled Unclassified.

One option would be to create multiple new repos, e.g. opencontrol/fisma-certifications, opencontrol/cui-certifications, but that seems unmanagable and slightly annoying.

Should a opencontrol/certifications be created instead?

e.g.

opencontrol/certifications
---- FedRAMP-low.yaml
---- FedRAMP-mod.yaml
---- FedRAMP-high.yaml
---- cui.yaml
---- etc

[anweiss]

I'm for it, however, how do you envision addressing the versioning aspect? We'll end up with a hierarchy of subdirectories just for keeping tracking of the versions of each cert

[afeld]

cover things like FISMA

https://github.com/opencontrol/NIST-800-53-Standards

how do you envision addressing the versioning aspect?

Discussion in #35.

[afeld]

Oh, sorry, you meant the FISMA baselines. Expanding the scope of the FedRAMP repo works for me.

[JJediny]

:+1: on creating a single repo for all certifications, suggest we rename the current fedramp-templates to certifications and consolidate the others

[shawndwells]

https://github.com/opencontrol/certifications is currently being used.... but looks abandoned for the past 2 years.

Proposing:

1. Refresh https://github.com/opencontrol/certifications to have just certifications, aka

   opencontrol/certifications
   ---- FedRAMP-low.yaml
   ---- FedRAMP-mod.yaml
   ---- FedRAMP-high.yaml
   ---- cui.yaml
   ---- etc

2. Would like to keep https://github.com/opencontrol/FedRAMP-Certifications around, but will add a "we've moved!" message for a month or two while people update their downstream code.

3. Create https://github.com/opencontrol/standards to house standards, such as NIST-800-53, 800-171, etc.

   opencontrol/standards
   ---- NIST-800-171.yaml
   ---- NIST-800-53.yaml
   ---- DISA-OS-SRG.yaml
   ---- etc

4. Add "We've moved!" message to README of https://github.com/opencontrol/NIST-800-53-Standards for a month or two, after which the repo will be removed.

I'm happy to do all this, but @afeld, I'll need repo creation privileges. [edit: never mind, apparently I have those permissions]

[shawndwells]

sample PR for updated certification repo: https://github.com/opencontrol/certifications/pull/2

edit: see also: https://github.com/shawndwells/certifications

[shawndwells]

sample repo for standards: https://github.com/opencontrol/standards

[gregelin]

I think it makes sense to consolidate the reference “certification” files. However, I agree that versioning is an issue. I would consider using an appendix on the standards so we can distinguish between RMF v4, R5, or other changes.

Below is an example with using years and appendices.

opencontrol/certifications
-- base
---- FedRAMP-low-2017.yaml
---- FedRAMP-mod-2017.yaml
---- FedRAMP-high-2017.yaml
---- cui-2017.yaml

[shawndwells]

@gregelin : Why? Once a new edition is out (e.g. with NIST), it's applicable immediately. Once $futureVersion is out, $oldVersion is no longer valid.

[shawndwells]

And also -- versioning can be a separate issue to track (vs creating the standard repos). That conversation is happening in https://github.com/opencontrol/discuss/issues/35

[gregelin]

@shawndwells Definitely possible to address this by creating other repositories. Just a vote for thinking about some naming conventions. If we are creating one repository as a basic reference for certifications.

Certifications are is just listings of applicable controls, It's likely different agencies will require slightly different controls for Low, Med, High. It's going to be annoying if I decide to generate artifacts from a certification that's published in a repo and then suddenly the controls list is modified. That's going to going to change my SSP.

That said, if it's just a reference to get people started...well, then it is just a reference and we want to manage expectations appropriately.

[openprivacy]

It would be good practice to reference by tag, commit or branch

[shawndwells]

Bump on this. Any objection to using the (apparently) unmaintained https://github.com/opencontrol/certifications repo to aggregate the various certifications?

[shawndwells]

(versus having a dedicated repo for dozens of certs)

[jasswalkjr]

@shawndwells, et. al., have you all seen the OSCAL-OpenControl Technical Integration Proposal? I'm excited about its possibilities: https://docs.google.com/document/d/1xsSceSbPtTHYv4zKmu-qwKkFb6Y3LDw9KivQ-Dx6zBA/edit#heading=h.l1u0b930zo1b

@anweiss also published a blog post about integrating OSCAL with Docker: https://blog.docker.com/2018/05/automating-compliance-docker-ee-oscal/

[shawndwells]

On 5/9/18 8:36 AM, jasswalkjr wrote:

@shawndwells https://github.com/shawndwells, et. al., have you all seen the OSCAL-OpenControl Technical Integration Proposal? I'm excited about its possibilities: https://docs.google.com/document/d/1xsSceSbPtTHYv4zKmu-qwKkFb6Y3LDw9KivQ-Dx6zBA/edit#heading=h.l1u0b930zo1b

@anweiss https://github.com/anweiss also published a blog post about integrating OSCAL with Docker: https://blog.docker.com/2018/05/automating-compliance-docker-ee-oscal/

Still learning more about that work. Red Hat reached out to the OSCAL gov team in the past. Was told that was a government-only initiative and industry participation was not welcome at the time. Very surprised to hear they converted the project to a private initiative with Docker and C2; especially since others in industry and government were not invited to collaborate.

[jasswalkjr]

@shawndwells, NIST wants feedback on OSCAL now. In fact, they specifically want feedback from the OpenControl community because of all of the changes they are proposing.

[shawndwells]

On 5/9/18 6:19 PM, jasswalkjr wrote:

@shawndwells https://github.com/shawndwells, NIST wants feedback on OSCAL now. In fact, they specifically want feedback from the OpenControl community because of all of the changes they are proposing. Haven't seen any postings by them in discuss. Also pinged other industry companies shipping OpenControl content -- none of us have been contacted. Tried to join the OSCAL mailing lists but their website is down [0].

[0] https://github.com/usnistgov/OSCAL/issues/164

[gregelin]

I support aggregating various certifications there...

Greg Elin

Greg Elin CEO, GovReady PBC p: 917-304-3488 e: gregelin@govready.com

On Tue, May 8, 2018 at 8:23 PM, Shawn Wells notifications@github.com wrote:

Bump on this. Any objection to using the (apparently) unmaintained https://github.com/opencontrol/certifications repo to aggregate the various certifications?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/opencontrol/discuss/issues/36#issuecomment-387582445, or mute the thread https://github.com/notifications/unsubscribe-auth/AABhk5OS9cavDIxx_MkHlPjkEdt4puV6ks5twjbxgaJpZM4Qaao9 .

[shawndwells]

Many people were out last week for the Red Hat, Google, or Microsoft conferences... so bumping to @afeld.

Any objections to re-creating the github.com/opencontrol/certifications/ repo and using that to house OpenControl certification content? Unifying the fedramp, securitycentral, and other repos. Current project is three year old fork of another project, and the involved parties don't seem to be around anymore.

Willing to do the re-creation, but would need org perms on the main opencontrol repo.

[david-waltermire]

I am the technical lead of the Open Security Controls Assessment Language (OSCAL) project. I wanted to give a quick update on OSCAL and address some of the comments above.

@shawndwells We had posted the wrong information for joining the mailing lists. This has been fixed in the CONTRIBUTING.md, which now shows the correct information. Please try to join again.

@gregelin We are wrapping up Sprint 10 today, and are working to publish updated SP 800-53 rev4 catalog, SP 800-53 rev4 low, moderate, and high baselines, and FedRAMP low, moderate, and high baselines. The FedRAMP baselines show the delta between the FedRAMP baseline and the corresponding SP 800-53 rev4 baseline. We still need to regenerate the JSON versions, so only the XML versions are posted at the moment. You can find these in the examples directory.

@shawndwells The OSCAL project is a public effort that welcomes and encourages industry participation. I am not sure who told you it was private and closed, but I assure you it is the opposite. For some time we developed using a private repo, but even then we welcomed outside participation and had a number of non-NIST participants following and contributing to the project. At this point, all of our work is publicly accessible on GitHub.com, with documentation on pages.nist.gov.

We are currently wrapping up some cleanup on our SP 800-53 rev4 catalog; SP 800-53 rev4 low, moderate, and high baselines; and the FedRAMP low, moderate, and high baselines. This cleanup will create a solid foundation for our work on the OSCAL implementation layer in the next sprint, sprint 11.

In Sprint 11 we plan to focus on two major areas:

1. Documenting a more complete roadmap to better illustrate where we are heading with the OSCAL effort.
2. Development of the OSCAL implementation layer. We hope to created an early prototype of the OSCAL implementation layer using the OpenControl component schema as inspiration. We will be integrating this layer with the exiting OSCAL catalog and profile layers.

We welcome help from the OpenControl community on this and future sprints. There are a few ways you can help:

1. Review existing OSCAL work. We always appreciate your feedback. Feel free to join the oscal-dev@nist.gov list to discuss aspects of OSCAL with the community.
2. Provide comments on the OSCAL user stories related to the implementation layer and catalog and profile efforts.
3. Create new user stories. We will consider these for work in future sprints.
4. Become a member of our development team by volunteering to work on a user story or two. We are always looking for volunteers that have XML and JSON data modeling, and controls assessment experience. We are also looking for people willing to work on open source tooling to support OSCAL use and content creation. If you are interested in helping in these ways, please email us at oscal@nist.gov.

[shawndwells]

@gregelin looks like you're the only active person with org-level permissions on the OpenControl repo. Would you mind removing the old repo & re-creating it? Ideally having a number of people added to be able to merge PRs against it. From Red Hat, this could be one or both of @redhatrises (Gabe Alford) and myself.

[shawndwells]

@david-waltermire-nist NIST informed us it was a private collaboration. Sent you a direct EMail to discuss offline.

[gregelin]

Will do over the weekend

Sent from my iPhone

On May 25, 2018, at 12:40 PM, Shawn Wells notifications@github.com wrote:

@gregelin looks like you're the only active person with org-level permissions on the OpenControl repo. Would you mind removing the old repo & re-creating it? Ideally having a number of people added to be able to merge PRs against it. From Red Hat, this could be one or both of @redhatrises (Gabe Alford) and myself.

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

[shawndwells]

On 5/25/18 2:32 PM, Greg Elin wrote:a

Will do over the weekend

Thanks, @gregelin!

[openprivacy]

We should also revisit possible future use for https://github.com/opencompliance that Greg and I have but have never really used. Could be a good place for developing a set of common controls (components) that could feed into various compliance frameworks (800-53, 800-171, HIPAA, ISO 27000, etc.)

[gregelin]

@shawndwells Its been a busy week and am looking at your request to update repo https://github.com/opencontrol/certifications to focus on certifications.

As per your comments in https://github.com/opencontrol/discuss/issues/36#issuecomment-344807610 there are likely some other repos depending on the current configuration of the opencontrol/certifications/ repo's existing structure.

Let me spend a little more time looking for some dependencies and then we will make changes. I want to make sure there are at least the two of us creating a record of the changes.

[gregelin]

@openprivacy Agree with Fen about revisiting future use of https://github.com/opencompliance.

BTW I'd like to move this whole thread to the mailing list.

[shawndwells]

On 5/31/18 9:27 AM, Greg Elin wrote:

@shawndwells https://github.com/shawndwells Its been a busy week and am looking at your request to update repo https://github.com/opencontrol/certifications to focus on certifications.

As per your comments in #36 (comment) https://github.com/opencontrol/discuss/issues/36#issuecomment-344807610 there are likely some other repos depending on the current configuration of the |opencontrol/certifications/| repo's existing structure.

Let me spend a little more time looking for some dependencies and then we will make changes. I want to make sure there are at least the two of us creating a record of the changes.

I don't understand. The https://github.com/opencontrol/certifications repo hasn't been used for the last 3 years, and even then, it was a fork of something else. Would blow it away so can be used for something productive.

[shawndwells]

On 5/31/18 9:28 AM, Greg Elin wrote:

@openprivacy https://github.com/openprivacy Agree with Fen about revisiting future use of https://github.com/opencompliance.

The "what project will develop content" land grab should be it's own independent conversation :) This ticket is just for creating a central certifications repo of opencontrol-formatted content.

BTW I'd like to move this whole thread to the mailing list.

What mailing list?

[afeld]

Deleted the old https://github.com/opencontrol/certifications repository, so feel free to recreate. As this thread digressed in multiple directions, please open up new issues or whatever for the breakout conversations. Thanks!

Once a new edition is out (e.g. with NIST), it's applicable immediately. Once $futureVersion is out, $oldVersion is no longer valid.

--> https://github.com/opencontrol/discuss/issues/35#issuecomment-394178911

[gregelin]

@shawndwells @afeld I wanted to make sure there were no existing OpenControl repos that were referencing the yaml files there. I did a search on GitHub and did not see any.