Enabling CSPs/ISVs to easily develop initial "implementation" artifacts for their software
anweiss opened this issue · 3 comments
In the early phases of OSCAL where tooling will be scarce (and this also holds true for OpenControl today), we're going to be faced with a "chicken-and-the-egg" scenario whereby CSPs/ISVs must still go through the initial exercise of actually correlating their services/software to security controls to create their OSCAL "implementation" artifacts and get to an initial machine-readable state. Some might argue that this process in and of itself is still the same process CSPs/ISVs go through today without OSCAL. This could slow the adoption of OSCAL as this process can still be painstakingly slow and tedious.
As such, we should think about approaches that can help CSPs/ISVs more easily conduct these correlation exercises. This could be in the form of guidance, additional functionality built in to oscalkit, re-work of the OpenControl-Editor, etc.
I think this needs to be part of the design for the implmentation model(s). One way of thinking about the implementation layer is breaking it in two models:
- vendor implementation: Allows the vendor to map capabilities in their service or software component to controls in one or more catalogs.
- end-user organization implementation: Allows the user organization to identify the components used, inheriting the data provided by the vendor.
Status Meeting: 8/23/2018
This issue was not assigned yet to any team member. It is not an urgent issue, but need to be addressed in the future. Needs discussion.
This work is being done in #216. Closing this issue