Day +1: A Call to Arms to Help Realize the "Compliance as Code and Improving the ATO Process" Policy Paper

[xee5ch]

@openprivacy and others, let's start the discussion. I had read the Day One Policy Paper on Compliance as Code and improving authorization outcomes for overburdened federal agencies and needless to say, this was a key reason I took conversations overhead at the 2nd OSCAL Dev Days much more seriously and knew it was time to take my part.

How can community adopters, implementers, and advocates, get the word out and help with any of the objectives below?

1. Study IT System Acquisition Rules for Vendor Compliance Information
2. Examine and Improve the Utility of System Security Plans (SSPs)
3. Create a Federal Compliance Library
4. Explore Open Security Controls Assessment Language (OSCAL)

Personal and professional experience has taught me that those with the cross-sectional skill-set to help with all the pieces of the puzzle, for one or all of the four goals, is rare and I think we need to give people actionable ways to help. Help me help you!

(P.S. There are several typos in the PDF I had not noticed a week or two ago, can you tell me here, or privately if you prefer, who I can contact to have those fixed with you or for you? Thanks!)

[openprivacy]

Some quick thoughts:

1. out of my wheelhouse
2. once compliance is code and ongoing authorization is implemented, do we need SSPs?
3. a distributed, git-based library of OSCAL component templates, documentation and verifiers is key to reducing toil
4. looking at methods to refactor existing SSPs into OSCAL reusable components as well as tools to compose known components to manage system compliance

@xee5ch - you can feed any PDF typos to me and I will pass on to Mary, the primary author. Thanks!

[xee5ch]

Some quick thoughts:

1. out of my wheelhouse

Fair enough!

2. once compliance is code and ongoing authorization is implemented, do we need SSPs?

Excellent question, what about before? I see SSPs getting lighter before continuous authorization, but can they ever go away for good?

3. a distributed, git-based library of OSCAL component templates, documentation and verifiers is key to reducing toil

100%. Is leaving them as free-form git repositories good or we interested in a component library and building clients to pull them down, like pip or npm?

4. looking at methods to refactor existing SSPs into OSCAL reusable components as well as tools to compose known components to manage system compliance

Sounds good, I have been thinking about this actively and would like to come up an approach with OSCAL extension models in flight, but I am learning how to do that well, now!

@xee5ch - you can feed any PDF typos to me and I will pass on to Mary, the primary author. Thanks!

Sorry, I hit update too soon. Yes, @openprivacy, will do so by tomorrow morning!