Agree with you Terry.
But the ability to model and represent data changes (CRUD) is important. We just need to agree on how that is done in the STIX model.
My response to this thread was suggesting we model deletion of relationships with a timestamp of when the reln is no longer active.
This would be consistent with how other CRUD operations are modelled in STIX and also supports your statement that its not a single database or server that has to update its version of
Terry MacDonald <email@example.com>
Date: Wednesday, May 3, 2017 at 12:51 PM
To: Allan Thomson <firstname.lastname@example.org>
Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, Bret Jordan <Bret_Jordan@symantec.com>, "Reller, Nathan S." <Nathan.Reller@jhuapl.edu>, "Struse, Richard" <Richard.Struse@hq.dhs.gov>, John-Mark Gurney <email@example.com>, "firstname.lastname@example.org"
Subject: Re: [cti] Re: [EXT] [cti] Embedded Relationships
I think it's important to note here that a TAXII community doesn't necessarily agree on a common set of 'agreed truth'. It's always up to each consumer to determine what they want to believe. Threat intelligence sharing is just someone
sharing their assertion to other members in the community.
A TAXII community is not a database. It's a sharing group. Once a producer has shared data with the community they have effectively lost control of the data ... And instead trust that other members of the year Intel sharing community will
treat the data in the way they requested through the data marking that was applied to the assertions they made. A delete function doesn't make sense to me in this construct - at least at a 'community' level. Once data has been shared, it's been shared. The
most we can communicate to recipients after that is that 'the data is worthless, so don't use it'.
At the moment TAXII operates through a single server for a community, but this is not the long term goal. Our long term goal is to spread the TAXII community over multiple TAXII servers in multiple different locations (newsgroup style),
such that a single TAXII server can be part of multiple communities.
On 4/05/2017 05:03, "Allan Thomson" <email@example.com> wrote:
It would be better to just have timestamp when the relationship
no longer is ‘active’.
That fits better with other immutable data processing for TI in general.
DELETE assumes the data is being stored in a repository. It would have to be optional to implement...
Sent from my mobile device, please excuse any typos.
Bret Jordan --- Re: [cti] Re: [EXT] [cti] Embedded Relationships ---
Great questions. In regards to the DELETE function, I think we can easily add this in TAXII 2.1. Please help us identify other gaps.
One of the gaps you mentioned is how to get the rest of the objects. We have talked about adding an ability in TAXII to automatically deterrence embedded relationships. Maybe
this would help.
As for the identity aspect, I think your internal tools inside your trust group can do what they need. You can always use custom properties to track an object as it moves through
your work flow and object lifecycle. One thing we need to add to STIX and TAXII is the ability to send suggested updates. I think this would also help you.
Please keep sending questions and ideas and help us fill in these gaps for the next release.
Sent from my Commodore 64
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
It assumed that whom ever you got the relationship will know how to get the other objects referenced by the relationship...
Why is that assumed? Shouldn’t the STIX/TAXII specs say how to do that? If it’s not consistent on how to do that then that is bad for consumers, and it seems like the point of the specs is to make it consistent for how to share information.
there isn't a delete operation in STIX
Why is there not a delete operation? How can the objects live in perpetuity?
In this case, they may choose to use a single "identity" for this group to produce their objects, and anyone in the group is allowed to use it.
Now there are no current technical measures to prevent you from doing this.
There are a couple of challenges with this approach. I’m curious how you plan to solve them.
1. Identity management
I have a lot of potential identities. Every combination of collaboration must be supported. That is exponential growth in the number of groups. While the number of groups is concerning the real heartburn will be when a user needs to select one. They will need
to choose from a large set of groups.
For instance, consider the Navy UARC community. There is APL, PSU, UT, UW, and UH. As time goes I expect every possible combination of collaboration to develop. That means my “identity” for creating an object could be [(APL), (APL, PSU), (APL, UT), (APL, UW),
(APL, UH), (APL, PSU, UT), (APL, PSU, UW), (APL, PSU, UH), … That’s kind of annoying for users to scroll through the long list to select.
2. Group selection
How do you know which group should be used? In the use case I gave the DHS analyst creating the first event has no idea who will contribute to the group. How would he know that only APL and FBI would contribute? He cannot know that and perhaps tomorrow another
organization will want to contribute. Perhaps only DHS will contribute to the object.
I see a couple of options. He can either use an “everybody” group that allows anyone to contribute, or he can create a new group for each new SDO. The “everybody” group allows for anyone to contribute to the object. That is good, but all edits to the object
will be attributed to “everyone” in which case you don’t know who made the object. That’s not good.
The other option is to create a new group for each new object. This would allow the group to add and expand members as more requests to contribute are received. The downside is that I now have a new group for each object, and the Identity must be further parsed
so I can determine who is in the group. Group names become meaningless. The other downside is that I still don’t know who made what revision of the object. All I know is that someone in the group produced the last version.
Currently, they would need to contact the DHS to update their object
This is the alternate to the single identity approach. The biggest downside to this approach is object attribution. If I create an object then I would be hesitant to update it based upon a request from someone else unless I have a very close relationship with
them. Going back to my example with DHS, FBI, and APL let’s assume FBI sends a request to DHS to change the object. Would DHS likely just accept the request? Probably not because anything in that object is attributed to them, and what are the chances that
the DHS person that created the object knows and trusts the FBI agent making the request? I would be nervous of bad information being attributed to me. And APL being a consumer may want to know who added which parts to the object.