OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [cti-stix] Proposal - Top Level Relationship Object


Hi,

the inherent inflexibility in managing relationships in STIX/CybOX
is one of the main issues I have with STIX/CybOX. Relationships
as first-class citizens with own ID etc. is exactly the way to go,
so "+1" from me.

We are currently discussing this issue on the STIX list, 
but CybOX with its "Related_Objects" mechanism has
exactly the same issues. So with this email (and by
copying in the CybOX list), I would like to encourage
an aligned approach to this issue that works both
for STIX and CybOX.

Kind regards,

Bernd

----------------

Bernd Grobauer, Siemens CERT



> -----Original Message-----
> From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-
> open.org] On Behalf Of Terry MacDonald
> Sent: Dienstag, 28. Juli 2015 05:07
> To: Jordan, Bret
> Cc: Chris O'Brien; cti-stix@lists.oasis-open.org
> Subject: Re: [cti-stix] Proposal - Top Level Relationship Object
> 
> I see this Relationship Object as being critical to providing
> additional analytic use cases, as well as allowing people to solicit
> opinions about what others think about a suggested relationship.
> 
> 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
> 
> 
> M: +61-407-203-026
> E: terry.macdonald@threatloop.com
> W: www.threatloop.com
> 
>  <https://www.threatloop.com>
> 
> 
> 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 understand
> 
> 	2) There needs to be a single way of doing things
> 
> 	3) It needs to be easily implementable in code.
> 
> 
> 
> 
> 
> 	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 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
> 
> 
> 
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]