It needs to be able to:
- Be sent independently of the 'data' nodes (Indicator, Threatactor, Observable, Objects, etc)
- Reference the ID of 'data nodes' outside of the namespace of the producer of the relationship (in other words - allow a third party to suggest a relationship between the data provided by others)
- Allow an organisation to only send a relationship object without necessarily sending the data nodes that describe each end. i.e. providing the ability to say this object has a relationship with this other object, but if you want to know more you need to ask me for the other object, and if you are authorised I will give it to you).
- Allow someone broadcast whether they either agree, disagree, or are unsure with another persons relationship assertion (although this may be better being send as a separate object (a +1 object?)).
Note: These points (esp point 3) have the knock on effect of forcing the ID namespace to be tied back to the organisations domain name. If we did that, and mandated what services need to be provided by TAXII at what location, then it would be implicit how to request more information about an object using just it's ID as the source.
Cheers
Terry MacDonald | STIX, TAXII, CybOX Consultant
Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.
On 28 July 2015 at 00:46, Jordan, Bret <bret.jordan@bluecoat.com> wrote:
The things you bring up here are some the elements and use cases I can foresee. However, in my opinion, after spending lots of time thinking though it and trying to write code for it, the Relationship Object needs to be top-level and needs to stand on its own. We need to be able to send just a Relationship Object and nothing else.I envision a day when this technology can grow beyond its current vision and become the DLNA of security products. Imagine what could be done if devices and technologies could actually share actionable threat intelligence and perform sightings and data-enrichment on that threat intelligence.If we are successful in building this thing and; 1) make it easy to use, 2)make it so that one can actually implement it in code, then this technology could be an enabling element for a lot of new start-ups. This could be a game changer for cyber-defense.We just need to be governed by a few key principles...1) It needs to be easy to understand2) There needs to be a single way of doing things3) It needs to be easily implementable in code.Thanks,BretBret Jordan CISSPDirector of Security Architecture and Standards | Office of the CTOBlue Coat SystemsPGP 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 27, 2015, at 04:44, Chris O'Brien <COBrien@cert.gov.uk> 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