Re: [cti-stix] Relationship name tweaks

_____________________________
From: Bret Jordan (CS) <bret_jordan@symantec.com>
Sent: Thursday, September 22, 2016 4:17 PM
Subject: Re: [cti-stix] Relationship name tweaks - attributed-to
To: Terry MacDonald <terry.macdonald@cosive.com>
Cc: <cti-stix@lists.oasis-open.org>, Coderre, Robert <rcoderre@verisign.com>, JG on CTI-TC <jg@ctin.us>

There are several objects in this same boat. My fear with the relationship explosion that this represents is that you will receive a lot of objects that your product will not understand. Remember products need to know what things are for automation to take place. If the contents of a field is not predictable then it should just be a string that systems will not try and process.

Bret

Sent from my Commodore 64

On Sep 22, 2016, at 1:13 PM, Terry MacDonald <terry.macdonald@cosive.com> wrote:

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

From:cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Coderre, Robert <rcoderre@verisign.com>
Sent: Thursday, September 22, 2016 5:33:13 AM
To: JG on CTI-TC
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Relationship name tweaks - attributed-to
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

--
Rob Coderre

iDefense, Director of Product Management

Verisign, Inc.

rcoderre@verisign.com

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, MRPCTI-TC Co-SecretaryCyber Threat Intelligence Network, Inc.jg@ctin.us

cti-stix message