Controls endpoints?

[flickerfly]

I'd like to start adding endpoints. My first use would be to get the content for a specific control. This might support an interface where I have control references and then some javascript that would provide a modal with the contents when I hover over it or something like that.

[rgauss]

Hi @flickerfly, thanks for raising the issue.

Are you envisioning things like:

GET /catalogs/{catalogId}/controls/{controlId}
GET /catalogs/{catalogId}/groups/{groupId}/controls/{controlId}

which would probably require related:

GET /catalogs/{catalogId}/controls
GET /catalogs/{catalogId}/groups
GET /catalogs/{catalogId}/groups/{groupId}/controls

Can you give a little more detail on how the app would know the control IDs but presumably not have the full catalog contents already?

[flickerfly]

I'm thinking more about looking up controls by something like NIST 800-53 name like ia-3 or the like.

Also, I can see situations where an app may store a relationship between evidence of satisfying that control without saving the whole catalog, and wanting to provide details on the control or gather related CCIs or Stig rules to that control without needing the whole catalog.

[rgauss]

I'm thinking more about looking up controls by something like NIST 800-53 name like ia-3 or the like.

Yes, in the proposed endpoints above, for 800-53 rev 4 that would like:

GET /catalogs/b954d3b7-d2c7-453b-8eb2-459e8d3b8462/groups/ia/controls/ia-3

since the 800-53 rev 4 catalog uuid is b954d3b7-d2c7-453b-8eb2-459e8d3b8462 and that catalog groups the ia-3 control under the ia group.

A 'shortcut' call could potentially be used to get straight to the control without specifying the group:

GET /catalogs/b954d3b7-d2c7-453b-8eb2-459e8d3b8462/controls/ia-3

Also, I can see situations where an app may store a relationship between evidence of satisfying that control without saving the whole catalog, and wanting to provide details on the control or gather related CCIs or Stig rules to that control without needing the whole catalog.

Sure. In many cases that app will have had to 'resolve' the controls in question through a profile, which complicates things, and app developers will of course need to weigh the cost/benefits of repeated REST calls for multiple control details vs the giant payload of an entire catalog for their particular use case, but it still seems like a useful option to have.

[flickerfly]

I was thinking that the controls could be addressed without a catalog involved. My use would often have catalogs that are derivatives of 800-53r4 for a specific situation and I've been thinking that control would simply be collection of independent controls, but I think I see why it needs to be associated with the catalog after your explanation. Thank you.

I expect that API implementers will also need to evaluate the need for rate limiting of the API to encourage good decisions in relation to repeated REST calls. That leads to realizing that there is no 429 definition in the API.

[rgauss]

My use would often have catalogs that are derivatives of 800-53r4 for a specific situation

Ah, OK, that's typically represented as an OSCAL Profile which is then used by a System Security Plan.

For example, the example SSP imports the 800-53 moderate profile which adds a P1 priority to the ia-3 control from the 800-53 rev4 catalog.

Profiles can also import other profiles, so an organization can create a further tailored version of an existing baseline.

[flickerfly]

Hope you had a Happy Thanksgiving!

Thank you for helping me understand. That's above and beyond!

If EasyDynamics has any non-open source products who would I talk to about checking those out?

[flickerfly]

@rgauss Do you have thoughts about how sub-controls/enhancements should be managed?