OASIS Open Mailing List Archives  ·  All Lists  ·  cti-stix  ·  2015-07

cti-stix — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

Proposal - Top Level Relationship Object


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.

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]