Seems like folks are not able to make it this week.
I propose we discuss this topic at the working meeting next Tuesday.
allan
From: "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org > on behalf of Jason Keirstead <
Jason.Keirstead@ca.ibm.com >
Date: Wednesday, May 4, 2016 at 5:26 AM
To: "Wunder, John" <
jwunder@mitre.org >
Cc: "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
Subject: Re: [cti] Update from STIX Package renaming Mini-Group
I can't make this time either, will be on PTO. The key thing to me is - there should never be a need to track bundles. If software was tracking them, then it would be making fundamentally incorrect assumptions on what a bundle is. The objects inside the
bundle should be tracked, not the bundle itself.
The only purpose of the bundle (as defined currently) is to serve as a top level wrapper for STIX TLOs stored in a file (because we need something to put TLOs in to make a list of bare TLOs a valid and parseable JSON structure). It serves no other purpose..
it's not communicating any relationships or context as to the information inside it.
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown
"Wunder,
John A." ---05/03/2016 11:11:25 PM---I think a call would make sense. It seems like we have different conceptions of what “bundles” shoul
From: "Wunder, John A." <
jwunder@mitre.org >
To: "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
Date: 05/03/2016 11:11 PM
Subject: Re: [cti] Update from STIX Package renaming Mini-Group
Sent by: <
cti@lists.oasis-open.org >
I think a call would make sense. It seems like we have different conceptions of what “bundles” should be used for. I won’t be able to make 8am PST but don’t wait for me.
I see the point that John-Mark and Jason are making about bundle just being a transport concept, but otoh sometimes the most “correct” solution isn’t the right one just because of the realities of how technology works, and on the balance it seems useful to
me to have IDs on packages so you can track them if you need to. But to be honest I would be happy with either answer.
On 5/3/16, 8:08 PM, "
cti@lists.oasis-open.org on behalf of Allan Thomson" <
cti@lists.oasis-open.org on behalf of
athomson@lookingglasscyber.com > wrote:
>
>I think we should have a higher bandwidth conversation on this topic (conference call) to discuss our differences and come to closure.
>
>
>Listening to the ‘no id’ camp I’m wondering what bundles are intended to support.
>
>I personally think there is no problem having an id in a bundle so would like to understand what is so objectionable to having one. If we don’t have one then vendors can create their own TLO that represents an id for a bundle and do it that way but would like
to avoid if we can.
>
>I’m happy to provide the webex if interested parties share their preferences on time/date.
>
>How about Thu 8am PST?
>
>allan
>
>On 5/3/16, 1:52 PM, "John-Mark Gurney" <
jmg@newcontext.com > wrote:
>
>>Jason Keirstead wrote this message on Tue, May 03, 2016 at 14:07 -0300:
>>> That seems like a TAXII level problem, if anything.
>>>
>>> I don't see how having IDs would even solve that problem, without changes
>>> to TAXII to allow someone to say something like "bundle recieved"
>>
>>I agree... I don't think Bundles should have IDs.
>>
>>We decided that STIX was going to be a transport mechanism, not a
>>document format. If you don't have the TLO's you need, then you need
>>to request the missing TLO's from your higher level transport, ala
>>Bret's example w/ TAXII or via your transport mechanism.
>>
>>As soon as you add an ID to a STIX Bundle, you are now adding meaning
>>to the grouping and we loose the Bundle is just a set of (possibly)
>>unrelated STIX objects.
>>
>>> From: "Jordan, Bret" <
bret.jordan@bluecoat.com >
>>> To: Jason Keirstead/CanEast/IBM@IBMCA
>>> Cc: Allan Thomson <
athomson@lookingglasscyber.com >, Mark Davidson
>>> <
mdavidson@soltra.com >, "
cti@lists.oasis-open.org "
>>> <
cti@lists.oasis-open.org >
>>> Date: 05/03/2016 02:03 PM
>>> Subject: Re: [cti] Update from STIX Package renaming Mini-Group
>>> Sent by: <
cti@lists.oasis-open.org >
>>>
>>>
>>>
>>> I agree with Jason... I know the request on the call was about how do you
>>> know if you did not get a bundle. That seems to be an implementation /
>>> transport level issue, not a language level issue. Allan / Terry? Thoughts?
>>> Is there another way of doing what you asked without having an ID field?
>>>
>>>
>>> Thanks,
>>>
>>> Bret
>>>
>>>
>>>
>>> Bret Jordan CISSP
>>> Director of Security Architecture and Standards Office of the CTO
>>> Blue Coat Systems
>>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
>>> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can
>>> not be unscrambled is an egg."
>>>
>>> On May 3, 2016, at 10:08, Jason Keirstead <
Jason.Keirstead@ca.ibm.com >>> > wrote:
>>>
>>>
>>>
>>> Open question - adding an identifier "so that it can be tracked",
>>> implies that it SHOULD be tracked.
>>>
>>> As an implementer - why do I need to track bundles, as all a bundle
>>> is is a whole bunch of content that may or may not be related?
>>>
>>> I would argue that we should not encourage the storage or tracking of
>>> the bundle structure, and therefore they should not have IDs.
>>>
>>> -
>>> Jason Keirstead
>>> STSM, Product Architect, Security Intelligence, IBM Security Systems
>>>
www.ibm.com/security www.securityintelligence.com >>>
>>> Without data, all you are is just another person with an opinion -
>>> Unknown
>>>
>>>
>>> <graycol.gif>Allan Thomson ---05/03/2016 12:23:49 PM---As discussed
>>> on the call today I would like to propose that we add an identifier
>>> attribute for the b
>>>
>>> From: Allan Thomson <
athomson@lookingglasscyber.com >
>>> To: Mark Davidson <
mdavidson@soltra.com >, "
cti@lists.oasis-open.org "
>>> <
cti@lists.oasis-open.org >
>>> Date: 05/03/2016 12:23 PM
>>> Subject: Re: [cti] Update from STIX Package renaming Mini-Group
>>> Sent by: <
cti@lists.oasis-open.org >
>>>
>>>
>>>
>>>
>>>
>>> As discussed on the call today I would like to propose that we add an
>>> identifier attribute for the bundle so that it can be tracked.
>>>
>>> {
>>> "type": "bundle",
>>> "spec_version": "stix-2.0”,
>>> “id”: “bundle--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f"
>>> "indicators": [
>>> {
>>> "type": "indicator",
>>> "id": "indicator--8e2e2d2b-17d4-4cbf-938f-98ee46b3cd3f",
>>> "created_by_ref": "source--f431f809-377b-45e0-aa1c-6a4751cae5ff",
>>> "created_time": "2016-04-29T14:09:00.123456Z",
>>> "revision": 1,
>>> "modified_time: "2016-04-29T14:09:00.123456Z",
>>> "object_marking_refs":
>>> ["marking-definition--089a6ecb-cc15-43cc-9494-767639779123"],
>>> "title": "Poison Ivy Malware",
>>> "description": "This file is part of Poison Ivy",
>>> "pattern": "file-object.hashes.md5 =
>>> '3773a88f65a5e780c8dff9cdc3a056f3'"
>>> }
>>> ],
>>> {
>>> "type": "marking-definition",
>>> "id": "marking-definition--089a6ecb-cc15-43cc-9494-767639779123",
>>> "created_time": "2016-02-19T09:11:01Z",
>>> "definition_type": "tlp",
>>> "definition": {
>>> "tlp": "GREEN"
>>> }
>>> }
>>> }
>>>
>>>
>>> From: "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org > on behalf
>>> of Mark Davidson <
mdavidson@soltra.com >
>>> Date: Friday, April 29, 2016 at 9:56 AM
>>> To: "
cti@lists.oasis-open.org " <
cti@lists.oasis-open.org >
>>> Subject: [cti] Update from STIX Package renaming Mini-Group
>>>
>>> All,
>>>
>>> Here is a quick update from the STIX Package name mini-group. The
>>> mini group is proposing:
>>> Renaming STIX-Package to STIX-Bundle
>>> STIX-bundle is simply a transport container
>>> STIX-Bundle is a grouping of STIX content that isn’t
>>> required to be related (it MIGHT be related, but being in
>>> the same bundle doesn’t mean it’s related)
>>> Removing all TLO Common Properties (with an open question
>>> about Data Markings)
>>> Removed properties: id, created_by_ref,
>>> created_time, revision, modified_time,
>>> revoked, revision_comment, confidence,
>>> object_markings_refs, granular_markings
>>> STIX-Bundle will keep the `spec_version` property
>>> All content in the bundle MUST be the same STIX version
>>> (identified by spec_version)
>>> There is an open question about whether Data Markings should be in
>>> the STIX-Bundle. Arguments for keeping it are:
>>> The group seemed to have consensus that Bundle-level
>>> markings were desired, but evidence was difficult for the
>>> mini-group to find.
>>> Certain sharing communities would appreciate the
>>> simplicity of package marking.
>>> It makes objects look smaller and is more natural for
>>> people who are new to the specs
>>> Arguments for removing it are:
>>> Data Marking at the bundle level is “two ways of doing
>>> things” - on-the-object markings and on-the-bundle
>>> markings
>>> TLO signatures will not be valid when the Bundle-level
>>> markings are used
>>>
>>> Thank you.
>>> -Mark
>>>
>>>
>>> [attachment "signature.asc" deleted by Jason Keirstead/CanEast/IBM]
>>>
>>
>>
>>
>>--
>>John-Mark