search

oasis-tcs / openc2-oc2ls

OASIS OpenC2 TC: GitHub repository used to propose and track changes to the OpenC2 Language Specification as new working draft level revisions are created and the associated CSDs mature
https://github.com/oasis-tcs/openc2-oc2ls
Other
15 stars 19 forks source link

add more actuators #360

Closed sparrell closed 4 years ago

sparrell commented 4 years ago

Add actuators that we are, or should be, developing

davaya commented 4 years ago

The Actuator Profile registry is the authoritative list of Actuator Profiles, and a sentence to that effect should accompany this table in the LS.

I'll update the registry to include all of the profiles in this PR. Moving forward, the registry and the language spec must not conflict. But if the AP-SC later adds standard or custom profiles to the registry, the L-SC MAY choose to rev the LS to include them, or it may choose not to. If it doesn't, those profiles still exist and can still be implemented interoperably by OpenC2 developers.

alevere commented 4 years ago

I find this reasonable for the time being, given how many APs we have.

Vasileios-Mavroeidis commented 4 years ago

Why would we want to have 2 different places to maintain the up to date AP list? Since we have an AP registry and it is the authoritative list, it is what it should be mentioned in the LS with a link for redirection. The APs will keep increasing and this table wont be updated when OpenC2 will become a standard. The suite of specifications that will be part of the future standard suite should be robust to changes.

sparrell commented 4 years ago

I disagree strongly with "The Actuator Profile registry is the authoritative list of Actuator Profiles, and a sentence to that effect should accompany this table in the LS". I have agreed in the past and would agree to the process which I thought we had agreed to for registering Custom Actuator Profiles. I see a world of difference between vendor extensions and security functions. I think it is an error to confuse the two. Even in our wildest success, there will not be that many AP's - ie standard interfaces to security functions. New ones will not come up that often. There may be hundreds of CAPs or there may be only a few - so far there are only a few and I personally predict it will stay that way, particularly if we do our jobs well (ie have vendor agnostic interfaces to functions). I believe strongly we will succeed if have vendor agnostic interfaces. CAPs are not vendor-agnostic interfaces. They will have vendor tweaks and probably be associated by name with a vendor. And even if we came up with new security functions and standardized them monthly with functions we had never heard of (an very unlikely scenario)- I still strongly believe the language should have in it the nouns for those functions. These functions are the core of what we are tying to do.

davaya commented 4 years ago

I'm not going to argue about what the L-SC should do with the list.

The AP-SC will maintain an authoritative registry of actuator profiles that it produces and any ones that custom profile developers choose to register; that is our job.

The L-SC is authoritative for the OpenC2 language, i.e., how the language makes use of the APs, including property IDs/Names it uses to refer to those APs. That is the same situation as if the LS were going to refer to content defined by other OASIS TCs, or by other SDOs - they create what they create, and the LS can choose to reference them or not.

Distributed development is the entire point of namespacing - a geotagging organization can create data models relevant to their domain without knowing that OpenC2 even exists, and OpenC2 can make use of geotagging objects published by that organization if it has a need for them. And the LS publishes objects that could be reused by the CTI TC if they chose; they wouldn't need our permission or knowledge to do so.

sparrell commented 4 years ago

Can you show me where the TC has approved the process you suggest? I believe I've been mislead but the details are in the wording and maybe it was my fault for not understanding what was proposed. Relating two SC's in the TC as if it was OASIS interacting wth IETF is just fundamentally wrong. It's not even like two TC's working independently. We are the same TC.

davaya commented 4 years ago

Technical possibilities enabled by a namespace registry have nothing to do with work processes.

It is "technically possible" for STIX to reference OpenC2 definitions under an OpenC2-registered namespace. I have no reason to think they have any interest in doing so.

I certainly see a possibility of OpenC2 referencing information objects defined by other organizations such as SPDX, although no work, technical or procedural, has yet been done to allow that to happen.