If Location is an SDO, does that make it possible to “move” another object by versioning the Location object? That seems like a bad idea. Especially if you effectively “move”
other, unrelated objects that also refer to the same Location. Even if we did make Location a TLO, we would have to mandate that people update the “_ref” fields to move an SDO, not the Location itself.
(I haven’t made up my mind on whether I like the Location SDO in general, just pointing out one consideration).
Greg
From:
<
cti@lists.oasis-open.org> on behalf of Bret Jordan <
Bret_Jordan@symantec.com>
Date: Friday, June 9, 2017 at 2:44 PM
To: "Reller, Nathan S." <
Nathan.Reller@jhuapl.edu>, "cti@lists.oasis-open.org" <
cti@lists.oasis-open.org>
Subject: [cti] Re: [EXT] [cti] Location as a Top-Level SDO
Nathan,
Well said. Thanks for writing this up. I agree with you. I also made a lot of comments in the 2.1 Working Concepts document. But I will add them here for community discussion.
Some people have stated that the follow are PROs for using an SDO... Here are my comments to them
1) Better correlation across reporting (you can re-use the UUID, tracking targeting of locations over time)
Bret: Nathan's comments in email suggest that is not actually a benefit but rather a false benefit as there would be no way to actually reuse outside of a single system and STIX
is not able a data model for a single system but rather a data model for exchange.
2) More flexibility in adding new relationships...I can add a relationship saying that your target identity is located in US, don't have to issue new identity
3) Ability to define a single location shared across multiple objects that occurred or are relevant to that one location without having to copy either coarse or fine-grained location
multiple times
Bret: I do not think this is a benefit. The overhead of creating the location SDO and all of the needed relationships would actually be a TON more work and overhead than just embedding
the data.
4) More natural uses of the STIX graph model
Bret: But you could argue then that everything or most things should be SDOs, like Nathan mentioned in his email, why are not Goals and Motivations also not SDOs
5) Less updates to the core properties of an SDO, if a location for a particular entity changes
Bret: I do not think this is really valid.
Bret
From:
cti@lists.oasis-open.org <
cti@lists.oasis-open.org> on behalf of
Reller, Nathan S. <
Nathan.Reller@jhuapl.edu>
Sent: Thursday, June 8, 2017 12:53:49 PM
To:
cti@lists.oasis-open.org Subject: [EXT] [cti] Location as a Top-Level SDO
In the last TC meeting there was some discussion about whether or not to make
Location an SDO or embed the information in other objects. I believe one of the
action items was that we should open up a discussion on the mailing list.
That's what this email does.
I guess there are at least three options.
1. Create Location SDO and use external Relationships
2. Create Location SDO and use embedded Relationships
3. No Location SDO and embed information in objects
I was not in favor of creating a Location SDO object, so I thought I would
share my thoughts. I lean toward option three.
1. Why would I reuse a Location object?
If I am new member to a community that does not have a centralized repo, which
appears to be the most common case based upon the discussions I have had so
far, then how do I know which Locations have already been defined? As far as I
know I don't even know how to query for this. In that case I will create a new
Location object with a new unique ID and send it out.
If I am a member of two sharing communities then my job is even more difficult.
First I need to know all of the existing Locations, which as I described above is
difficult or not currently possible for new members. Let's assume for this
case that I have been listening from the beginning in both communities.
Now I have a new SDO and need to link it to a Location. I better not have
deleted any of my Location objects, and I need to know that the Location object
that I want to reuse in Community A has ID A and in Community B has ID B. When
I create my Relationship to link the Location I will need two different
Relationship objects. One for Community A that links to Location with ID A and one for
Community B that links to Location with ID B.
My bundle will therefore look something like this, and I'm using pseudo STIX
json:
{
Location with ID A or B
SDO
Relationship(SDO, Location with ID A or B)
}
Again my assumption is that no centralized repository of objects. In that case
I need to resend Location object so new members know what the Location is. If I
have to resend a Location object then I would likely just create a new Location
and forget about tracking which Location came from which community. That sounds
way easier and way fater.
Plus I'm also assuming there is some normalized text for Location. I can
determine that two Locations refer to the geographic area. If I can't then we
definitely need a centralized repo for them and need a mechanism to retrieve,
but if I can determine that two are equal then why not omit the SDO object and
embed the information in an SDO? Save the overhead and they will figure it
out. They will need to do it for new members anyways.
2. We have not solved the sharing problem, and Location is not a top-level
object to share
To me so far I do not believe we have solved the sharing problem. For me
sharing in this context is the ability for multiple people and organizations to
collaborate on a common object, like Malware or Threat Actor. While I
understand the intent of the graph model, and I do like the property that
others can comment on objects without having to submit a merge request of some
sort. It makes me wonder why almost all properties are not SDOs, and how
multiple organizations can collaborate on the same object? For example, how can
I say that Threat Actor Foo has this motivation and another organization say
that Threat Actor Foo has this goal? I don't know how to merge that information
because I do not know how to determine that two objects are equal unless they
have the same ID. Plus I don't know how to handle merge conflicts where two
people have differing information. Is one person's information outdated, or is
there an actual disagreement?
I think it's because of this problem that we are leaning toward creating a
Location object SDO. I'm having a hard time wanting to create this object
because on its own it provides no value to me. If someone sent me one of the
other top-level SDO objects then I would find value in that even if it had no
relationships associated with it. A new Threat Actor is informative. A new
Malware is always interesting. But if someone sent me a Location object and
nothing else then I would be confused. I don't find that to be valuable, and I
think that is part of what bothers me about making Location an SDO. I would
argue that if Location is an SDO then other objects should be created like an
alias SDO, motivation SDO, goal SDO.
I find this similar to motivations and aliases. Threat Actor has motivation and
aliases properties. It seems likely that other organizations may want to
comment on its motivation and create a relationship. Why not make a motivation
SDO? It seems like the line was drawn somewhere, but I don't understand where
it is. It seems to me that if an object that does not provide much value on its
own is made into an SDO then other objects should as well.
Those are my thoughts. I hope they make sense. This is not a critical decision
in my opinion, but it does beg the question as to what the requirements are for
determining which objects should be considered an SDO. Perhaps that question has
been answered, and I don't know.
-Nate