Re: [cti-stix] Proposal - Top Level Relationship Object

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

Relationship should also have a contributor ID of some sort (who is the entity asserting that relationship).

-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


"Wunder, John A." ---2015/07/28 04:51:37 PM---No directionality or description/qualifier? It seems like you want to be able to say *what* a relati

From: "Wunder, John A." <jwunder@mitre.org>
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, JG on CTI-TC <jg@ctin.us>
Cc: "Chris O'Brien" <COBrien@cert.gov.uk>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 2015/07/28 04:51 PM
Subject: Re: [cti-stix] Proposal - Top Level Relationship Object
Sent by: <cti-stix@lists.oasis-open.org>

---

No directionality or description/qualifier? It seems like you want to be able to say *what* a relationship is describing and also which direction it goes in.

I.e. TTP malware "is variant of" other TTP malware
vs. TTP malware "is same as" other TTP malware given a different name by a different vendor

From: <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret"
Date: Tuesday, July 28, 2015 at 3:41 PM
To: JG on CTI-TC
Cc: Chris O'Brien, "cti-stix@lists.oasis-open.org"
Subject: Re: [cti-stix] Proposal - Top Level Relationship Object

I see the relationship object being pretty simple and straight forward: 


Relationship
IDREF (1-n)
Source
Confidence


Thanks,

Bret



Bret Jordan CISSP 
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Jul 28, 2015, at 13:16, JG on CTI-TC <jg@ctin.us> wrote:

Chris:

You are not going insane...we are all dealing with these same issues.

Some of the more recent discussions (after you made this post) with
respect to 'Sightings' seem to make a lot of sense to me...that is, to
push the Sighting functionality further down in the data model...That
is, down to the CybOX level...

And I think we need to think about the Relationship object with respect
to 'Communities of Interest'... For example, a malware research
Community of Interest that is using Indicator, Observable, TTP and
ExploitTarget may seek to express Relationships in a way that shows the
Static and Behavioral characteristics of the malware (deep in the data
model and at a very refined level of granularity)

...Whereas an Incident Response Community of Interest that is using
Indicator, Incident and CourseOfAction may need the Relationship object
defined in a separate way.... that is, one that is more tied to
"actionable intelligence" which may then tie into ExploitTarget,
ThreatActor, and Campaign...which then becomes of interest to a law
enforcement Community of Interest.

Of course... handling this may take us back into the debate on Profiles...

Jane Ginn
CTIN

On 7/27/2015 3:44 AM, Chris O'Brien wrote:
For what it's worth, from me, I think this would be pretty huge (coupled with the sightings object as well). As an analyst trying to identify useful data for my customers on large data sets, I'm interested in being able to produce top-level, automated assessments on data quality of feeds/dbs of stix data, and one of the ways that I'd suggest that a specific data point is of a 'high quality' is if it has multiple relationships and/or sightings. Add in to that the ability to rank producers, and even analytical assertion confidence, and you've got all the makings of a an algorithm for a heuristic grading scheme that could feed something even more awesome...like a machine learning project that can conduct threat pattern detection... As you say, Bret, this also gives scope for those relationships to have their own concept of 'quality' based on their related analytical assertions / confidence.

I'd perhaps throw in to the discussion that it may not need to be a standalone object in its own right - we're currently experimenting with using the existing stix architecture relationships (with a little extra meta data) to achieve the desired effect, but it gets messy quickly and direct references to the relationships are by-way-of the object that they sit on (then you ask...which end of the relationship is the 'master' for that relationship, or must they both be updated when a change is made...what happens if one of them isn't in your namespace, etc, etc). Jimmy-rigging solutions to those issues feels feasible, but messy, prescriptive and makes anyone with a coding background have a little cry to themselves. It's something we're having to think about here at the moment - just wanted to mention that it's still possible and would be less impactful to existing deployments.

Cheers,
cob

PS: If anyone else is looking in to this sort of heuristic / predictive / minority report-esque implementation, it'd be good to hear from you. If only to confirm that I'm not going completely insane.


-----Original Message-----
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: 24 July 2015 22:57
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Proposal - Top Level Relationship Object

I would like to see a top level relationship object that just contains references to the times that are related. This needs its own ID so people can reference it and disagree with it or sight it or enrich it with other data.

Bret

Sent from my Commodore 64
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


--
Jane Ginn, MSIA, MRP
Cyber Threat Intelligence Network, Inc.
jg@ctin.us



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php