Re: [cti] Re: [EXT] [cti] Embedded Relationships

[John-Mark Gurney <jmg@newcontext.com>]

Reller, Nathan S. wrote this message on Mon, May 01, 2017 at 15:53 +0000:
> I have read through the previous emails and have a better understanding of the decision making for creating Relationship objects. It allows the object creators to maintain control of the object because only they can update it while also allowing others to add more information about an SDO.
> 
> I’m still a little confused about some of the CRUD (create, read, update, and delete) operations. Create seems easy enough for now with a TAXII request to upload an object. We talked a little about reading an object; although I don’t know how to retrieve all information about an object, especially when I first learn of an object via a Relationship. I don’t know where to retrieve that object based upon its ID. I’m not sure of when I can delete an object. If others have Relationships that point to my object do I need to coordinate with them before I delete it? Otherwise they will have orphaned pointers, and how do I know if that object has been deleted or whether it lives in a repository that I cannot access. If I am the creator of a Relationship is it my duty to follow the objects of that Relationship and then delete the Relationship when one of the objects is deleted?

So, how people consume data is entirely up to them.  It assumed that
whom ever you got the relationship will know how to get the other
objects referenced by the relationship...

Also, there isn't a delete operation in STIX, there is a revoke, which
just says that I don't believe the information to be valid any longer..
There is no ability for someone else to delete an object for your local
store..  The delete operation is entirely up to the local consumer of
the object..  There is no requirement that when a new revision of the
object is published (which may be revoked) that a consumer accept and
use it...

We have not discussed the requirements of relationships and when an
object that is pointed to them is revoked.  I expect that if an object
is revoked that is pointed to by a relationship, that relationship will
be shown as broken, and no longer be used.  It may be automatically
deleted from the local database as no longer useful...

I don't see a need for a producer to do any work when they revoke an
object, though I do see use for them to revoke the relationships that
they have produced...

> The CRUD operation that I have the most questions about is updating an object. I don’t understand how to update an object. Specifically, how do I update an object for which I am not the creator because the design only allows the object creator to update an object?

You cannot.  The only way is to produce a new object, this is covered in
Part 1, Section 3.4...

Now there is nothing the prevents you from maintaining your changes
local, but the STIX standard requires that you not publish your changes
using the same ID as the original object...

> I’m considering the use case of a community that collaborates together. To make this more realistic let’s say the community is DHS, FBI, and government contractors like APL, MITRE, etc. I want to walk through a few use cases, so I know how to edit an object.

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.

> The first use case is how to edit the name of a Threat Actor. Let’s assume that DHS has created a Threat Actor SDO and his name is “Dirty Bear.” The initial Threat Actor does not have any data for any of the optional properties because this is a new Threat Actor and very little is known about him. APL is investigating some incidents, and it discovers that Dirty Bear is the Threat Actor behind the attacks. They also learn that Dirty Bear is spelled “Dirty B3ar.” How does APL update this information? Should they create a new Threat Actor that is “derived-from” DHS’s Threat Actor? Should they send DHS an email?

There are discussions/desire to add a STIX message to be able to
suggest changes to an object, which the producer will then be able
to accept/reject and publish a new version.

Yes, in some ways we are reinventing a distributed change control
system.

Currently, they would need to contact the DHS to update their object,
unless the above scheme where they all share an identity is used.  Even
in the shared identity scheme, you have to make sure that DHS knows
about the change, or they could end up producing a newer version that
doesn't have the change.

> During APL’s investigation the FBI was alerted, and they also began investigating “Dirty B3ar.” The FBI has discovered more information about the attacker. They learned that he has an alias of “Brazen Gazelle.” Do they update the object or create a new derived from object? They also put this Threat Actor’s sophistication as “intermediate.”
> 
>  
> 
> For this community should we expect there to be three Threat Actor SDOs that reference the same person (one each from DHS, APL, and FBI)? From APL’s point of view, when they start creating Relationships should they duplicate those Relationships for each instance of the SDO, or should they only add Relationships to their Threat Actor SDO?
> 
>  
> 
> I have similar questions about objects within an organization. Let’s dive deeper into the FBI scenario. Let’s pretend there is a team of 6 agents investigating Dirty B3ar. Let’s assume for the sake of argument the solution is to create a new Threat Actor SDO and use the derived-from property. Agent Tim Smith is responsible for creating the new Threat Actor. What Identity should create the object? Should it be an FBI-wide Identity or one tied to Agent Tim Smith? If it’s an FBI-wide Identity then there is no information about who added what to the object, and that is one of the properties we wanted. If the Identity is Agent Tim Smith then how can Agent Michael Sullivan update the object when he discovers the sophistication level of Dirty B3ar? Should he create a new SDO and derive-from Agent Tim Smith’s object? Should he ask Agent Tim Smith to update the object and take responsibility for the information? Or should they use a common FBI Identity?

There have been discussions on this recently.  I'm not sure what the
results have been of them though.

-- 
John-Mark