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: Re: [cti] STIX Enhancements

I will also point out the current working document


Jason Keirstead
Lead Architect - IBM.Security

"Things may come to those who wait, but only the things left by those who hustle." - Unknown

From:        Bret Jordan <Bret_Jordan@symantec.com>
To:        "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date:        09/18/2018 11:04 AM
Subject:        [cti] STIX Enhancements
Sent by:        <cti@lists.oasis-open.org>


I would like to kick of a thread here to discuss some of the STIX Enhancement pieces that I feel we need to address.  Please note, the STIX Enhancement work is not the same as the STIX Work Product Process document that I sent out a few weeks earlier.  These are different things.

In order for STIX Enhancements (or what some might call a protocol or schema extension) to work it is my belief that a STIX Object that contains an enhancement needs a way of saying that it contains one or more enhancements.  Further, I also believe there needs to be some very basic elements added to TAXII to be able to identify that a client and server both support certain enhancements. On the STIX schema side I view this as something like:

   type: "indicator",
   seps: [
   ...rest of indicator...

There has been some discussion about if SEPs should be versioned or if each SEP version should be its own thing.  I have not seen enough pros and cons to personally decide what I would prefer.  Also, the list of SEPs may need to be a list of objects instead of a list of strings.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]