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 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

* Let's take a strawman Indicator. Currently, the object id would be
  something like:


* If we move to URLs, the object id would be something like:


* 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:


  ...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:


  ...and get back a JSON blob something like this:

    [{'version': 0, 'object_id':
      'changelog': 'initial publication of indicator'},
      {'version': 1, 'object_id':
      'changelog': 'typo fix'},
      {'version': 2, 'object_id':
      'changelog': 'revoking indicator, this was actually innocuous'}]

* This struck us as an intriguing approach. Curious to hear your thoughts.

Trey Darley
Senior Security Engineer
4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
Soltra | An FS-ISAC & DTCC Company
"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]