Add "rule_number" target to language spec

[sparrell]

The SPLF Actuator Profile mostly uses terms used in the language spec but does have some extensions. One extension is the "rule_number" target. I propose the "rule_number" target be added to the language specification.

My first argument fo including is that I (@sparrell) feel strongly that all terms in and OC2 specification should eventually end up in the language specification. I don't think AP specs should be help up until the LS is updated, but I see no reason not to eventually include any term in any OC2 specification (note specification, not custom extensions. I am distinguishing between spec and custom).

Should my first argument fail, my second argument is that "rule_number" will be common to many profiles. I suspect the stateful packet filter profile which will need it and it's likely in my opinion stateful firewalls will result in more than one additional profile. I suspect that web application firewall profiles will need it. I suspect we will have at least one, and probably several, IDS/IPS profiles that will need it. Etc ad nauseam. I do not think one should be rule_number, another rule_id, another policy_id, etc. Therefore it should be defined once in the language spec.

My third argument is trivial, but not insignificant. It would obviate the need for namespacing components in the command. I am perfectly ok with custom actuator profiles having namespaces and one CAP command having multiple namespaces within a command. I could even live with one OASIS TC refenencing namespaces in other TC's. But it offends my sensibilities that within the OC2 TC we are introducing a separate namespace in the middle of the most common commands. I still maintain the firewall deny/allow commands are the most common security commands sent, especially in "machine speed response to attack". Those commands having to invoke another namespace midcommand, to reference our own terms, seems very superfluous to me.

Should there be acceptance of this proposal, then specific text changes would need to be proposed and accepted. To begin with, this issue is to get agreement in principle to the concept of adding 'rule_number' as a target in the next issue of the language specification

[jmbrule]

This issue has been proposed, deliberated at great length and voted on. The points made are not new. It seems logical that defer these discussions until at least one of the following criteria are met: ONE: New points are made (that have not already been made, deliberated upon for several iterations) TWO: Experience we gain as the specification is promulgated indicates that the previous conclusions made were not correct THREE: A wave of new members join the TC such that the original vote is overwhelmed.
Rehashing these old debates has limited utility until at least one of these are met.

[TobyConsidine]

Duncan:

Can you please expand on the use of the construct “Rule Number”?

Is it an Ordinator “Apply this rule first, and then apply that rule to the resulting state”

Or is it a sub-message, to identify components of a command (I did 1, but I could not do 2)

Or is it something else

thanks

From: Duncan Sparrell notifications@github.com Sent: Monday, January 20, 2020 10:26 PM To: oasis-tcs/openc2-oc2ls openc2-oc2ls@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [oasis-tcs/openc2-oc2ls] Add "rule_number" target to language spec (#351)

The SPLF Actuator Profile mostly uses terms used in the language spec but does have some extensions. One extension is the "rule_number" target. I propose the "rule_number" target be added to the language specification.

My first argument fo including is that I (@sparrell https://github.com/sparrell ) feel strongly that all terms in and OC2 specification should eventually end up in the language specification. I don't think AP specs should be help up until the LS is updated, but I see no reason not to eventually include any term in any OC2 specification (note specification, not custom extensions. I am distinguishing between spec and custom).

Should my first argument fail, my second argument is that "rule_number" will be common to many profiles. I suspect the stateful packet filter profile which will need it and it's likely in my opinion stateful firewalls will result in more than one additional profile. I suspect that web application firewall profiles will need it. I suspect we will have at least one, and probably several, IDS/IPS profiles that will need it. Etc ad nauseam. I do not think one should be rule_number, another rule_id, another policy_id, etc. Therefore it should be defined once in the language spec.

Should there be acceptance of this proposal, then specific text changes would need to be proposed and accepted. To begin with, this issue is to get agreement in principle to the concept of adding 'rule_number' as a target in the next issue of the language specification

— 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-oc2ls/issues/351?email_source=notifications&email_token=ADCKAOBRT735IH2LQM3SMBDQ6ZTLHA5CNFSM4KJM2CR2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IHQBYXA , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADCKAOFDYO7JERW6L4OO4FDQ6ZTLHANCNFSM4KJM2CRQ . https://github.com/notifications/beacon/ADCKAOGTHP32BFTIWOEIQGTQ6ZTLHA5CNFSM4KJM2CR2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IHQBYXA.gif

[Vasileios-Mavroeidis]

@TobyConsidine it identifies the firewall rule to be deleted when used with the action "delete".

[Vasileios-Mavroeidis]

Inclusions from APs to the LS will have a great impact on our implementations in the future, especially when we will have many APs.

For that reason either we add new actions/targets at an early stage before OpenC2 is greatly adopted in the LS and with the requirement that we are very sure about those new actions/targets (this is how the LS was developed), OR we wait for long periods and we make the changes based on AP clustering and for sure only when we have multiple changes aggregated. Every transfer from the AP to LS, automatically changes multiple specs.

Then we can reference the changes (from version to version) in a separate document to support the engineers that had already implementations.

• it is of my belief too that rule number will be greatly used by multiple APs.

• maybe we need to come up with a specific/formalized process for introducing and transferring actions/targets/arguments in the LS.

[jmbrule]

There is a desire to move everything 'up' to the language specification regardless of whether or not it is meaningful outside of a subset of actions, actuators and/or cyber eco-systems.

I assume the motivation for this totalizing instinct is to avoid having numerous terms being defined for the same or very similar argument resulting in undue redundancy and complexity.

The likelihood of redundant terms existing in the space of custom actuator profiles is conceded. Having conceded the point, moving everything 'up' to the language specification does not accomplish anything that cannot be done by generating OASIS specifications for the actuator profiles. A mechanism for producing actuator profiles is likely to start with a custom actuator profiles and draft an OASIS specification. The members of the Actuator Profile Subcommittee are going to be familiar with the other profiles, therefore in the process of the creation and deliberation of the OASIS actuator profile, there will be ample opportunity to cross check and de-duplicate arguments. If it is deemed necessary, the AP SC could in fact create a list of arguments (using the reserved port documentation as a precedence).

Maintaining the language specification in its current scope (define the actions, targets, syntax, semantics at the effects based level) keeps the specification at a level of abstraction that is flexible and applicable to a range of scenarios and technologies. In addtion ot keeping the language specification concise, it also helps us avoid the need to rapidly revise the specification to keep up with the pace of technology releases.

A set of actuator profiles that puts the language in the context of a particular function allows us to have a suite of specifications that is concise at the abstract level and greater precision at a particular actuator level. Should a technology or function become less common or obsolete, then the profile is simply no longer supported as opposed to having extraneous information in the language specification and/or having to deprecate the language.

[jmbrule]

Issue 94, 351 and 352 are essentially the same issue. One camp would like to move all specifiers, arguments etc 'up' to the language spec and the other camp would like to keep the specifiers, arguments etc that are unique to a particular set of actuators in the profiles. May we close 94 and 351 and put all the deliberations in 352? Keeps us from having to repeat the deliberations in multiple threads

[sparrell]

To the comment "This issue has been proposed, deliberated at great length and voted on." - I disagree vehemently. I made a ballot comment stating my views. The deliberation was to kick the can down the road which I agreed to because of the compelling argument to not hold up the specification and I was assured we would revisit. I was under the (apparently faulty) assumption that no one objected to the concept but that it was race condition between SLPF and LS that was the crux of the argument. Wrt "voted on" - I disagree this topic was ever voted on. We never even discussed at TC level and we only voted at TC on specs. To the comment "moving everything 'up' to the language specification" - #351 is an issue for 1 term - not all. Why is rule number different than any of the other defined terms? If this isn't included, shouldn't all the others be removed?

[davaya]

Necro alert :-):

The resolution may have been to kick the can down the road, but now that it's down the road I strongly believe that:

• The LS is a framework that can be extended (with individual functional areas documented in actuator profiles)
• The LS defines a common set of data types that apply to multiple functional areas
• The LS should not define data types that apply to only a single functional area

Longer-term, "OpenC2" (the work products comprising the OpenC2 standard) MUST be extensible without glomming all of its functions together into the Language Specification. For example, when considering OpenC2 for OASIS Emergency Management / EU STRATEGY, it's likely that geographic addresses will be needed. Even if multiple actuator profiles need geo addresses, it makes more sense to define and reference a geo address profile than to push all geo-related types into the language spec.

[dlemire60]

discussed at triage; deferred to the future until there are multiple APs with examples of rule numbers or similar concepts ("entry_id").