Robert,
Will you be willing to add these relationships to the 2.1 Concepts document? It would be good to capture them in Google Docs so we do not loose them in the mass of email.
Bret
From: Coderre, Robert <rcoderre@verisign.com>
Sent: Friday, September 23, 2016 9:56:00 AM
To: Bret Jordan (CS)
Cc: Terry MacDonald; cti-stix@lists.oasis-open.org; JG on CTI-TC
Subject: RE: [cti-stix] Relationship name tweaks - attributed-to
Brett,
As examples, these are some of the types of relationships we maintain. (Key: Fundamental = SDO, Relationship = SRO)
|
Fundamental ->
|
Relationship ->
|
Fundamental(s)
|
|
Vulnerability
|
Affects
|
Vulnerability Tech, Package
|
|
Vulnerability
|
Exploited By
|
File, Malware Family, Malicious Tool
|
|
Vulnerability
|
Fixed By
|
Vulnerability Tech, Package
|
|
Vulnerability
|
Identified By
|
Detection Signature
|
|
Vulnerability
|
Mentioned By
|
Intelligence Alert
|
|
|
|
|
|
Threat Actor
|
Advertiser Of
|
Malware Family, Malicious Tool
|
|
Threat Actor
|
Affiliated With
|
Threat Group, Malicious Event
|
|
Threat Actor
|
Alias
|
Threat Actor
|
|
Threat Actor
|
Associated With
|
Malware Family, Malicious Tool
|
|
Threat Actor
|
Author Of
|
Threat Campaign, Malicious Event
|
|
Threat Actor
|
Developer Of
|
Malware Family, Malicious Tool
|
|
Etc.
|
|
|
However, I wouldn’t necessarily lobby for all of these (this is just a small sampling) to be added in to the spec for 2.0. I would lean towards more generic
relationship types to get the ball rolling. I am positive communities of interest will arise quickly.
From: Bret Jordan (CS) [mailto:Bret_Jordan@symantec.com]
Sent: Thursday, September 22, 2016 11:37 PM
To: Coderre, Robert
Cc: Terry MacDonald; cti-stix@lists.oasis-open.org; JG on CTI-TC
Subject: Re: [cti-stix] Relationship name tweaks - attributed-to
What I would like to know is, what other relationships "should" be defined in the specification between other objects.
Bret
Sent from my Commodore 64
I am coming around to Terry's way of thinking on this. The single level relationship is much easier to parse and multiple relationships between SDOs only enriches the story we are trying to convey.
The relationship we have defined now, attributed-to, is the generic use case. It can be used with a minimum of information, and in many cases is a mere assertion.
What Gary and the others are suggesting are more nuanced relationships that convey a deeper meaning. I would expect that if someone were to use a planned-by relationship, there is more evidence to support that, versus a generic attribution. Same for executed-by
and others yet to come.
We are not restricted to adding these additional relationships. Perhaps it may make more sense to stop at the generic case for 2.0 and if we see significant adoption of some of these other relationship types to add them to the vocabulary
in 2.1 and beyond.
--
iDefense, Director of Product Management
I much prefer district single level relationships. We should suggest a list of relationships in an open vocab (as we do now) allowing people to add to the list of relationship types for each object type. Over time the popular ones will become apparent and
we should codify their popularity by adding them to the next release of STIX.
We absolutely need this multi-relationship connectivity between SDOs to provide the flexibility for users to accurately describe the nuances of the Threat Intel they are wanting to portray. The suggested open vocabulary will provide the structure to allow
automation to occur, and the extensibility of that open vocab will provide flexibility to describe accurately.
I do not like adding another layer to the relationships at all. I would prefer keeping them single level. All a double layer relationship would do is classify the object type at the other end of the relationship, which is an unnecessary addition as the relationship
is already able to do that as the id in the target_ref field contains the object_type.
Cheers
Terry MacDonald
Cosive
On 23 Sep 2016 4:26 AM, "Bret Jordan (CS)" <Bret_Jordan@symantec.com> wrote:
So what you are saying is having a required relationships of "attributed-to" with the option of additional labels or relationship types of "executed-by" or "planned-by"???
Should these other things really be "sub_relationship_types?
Bret
I agree with Jane here, in that as described each relationship type can have very specific, nuanced meanings. That does convey richer information, but as noted elsewhere, can cause problems from an MRTI perspective. In our graph model
for our product, we have multiple relationship types and these are specific and constrained for different object types by schema rules. That works well for us and keeps our data consistent, but I would not necessarily push that onto a larger community.
I am more in favor of a single relationship type ("attributed-to"), with a label to convey additional detail. However, I would have an open vocabulary that predefines most of the relationship types so we can have consistency and better
interoperability. It can be extensible, as we do for other vocabs, but the base options should be enumerated.
Rob
--
iDefense, Director of Product Management
On Sep 21, 2016, at 8:43 PM, JG on CTI-TC <jg@ctin.us> wrote:
John:
There is a big difference between all three of these proposed relationship names:
"attributed-to" - This is from the POV of an analyst that has either information from another research entity or information from his/her own team. However, it sounds as if he/she is not firm in the approach towards attribution. It sounds a little like
legalese.
"executed-by" - This sounds much more definitive; however, the information in the hands of the analyst at the time may or may not be definitive. Therefore, it may be necessary for the analyst to qualify his/her own judgement.
"planned-by" - This seems to be more intimately linked to an interpretation, on the part of the analyst, about internal operations of the APT team. For some of the more advanced APT research teams this may be possible. For others, there may not be enough
depth to the bench. Or, for APTs that have been around for a long time and have left a significant temporal footprint (e.g., the Dukes) this interpretation of a "planning" step may be possible. But for newly discovered threats, it might not be possible for
an analyst to claim knowledge of pre-attack plans.
I can only say that I would like to have all three of these relationship names available to me so I could choose the one that is most appropriate to the situation. Then, the question becomes, how to automate it for MRTI.
Jane
On 9/21/2016 11:32 AM, Wunder, John A. wrote:
All,
A couple times I’ve alluded to some changes to relationship names that Gary Katz proposed. Given some last-minute changes (removing Incident, mostly)
it turns out only one is still applicable for 2.0 so I’d like to raise it now.
The relationship in question is “attributed-to”, when used from a Campaign to a Threat Actor or Intrusion Set. For example, Operation Aurora is attributed
to APT1.
Gary (or rather the analysts he worked with) suggested that it might be better to use “executes” or “plans”. So Operation Aurora is planned by APT1,
or Operation Aurora was executed by APT1.
So, the decision is:
1.
Continue to use “attributed-to” (no change)
2.
Use “executed-by”
3.
Use “planned-by”
Thoughts? I’m pretty open to either 1 or 2, but #3 sounds different to me.
John
--
Jane Ginn, MSIA, MRP
CTI-TC Co-Secretary
Cyber Threat Intelligence Network, Inc.
jg@ctin.us
|