Re: [cti-stix] Proposal to establish Sightings (#306) and Relationships (#291) as our official issue topics under active consideration for STIX v2.0

[Trey Darley <trey@soltra.com>]

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