Re: [cti] Update from STIX Package renaming Mini-Group

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

If the ID is going to be used in request / response in TAXII, then shouldn't it be part of that layer (transport)? Request/response is not something done in the STIX layer.


-
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


Allan Thomson ---05/03/2016 03:36:21 PM---I think an id is useful for retrieval (request/response) and tracking. 1. For Request/Response ha

From: Allan Thomson <athomson@lookingglasscyber.com>
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, Jason Keirstead/CanEast/IBM@IBMCA
Cc: Mark Davidson <mdavidson@soltra.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 05/03/2016 03:36 PM
Subject: Re: [cti] Update from STIX Package renaming Mini-Group
Sent by: <cti@lists.oasis-open.org>

---

I think an id is useful for retrieval (request/response) and tracking.

1. For Request/Response having the ability to get a list of new ‘ids’ of bundles available from a server and then request a specific bundle based on an id seems useful. I agree this could be related to the transport protocol itself but what is the harm in embedded that id as well.
2. For tracking if I’m a broker and want to pass the bundle as is without modification then it would seem I need some ‘id’ to represent the bundle other than when I got it.

In both cases, there’s alternate solutions to solving these problems but it would seem adding an id to the bundle itself by the creator of the bundle is not difficult and helps use bundles.

What exactly would be the problem of having an id in the bundle? 

If you don’t care about the id then just ignore it.

allan

From  "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Tuesday, May 3, 2016 at 10:03 AM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Cc: Allan Thomson <athomson@lookingglasscyber.com>, Mark Davidson <mdavidson@soltra.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Update from STIX Package renaming Mini-Group

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