cti message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cti] STIX Enhancements
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: Bret Jordan <Bret_Jordan@symantec.com>
- Date: Tue, 18 Sep 2018 11:05:57 -0300
I will also point out the current working
document
https://docs.google.com/document/d/1D3Rls74xHqskZ3THiSjilOf5XfFgVed-mZM-3kmG6SU/edit
-
Jason Keirstead
Lead Architect - IBM.Security
www.ibm.com/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>
All,
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: [
"enhancement_foo",
"enhancement_bar_123"
],
...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.
Bret
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]