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

I like that idea.



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 Nov 4, 2015, at 03:52, Trey Darley <trey@SOLTRA.COM> wrote:

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: Message signed with OpenPGP using GPGMail

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]