[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] Update from STIX Package renaming Mini-Group
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]