Standard versioning and revisions

[jenglish]

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

[johnmod3]

I think this is looking at the problem in an old way, I think mass RMF revisions should go away and instead we need atomic level updates to specific controls and tests.

[openprivacy]

+1 The age of massive updates and 3-year ATOs is gone - black hats don't work on that schedule. But a huge legal and cultural shift must take place at NIST and the DHS and every FISMA-reportable agency before they get it. OpenControl is helping show the way, but don't hold your breath. Until then, we'll have to continue to demonstrate compliance while we build in security as a "side" project.

On Tue, Nov 7, 2017 at 6:31 PM, John notifications@github.com wrote:

I think this is looking at the problem in an old way, I think mass RMF revisions should go away and instead we need atomic level updates to specific controls and tests.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/opencontrol/discuss/issues/35#issuecomment-342659403, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJlp6xQM_qpGDCdFV8GppyoLNxFC78rks5s0OhngaJpZM4QVlYs .

[afeld]

@jenglish Probably easiest to treat them as entirely different Standards. Happy to accept a pull request to the 800-53 repository to add other revisions.

[jenglish]

I was thinking of using git branches for this. e.g. instead of specifying:

dependencies: standards:

• url: https://github.com/GovReady/NIST-800-171-Standards revision: master

that pulls in NIST-800-171r1.yaml from the master branch, you could have separate branches for each revision, each containing NIST-800-171.yaml (unsuffixed). I will try setting up my fork of the GovReady repo that way and see how it works...

[shawndwells]

On 11/9/17 4:33 AM, Joe English wrote:

I was thinking of using git branches for this. e.g. instead of specifying:

dependencies: standards:

• url: https://github.com/GovReady/NIST-800-171-Standards revision: master

that pulls in NIST-800-171r1.yaml from the master branch, you could have separate branches for each revision, each containing NIST-800-171.yaml (unsuffixed). I will try setting up my fork of the GovReady repo that way and see how it works...

Is indicating revisions important? Once a new revision is out, isn't the old one antiquated/unsupported?

Branches make things overly complex. If the control list is out of sight, it's out of mind. Would rather have NIST-800-171-{r1 .. rX}.yml in a single directory. This would also work with existing downstream tooling, versus having people rewrite how they pull in standards.

[afeld]

Once a new revision is out, isn't the old one antiquated/unsupported?

Yes, but in practice, the old one stays in use, especially for a transition period.

[shawndwells]

Has been included in the https://github.com/opencontrol/standards repo for a few months. PRs can re-open the conversation :)

[its-a-lisa]

Is this overcome by events or is this still an open issue? If open and the schema plans to live on, I suggest collaboration with the OSCAL folks to understand how they approach the problem.