Passing a command to an endpoint when the Target field is already populated #31
Comments
|
Related to oasis-tcs/openc2-oc2arch#39 The Message layer currently defined in Language Spec section 3.2 should probably be moved to the Architecture spec. But the Language Spec defines the fields of a command, it must be clear that "Actuator Profile" is a function, not a device, and the "actuator" field of a command identifies a profile, not a device. The consumer(s) to whom a command is addressed go in the "to" field of a message. It could be a hostname for http transfer or a topic for pub/sub (mqtt) transfer. Once a command is received by one or more consumers, they decide what to do with it: process it if they support the function in the "actuator" field, or ignore it otherwise. If the consumer supports the edr function but the command has no "actuator" field, the consumer attempts to execute the command as if the actuator field said edr. This example could be (from LS): |
* Updated "EDR"/"Endpoint detection and response" to "ER"/"Endpoint Response" where relevant * Removed all actuator specifiers save for "hostname", tied to issues oasis-tcs#30 and oasis-tcs#31 * Updated Michael Rosa as chair * Added Michael Rosa, Joe Brule and Russel Warren to acknowledgements * Fixed heaps of errors in formatting and spelling Will update to the new template (used by Posture Attribute Collection) once open PR's are merged
|
@dlemire60, I like your term "downstream target" from ap-pac #6. I think it lends itself well to an argument, which I'm increasingly in favor of implementing this functionality as. This is especially since it lets us specify which commands either supports or MUST include a downstream target in order to be consumed: commands like "contain file" are specifically meant to be targeted at a single endpoint. So something like this: Type: Downstream-target (Map{1..*})
Command Arguments Matrix
{
"action": "delete",
"target":{
"file": {
"hashes":"..."
}
},
"args": {
"edr": {
"downstream_target":{
"endpoint":"Host123ABC"
}
}
},
"actuator": {
"edr": {
"hostname":"edr.organization.tld",
}
}
} |
|
I agree that args is the cleanest place to specify downstream devices. How about something like: "args": {
"er": {
"endpoints": {
"names": ["Host123ABC", "Host123DEF"],
"groups": ["group1", "group2"],
"selector": "some pattern expression"
}
}
}If a command included no endpoints arg, the OC would perform the command for all endpoints under its control. As above, the Orchestrator Consumer address "edr.organization.tld" has to go in the message "To" address, otherwise the OC will never receive the command. |
|
Heres a summary for today's ad-hoc meeting: Summary of the issue
Example argument: "args": {
"er": {
"downstream_consumers": {
"tenant": "some tenant specifier",
"endpoints": {
"names": ["Host123ABC", "Host123DEF"],
"groups": ["group1", "group2"],
"selector": "some pattern expression"
}
}
}
} |
|
Notes from the meeting: Issues discussed
Suggested Solutions
Actions
Other notes
|
Actions
When defining new 1.1 commands we should mentally translate the "actuator" property to "profile". With profile being "document that defines the operations performed by the consumer", profile specifiers is equivalent to "command arguments that apply only to this profile". We should consider if there are any use cases where profile specifiers do not fit in args, and if there are none, simplify the command by eliminating profile specifiers. |
It is an "actuator" but as we discussed in the last meeting and also @davaya mentions right below, from an "OpenC2 language" perspective the semantics are different, meaning the actuator refers to a profile and the specifiers to something pertinent to the profile. So we need to go with defining a ´downstream device´ concept that will fit into the arguments segment of the command. One aspect/constraint to take into consideration is the need for this concept in more actuator profiles. A more representative definition should be incorporated at the LS level. |
Added tenant_id Actuator Specifier As discussed in ad-hoc meeting, meeting notes can be read in issue #31
As mentioned in issue #30, we need a way for the AP to say things like "delete this file on this endpoint".
In this example the ER AP uses the Action "delete" paired with the Target "file", leaving us without a way to refer to the target endpoint that the actuator is to execute the Command on.
The problem stems primarily from the fact that the endpoint itself is not an actuator. However in order for e.g., a file to be deleted from a machine, there has to be something on the endpoint which performs the deletion. This varies from vendor to vendor, and it's difficult to find technical write-ups or good source describing the actual mechanics, but boils down to some sort of process or service running with elevated privileges that receives and executes a command from the EDR server.
I have also yet seen an EDR API which even mentions this program/service. All of them use some sort of unique ID tied to the endpoint itself to specify the target endpoint.
With all that in mind, here are two suggestions on how we can implement this in the AP:
Suggestion 1: Refer to the endpoint in the actuator specifiers map
Sample command
{ "action": "delete", "target":{ "file": { "hashes":"..." } }, "actuator": { "edr": { "hostname":"edr.organization.tld", "endpoint_id":"Host123ABC" } } }Suggestion 2: Refer to the endpoint using a Command Argument.
Type: Actuator-target (Map{1..*})
An added benefit here would be that we can denote which Commands this argument can be paired with in the Command Arguments matrix.
Table 2.3-2. Command Arguments Matrix
[...]
Sample command
{ "action": "delete", "target":{ "file": { "hashes":"..." } }, "args": { "edr": { "actuator_target":{ "endpoint_id":"Host123ABC" } } }, "actuator": { "edr": { "hostname":"edr.organization.tld", } } }The text was updated successfully, but these errors were encountered: