Re: [cti] STIX and TAXII question

Bret – Inline.

Allan Thomson,

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@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Friday, December 8, 2017 at 10:15 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] STIX and TAXII question

All,

A few of us have been discussing some critical points about TAXII on Slack and how the date added should be used inside of a collection. Since this discussion has branched beyond just TAXII and in to STIX, I felt like bringing it up on the list, would be a good idea.

Level setting on scale:

From a scale standpoint, think of your TAXII server holding 100 billion objects and it having 5,000 different collections.

Problem the way I see it:

A TAXII server will have a container of all STIX objects that it knows about and there will be a separate container that keeps track of which objects are in which collection. It goes without saying that an object can be in zero, one, many, or all collections. Further, if you update a STIX object in one collection (fix a type'o) you probably want that update to show up in all of the collections that the STIX object is found in. This can be done automatically by just tracking the root STIX ID in a collection. This means that any new versions of a STIX object will automatically be found in their respective collection. The other option requires a ton of book keeping and maintenance. You would need to track which version of a STIX object is in which collection and when an update was made, you would need to touch every single collection that the new versions should be added to. Further, an operator would need to know if their update should be applied to all collections that the object is currently found in.

A use case was brought up that a person may want to version an object (ver 1) to remove say TLP:RED content and make a new version (ver 2) be TLP:GREEN. Then you would have the STIX ID foo ver 1 in collection "private" and STIX ID foo ver 2 in collection "public". I am wondering what others think of this? Is this a valid use of versioning? Or should the object be forked with a related-to relationship?

AT: Versioning is not intended to be a filter/view of a database. That is a misuse of the capability and would be wrong to do so.

I suggest that there 2 objects that are created with a relationships (if necessary) for TLP:RED and TLP:Green ‘versions’ of the same objects. Versioning was not intended to differentiate objects in this manner *unless* the changes from object v1 to object v2 are intended to represent a sequential change to represent the new state of the object.

What happens if STIX ID foo ver 1 gets updated? Does that mean the server then needs to track if the update should be applied to version 2 as well? If version 2 is Green and version 1 and 3 are RED, does that make things weird for a client? What happens if a client has access to both "private" and "public" and finds the same object but different versions? What is the client supposed to do?

AT: By using different objects based on a relationship avoids many of these issues.

Thanks

Bret

cti message