search

oasis-tcs / openc2-apsc-stateless-packet-filter

OASIS OpenC2 TC: A GitHub repository is to provide configuration management and to aid in the development of the first generation OpenC2 firewall profile
https://github.com/oasis-tcs/openc2-apsc-stateless-packet-filter
Other
6 stars 10 forks source link

Expand Query command #117

Open alevere opened 4 years ago

alevere commented 4 years ago

An orchestrator or producer of commands needs a way to know the state of an slpf and a better way for determining what it supports. For instance, it may need to know the rules in place or it may need to know if the AP is conformant to the Temporal Consumer requirements. I propose we expand query features to support these:

  1. Its conformance to the numbered conformance requirements or lack thereof
  2. Its rule-base
Vasileios-Mavroeidis commented 4 years ago

sounds reasonable.

The required or not-required arguments for an action/target pair are important to know in this case.

jmbrule commented 4 years ago

I agree completely with Alex and Vasileios. We REALLY need to get the query features schema command back in the language spec. May I suggest we close this issue and essentially repeat this very discussion to the lang spec?

davaya commented 4 years ago

This is not the same issue as "query schema". There is no response that will return the state of an slpf, or what rules are in place, so new responses will need to be defined to return them. For optional fields that are already defined, "query features schema" would tell you whether they are supported in this particular implementation. But if they aren't defined they aren't supported :-). And if they are not optional, they must be supported by any conforming implementation.

Dave

On Thu, Feb 13, 2020 at 2:27 PM Joe Brule notifications@github.com wrote:

I agree completely with Alex and Vasileios. We REALLY need to get the query features schema command back in the language spec. May I suggest we close this issue and essentially repeat this very discussion to the lang spec?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/oasis-tcs/openc2-apsc-stateless-packet-filter/issues/117?email_source=notifications&email_token=AESEALALRX7NDVX2CF37BDDRCWNLVA5CNFSM4KTEAZ4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELWJU2A#issuecomment-585931368, or unsubscribe https://github.com/notifications/unsubscribe-auth/AESEALGDWLR62LBGSZX4KGTRCWNLVANCNFSM4KTEAZ4A .

jmbrule commented 4 years ago

Upon rereading (more carefully this time) I think we conflated two issues. The need to know "The required or not-required arguments for an action/target pair are important to know" can be addressed with the query features schema command, the need to know the current state of the rule set is not...

Vasileios-Mavroeidis commented 4 years ago

Ok yes, i understand. This could keep an orchestrator updated for the state of the rule-set of an actuator. Regarding the conformance, i dont think that really matters, when we get the pairs or schema, as long as we can see for example, temporal arguments, that would automatically mean that the actuator conforms.

davaya commented 4 years ago

The "conformance" comment was intended to point out what query-schema will and won't tell you. It will not, for example, replace query pairs because the current LS schema isn't designed to enforce pairs using syntax. It could be designed that way by including several new type definitions, but currently it isn't.

In any schema, some things are required and others are optional. For the optional things, actuator A may support "thing-1" and Actuator B may not support it. Query schema allows distinguishing between the two actuators, because "thing-1" will not appear at all in Actuator B's schema.

Vasileios-Mavroeidis commented 4 years ago

Agree +1