[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Meeting of the minds: Bret's and my proposal for STIX Enhancements (SEPs)
Hi, y'all - Apologies for the friction on the mailing list this week. Bret and I said together this evening after the OpenC2 F2F wrapped up and worked out the attached proposal. If you've looked at either my GitHub-based SEPs proposal or the Google Doc which we've been working on in a minigroup, I think you'll see that we've managed to unify our respective positions and address the concerns which others in the CTI TC have expressed. -- Cheers, Trey ++--------------------------------------------------------------------------++ Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 088F 823F 018A 831A 270A 6C4F C338 ++--------------------------------------------------------------------------++ -- "It is always something." --RFC 1925
Attachment:
cti_enhancement_process.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document
CTI TC STIX Enhancement Process Proposal ======================================== The initial version of the STIX Enhancement Process (hereafter referred to as SEP) allows the following types of enhancements to be defined: * New STIX Domain Objects (SDOs) * New STIX Relationship Objects (SROs) * New STIX Cyber Observables (SCOs) * New STIX Object Extensions * These are named groups of properties (as currently used in STIX Cyber Observables as Extensions). * STIX Object Extensions MAY be used on SDOs, SROs, and/or SCOs. As they are currently only codified in the specifications in connection with SCOs, when used in context with SDOs and/or SROs they SHOULD be interpreted as custom properties. The following are out of scope for the initial version of SEP: * Redefining an existing property on an object to add clarity or enhanced meaning. * For example, explaining double or triple tagging of data in a "tags" property. * Redefining the semantics of existing SDOs, SROs, and/or SCOs (or properties thereof) which are already defined in CSDs and/or CSs. * Redefining the semantics of STIX Patterning (including, but not limited to adding new elements, operators, or language elements). SEP Categories ============== SEPs which the CTI TC itself wants to create -------------------------------------------- * Must be useable by the CTI TC itself. * For example, this might be used for less well-understood and/or controversial concepts. * (What we're talking about here is basically minigroups.) * CTI TC SEPs MUST be listed in the Official Registry. * CTI TC SEPs MUST be stored in the Official Repository. * CTI TC SEPs MAY be added to a future spec version. SEPs which CTI TC members themselves want to create --------------------------------------------------- * These SEPs SHOULD be listed in the Official Registry. * These SEPs MAY be stored in the Official Repository. * If SEPs are stored in the Official Repository, they become OASIS CTI TC IPR. * These SEPs MAY be added to a future spec version if they are officially submitted to the TC by being contributed to the official repository AND accepted for inclusion according to CTI TC processes (defined elsewhere, in the process document previously balloted. * SEP creators MAY request the CTI TC to evaluate their SEP for _unmodified_ inclusion prior to submission to the CTI TC. * This is intended to address the case where a SEP creator is *only* willing to contribute the IPR to OASIS given a guarantee that it will be included in the spec unmodified. SEPs which third-parties (non-CTI TC) want to create ---------------------------------------------------- * These SEPs MAY be listed in the Official Registry. * These SEPs MAY be stored in the Official Repository or linked to a repository under the control of the third-party. * These SEPs MAY be added to a future spec version if they have been submitted to the CTI TC via the public comment email list or by submitting them to the Official Repository. General Approach ---------------- * Official Registry: Initially we will use GitHub (https://github.com/oasis-open/cti-sep-registry/) but may look at other options (like IANA) in future. * Official Repository: Initially we will use GitHub (https://github.com/oasis-open/cti-sep-repository/) to store all SEPs that have been submitted to the CTI TC. * We may investigate something else in the future. * SEPs submitted to the Official Repository belong to the CTI TC and fall under OASIS IPR rules. * Prior to submitting a SEP to the Official Repository, the submitter MUST have executed the OASIS CLA. Open Questions -------------- * How do we advertise in a STIX object that a given SEP is in use? * Why do we need to? * How do we advertise in TAXII that a given SEP is in use? * Why do we need to? * How do we filter in TAXII for SEPs? * Why do we need to?
Attachment:
signature.asc
Description: PGP signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]