[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]