Architecture Flows

[davaya]

The Architecture Use Cases section starts with Putting an SBOM into PACE:

"Decision-making element (e.g a SOAR running a CACAO playbook eg {fillinhere}) sends OpenC2 command, (eg {fillinhere}), telling PCS to retrive SBOM from device_id=2345."

This is an IT Asset Management question - it is not sufficient to say ITAM is "inside" or "outside" of PACE - the DM must know about assets in order to send a command, and PCS must know about assets in order to respond to a command. Whether ITAM is "inside" or "outside", it needs an interface in order for the DM or PCS to query it. That is why we need to think more carefully about how to implement the use case; it's not just a matter of writing actuator profiles because OpenC2 acts at the application, not transport, layer. What does "device_id=2345" or "ComponentX" mean? How is an OpenC2 message addressed and routed so that it can be seen by ComponentX in the first place?

I can think of at least three ways for that to happen:

1. Somebody populates the PAR with a list of "device_id" and their IP addresses before the first command can be sent to the PCS. The format of device_ids and the information attached to them has to be defined, as is the mechanism for how the DM obtains that information.
2. Devices are required to subscribe to a pub/sub topic, thus registering their device_ids and interest in receiving OpenC2 commands. How does the DM obtain device_ids from the subscription information, before the first command is sent to the PCS?
3. Something sniffs the integration bus looking for ARP traffic from devices, DM obtains a list of active IP addresses from the sniffer by some mechanism, then sends query features to each IP address to find out which ComponentX's support the SBOM profile. All before the first message can be sent to the PCS.

I'm sure there are a zillion other ways as well, but we have to describe what the DM does in more detail than just "send a command to the PCS". This update shows the first interaction with the DM asking the PAR "what components exist?" (0a) and returning the set of components that the PACE can manage (0b). Regardless of how PACE is implemented, the DM needs that information before it can ask the PCS to put an SBOM for that component into PACE. It could query the PCS or PAR for the components, but asking the PAR is more direct since that's where the information exists if ITAM is "inside" PACE.

OC2_Get_SBOM_Arch2