cti-stix message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: [cti-stix] Re: [EXT] Re: Bundle add Spec_version
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: <cti-stix@lists.oasis-open.org>, Bret Jordan <bret_jordan@symantec.com>
- Date: Fri, 21 Sep 2018 12:32:30 -0300
I would like to expand on this idea a little
bit, because I think there is a wider opportunity here to improve something
we did in CSD01.
- This property on a bundle, previously
indicated the version of the bundle as well as all of the objects inside
it.
- The reason we removed this property
from the bundle, was because we added spec_version to each SDO/SRO, and
made it a mandatory property
- However, this makes it ambiguous as
to what the version is, of the bundle object itself - hence this discussion
What if we revisit this change we made
- and do this instead
- We keep spec_version on the bundle
as the previous definition - it defines the version of the bundle itself,
as well as objects within
- We make spec_version an *optional*
field on every SDO/SRO. If it is *not* present, then the SDO/SRO inherits
the value from it's bundle.
-
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
__________________
Your faith in spec reading is admirable :-)
Allan Thomson.
CTO, lookingglass cyber solutions.
Www.lookingglasscyber.com.
This electronic message transmission contains information from LookingGlass
Cyber Solutions, Inc. which may be attorney-client privileged, proprietary
and/or confidential. The information in this message is intended only for
use by the individual(s) to whom it is addressed. If you believe that you
have received this message in error, please contact the sender, delete
this message, and be aware that any review, use, disclosure, copying or
distribution of the contents contained within is strictly prohibited.
From: Bret Jordan <Bret_Jordan@symantec.com>
Sent: Wednesday, September 19, 2018
9:12:52 AM
To: Allan Thomson
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [EXT] Re: Bundle add
Spec_version
We could do that or just be super clear in the description,
something with a MUST statement so that it is flagged when people parse
and extract things from the document.
Bret
Sent from my Commodore 64
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0
74F8 ACAE 7415 0050
On Sep 18, 2018, at 6:27 PM, Allan Thomson <athomson@lookingglasscyber.com>
wrote:
Suggest to make it clear that is not the contained object
versions then we should call the property something else.
Ideas:
- bundle_spec_version
- bundle_spec
- bundle_wrapper_spec
Allan Thomson,
CTO, Lookingglass
Cyber Solutions
This electronic message transmission contains information
from LookingGlass Cyber Solutions, Inc. which may be attorney-client
privileged, proprietary and/or confidential. The information in this message
is intended only for use by the individual(s) to whom it is addressed.
If you believe that you have received this message in error, please contact
the sender, delete this message, and be aware that any review, use, disclosure,
copying or distribution of the contents contained within is strictly prohibited.
From: cti-stix@lists.oasis-open.org<cti-stix@lists.oasis-open.org>
on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Sent: Tuesday, September 18, 2018
11:41 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Bundle add Spec_version
All,
I would like to start a thread here to discuss adding
back the spec_version property to the bundle in STIX. A little bit
of history:
1) We had spec_version on the Bundle in 2.0. However,
we had problems with it, as it was unclear if it meant the spec version
of the objects in the bundle or the bundle wrapper itself.
2) Based on this, in 2.1 we added spec_version to every
object and removed it from the bundle.
I am thinking that we may need to add it back to the bundle
with a clear definition that it is the spec version of the bundle wrapper
itself. Thoughts?
Bret
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]