[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [cti-stix] Proposal - Top Level Relationship Object
[resent to CybOX list because msg had bounced on first attempt] -----Original Message----- From: Grobauer, Bernd Sent: Dienstag, 28. Juli 2015 08:56 To: 'terry.macdonald@threatloop.com'; 'bret.jordan@bluecoat.com' Cc: 'COBrien@cert.gov.uk'; 'cti-stix@lists.oasis-open.org'; 'cti-cybox@lists.oasis-open.org' 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]