Actuator Profile SC,
CURRENT TEXT
The current text is accompanied with a graphic. The original text was:
Figure 1 presents a notional OpenC2 implementation which illustrates cases were a firewall profile may be required and the components within the network that may interact with or be affected by OpenC2.
- OpenC2 Message Fabric: The transport mechanism for passing OpenC2 commands between OpenC2 compliant entities within the network.
- OpenC2 Producer: Products that send commands, receives responses, and manages the execution of a course of action involving one or more actuators. The orchestrator needs a priori knowledge of which commands the actuator can process and execute therefore
must implement the profiles for any device that it intends to command.
- OpenC2 Proxy: An abstraction of the firewall functionality that maps (or translates) OpenC2 commands to an appropriate API (i.e., a mitigation manager or vendor API).
- Device Manager: Interfaces with one or more physical or virtual firewalls. A device manager is a means to provide mitigation system management, which includes participation in OpenC2 workflow processing, transforming actions into a format suitable for a
given device, set of devices or capability within a device that provides the firewall functionality. A proxy between the OpenC2 message fabric and the device manager may implement the firewall profile and map the commands to the device manager’s API or the
device manager itself may natively support OpenC2 at its API (thus removing the need for the proxy).
- Proxy to Physical or virtual firewalls. An OpenC2 proxy must implement the firewall profile and map the commands to the vendor API.
- Native OpenC2 support: In the future, there may be devices that natively support OpenC2, and will be required to implement the firewall profile.
- Other Actuators: A product may provide multiple cyber defense mechanisms including firewall functionality as a subset of its capabilities thus the firewall profile is (in addition to other profiles) needed.
COMMENT:
I objected to this picture back in the forum and my objection still holds. I think proxy is the wrong word. I think too much focus on 'red'. I think 'device manager' is an undefined term that is really an orchestrator from an openc2 viewpoint. I think
too much emphasis on hardware. I think too much emphasis on pub/sub or 'bus'. I think most of picture is implementation that should be in IC-SC committee notes, not in AP-SC specification. I think a simple openc2 producer to openc2 consumer is all that is needed
here. I think this or another picture should include something that shows actuator may have more than one profile
MY REQUESTS:
Please provide alternate text.
Let us attain consensus on the bullets before we try to create a graphic to capture the bullets,
Provide the graphic.
====
Joe B