[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0
On 30.10.2015 12:01:48, Davidson II, Mark S wrote: > > I like this approach on several levels but it does rely on the > > implementer to ensure the immutability of the object referenced by the > > URL, doesn't it? > > My opinion would be no. Just like any web resource, the object > identified by a particular URL could change over time (e.g., same > ID, new version). That said, we could make immutability a rule if we > thought it was beneficial. Were you thinking immutability would be a > positive or a negative? > For the viewing audience at home, Mark and I spent some time brainstorming around this issue over the past week. Here's my best attempt to summarize our conclusions. [Note that the following discussion assumes a REST-based TAXII Query API.] Immutability of objects under a URL-based object id scheme ========================================================== * If we move to using URLs as object ids, the underlying *data* a URL-based object id refers to *MUST* be treated as immutable. Here's why: * Let's take a strawman Indicator. Currently, the object id would be something like: example.org:indicator-14adf303-bd57-4dad-bf84-4ba8e8ef175c * If we move to URLs, the object id would be something like: taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175c * Now, why should the object behind the URL be immutable? Let's say I'm at Org A and I generate a Report object that links to the Org B Indicator (above). I'm making an direct assertion regarding that *particular* Indicator version. Now, if Org B goes and publishes a revision of the original Indicator *under the same URL*, it creates a problem for Org A. Do we still support our original assertion from our Report, given that Org B are effectively shifting the ground under our feet? Maybe, who knows? Definitely problematic, QED these things should be immutable. Implications for object versioning ================================== * Object versioning has long been a painful subject. Mark and I came up with an interesting approach. (Again, assuming a REST-based TAXII Query API.) * One can envisage a REST-based approach where I can refer to an object like this: taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175c/latest/ ...and get the latest revision of the object. * Additionally, one can envisage a REST-based approach where I can refer to an object like this: taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175c/history/ ...and get back a JSON blob something like this: [{'version': 0, 'object_id': 'taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175c', 'changelog': 'initial publication of indicator'}, {'version': 1, 'object_id': 'taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175d', 'changelog': 'typo fix'}, {'version': 2, 'object_id': 'taxii.example.org/api/query/indicators/14adf303-bd57-4dad-bf84-4ba8e8ef175e', 'changelog': 'revoking indicator, this was actually innocuous'}] * This struck us as an intriguing approach. Curious to hear your thoughts. -- Cheers, Trey -- Trey Darley Senior Security Engineer 4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 Soltra | An FS-ISAC & DTCC Company www.soltra.com -- "There are only two hard things in Computer Science: cache invalidation and naming things." --Phil Karlton
Attachment:
signature.asc
Description: PGP signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]