OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[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]