Open tohch4 opened 3 years ago
@tohch4 Are you suggesting that ARS be an overlay on top of default 800-53? This is what I would like to see...
@tohch4 Are you suggesting that ARS be an overlay on top of default 800-53? This is what I would like to see...
It seems @tohch4 is inactive. But given reference to the FedRAMP code base I had reviewed, this seems to be exactly the goal of the issue.
@xee5ch - Looking at ARS 5.0 it appears straightforward to define organization defined parameters for the Control Statement. But ARS also changes the Guidance (renamed “Discussion”) and adds a collection of additional sections:
How can we fit these into a profile? Does OSCAL allow for the addition of new “guidance” sections like this?
@openprivacy, it looks like I have fallen out of step with the times. It appears it was ARS 5.0 was officially published on the official CMS ISPG library site? I somehow missed official word of this!
Let me take a look and get back to you on these very important questions!
OK, so I took a look. Replies below, I think we could start working together on this, but I need to ask around about the implementation standards.
@xee5ch - Looking at ARS 5.0 it appears straightforward to define organization defined parameters for the Control Statement. But ARS also changes the Guidance (renamed “Discussion”) and adds a collection of additional sections:
Great, we are on the same page regarding Guidance being renamed Discussion. That is easy.
* Implementation Standards
This bit I am unsure of, but it would seem we can add a part
with a @name
of implementation-standard
or something suitable and add it below. I guess I would like to dig deeper on "the right way" in a dev meeting with the NIST team and community members to discuss, in some cases, how parameter
s in some cases are interlaced with the implementation standards. So, if we look at the current 800-53B+800-53A catalog for AC-2(2):
<control class="SP800-53-enhancement" id="ac-2.2">
<title>Automated Temporary and Emergency Account Management</title>
<param id="ac-02.02_odp.01">
<select>
<choice>remove</choice>
<choice>disable</choice>
</select>
</param>
<param id="ac-02.02_odp.02">
<label>time period</label>
<guideline>
<p>the time period after which to automatically remove or disable temporary or emergency accounts is defined;</p>
</guideline>
</param>
<!-- More parts of the control snipped, not relevant for this convo. -->
</control>
You will notice that the implementation standard for this in CMS ARS 5.0 is textually similar, and includes some stuff that are not just parameter overrides (ac-02.02_odp.02
param for a time range) in cell F9:
High & Moderate:Std.1 - Emergency accounts will be automatically disabled within 24 hours of activation;Std.2 - The duration of temporary accounts will not exceed: (a) 30 days for High systems and (b) 60 days for Moderate systems.
So why do I bring this up? Some of it could be "part of the modified control in the catalog" and some of it is in the guidance or other details. Maybe we can work a bit on the first few controls with a pipeline and look at the result and workshop it?
* Privacy Discussion * Privacy Implementation Standards * HVA Discussion * HVA Implementation Standards
How can we fit these into a profile? Does OSCAL allow for the addition of new “guidance” sections like this?
Ok, so the rest of these? Whenever we have HVA and Privacy or some overarching category of system categorization, that is really a separate profile. At least this is how it is generally done and a profile is analogous to what they call in USG cybersecurity space a "control overlay." Hat tip to an internet friend, trevor.
https://github.com/trevorbryant/usgov-controls
Those are not in OSCAL, but you can start to get the idea. But you have seen in the FedRAMP codebase before. So what we really need to consider, and I think upstream NIST source is the same as well. Notice they extract out controls that are privacy-relevant into "an overlay" as part of its own catalog. This is practical and represents some real-world complexity, you can have a Moderate or High impact system ala a FIPS-199 categorization that would not include privacy enhancements in an overlay/profile, or you could have them included with Moderate+Privacy or High+Privacy. It depends on the privacy impact of the system. As it stands, we can see OSCAL profile resolution supports the mechanics of that system pretty well.
This is excellent insight, thank you!
The impact level baseline (Low, Moderate, High) would be applied to the initial catalog (in this case, the ARS default) so that Privacy, etc could add their required controls. If there were a HVA + Privacy system, would the order in which the Profiles were applied/resolved matter?
It would be great to create a mini-catalog (remember Freedonia?) with just a couple controls where we could demonstrate this pipeline.
This is excellent insight, thank you!
De nada! Thank you for including me in this. I think it is good the community live by practice, and I want to see some real-world catalogs outside of just NIST (even though they are the origin of our RMF world, :laughing:).
The impact level baseline (Low, Moderate, High) would be applied to the initial catalog (in this case, the ARS default) so that Privacy, etc could add their required controls. If there were a HVA + Privacy system, would the order in which the Profiles were applied/resolved matter?
Yes, this was recently clarified in the profile resolution spec updated in usnistgov/OSCAL#1017, I believe: last profile always wins. They are imperative, not so much declarative. Let's say you have a catalog, Profile1, Profile2. You apply profile 1 to catalog and get Catalog1 (derived from Profile1) and then derive another catalog, maybe you keep Catalog1 or not, and then apply Profile2 two that. Conflicts can happen, and the commands in the last profile applied should/would always win out.
It would be great to create a mini-catalog (remember Freedonia?) with just a couple controls where we could demonstrate this pipeline.
We could do that, or we could even spec 2-4 controls here of the actual material and focus on just those. Either way, I am flexible. Setting up an example pipeline (I can fork from here) and show "changes to original 800-53A full catalog") I feel could be very informative. Thoughts?
we could even spec 2-4 controls here of the actual material and focus on just those
This is what I meant, though I confused things a bit (by mentioning Freedonia). The full ARS 5.0 is available at https://www.cms.gov/research-statistics-data-and-systemscms-information-technologyinformationsecurityinformation/acceptable-risk-safeguards-50 - we have some rough tooling that may help in converting this to OSCAL (haven't tried yet).
We only need to show the pipeline working for 2-4 controls to demonstrate the possibility. (I've asked if I can grab the recently dropped ARS 5.0 Moderate baseline.) I believe this could be very informative for all of us. ;)
we could even spec 2-4 controls here of the actual material and focus on just those
This is what I meant, though I confused things a bit (by mentioning Freedonia). The full ARS 5.0 is available at https://www.cms.gov/research-statistics-data-and-systemscms-information-technologyinformationsecurityinformation/acceptable-risk-safeguards-50 - we have some rough tooling that may help in converting this to OSCAL (haven't tried yet).
We only need to show the pipeline working for 2-4 controls to demonstrate the possibility. (I've asked if I can grab the recently dropped ARS 5.0 Moderate baseline.) I believe this could be very informative for all of us. ;)
Cool, let's make it happen! I am sure we can make headway. Judging from the Excel spreadsheet, we can infer the baseline mappings for Low, Moderate, and High as well anyway.
I'm going to be working this week to turn that spreadsheet into JSON-formatted OSCAL (maybe one for each impact level).
I definitely encourage you to experiment, can I also work out by sometime next week a MVP to show:
Let me know if that appeals to you? It is really not that bad!
Also, I am willing to meet up from time to time (it will have to be in the late afternoon or evenings in New York/UTC-5 time zone to show the sausage as it is made, if you want to experiment, ask questions, and get deeply involved with what I am proposing, even if it is a throwaway. I am game for it!
Very appealing. I want to experiment, ask questions, and get deeply involved with what you are proposing. Late afternoons/evenings will work. I am game for it, too!
Sure thing, can I ping you on Gitter? Tonight might not be great but I can make more time tomorrow and/or the afternoon of Thursday. Let me know!
So, today's OSCAL Workshop 2022 breakout session on this topic was very informative, so I will use the reference material from that session to guide my work here in the draft WIP PR above.
More updates to follow.
@GaryGapinski, I see you have been busy and the profiles and catalogs are shaping up nicely. Can we talk Friday or later this week about this issue and how I can help?
FedRAMP developers take catalogs directly from NIST OSCAL and customize them so you can easily track from revision to revision of RMF 800-53 updates. In the long-run, it makes collaborative review and changes easier to push across the community over time. Can we do similarly for CMS?
I am also definitely willing to help with this effort. I have many colleagues working on CMS projects who would appreciate this effort, let me know how I can help!