Representation of telemetry #7
Description
Author Use Case: As a developer of compliance agents or similar mechanisms, I want to ensure compliance findings are transmitted such that an aggregating capability is able to receive and interpret the findings. The findings must be tied to specific components, controls, and automated validation activities.
Consumer Use Case: As the creator of tools and dashboards that aggregate continuous compliance telemetry from many different sources, I want to ensure all telemetry arrives as consistently as possible and with sufficient detail to provide deeper analysis and unambiguous reporting.
Example: I have a dashboard of compliance findings that is fed from multiple different sources, such as infrastructure devices (switches, routers, firewalls), a shared ICAM/Identity Management capability, and dedicated system components that include a web/API server and database server.
I want the telemetry from each of these sources to use the same format. Further, I need to be able to associated any specific finding (good or bad) with specific component(s), control(s), and test specifications. This not only enables my dashboard to know the compliance health of each system component, it also allows my dashboard to know if it is missing telemetry for specific components or if specific tests are not running as specified.
Additional Comments
This issue primarily targets the OSCAL assessment results model, but involves correlation with assessment plan (testing specification), SSP (components and inventory), and catalog(s)/profile(s) (applicable controls).