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.

Thanks,

Bret

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 <> 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 theimplementer to ensure the immutability of the object referenced by theURL, doesn't it?My opinion would be no. Just like any web resource, the objectidentified by a particular URL could change over time (e.g., sameID, new version). That said, we could make immutability a rule if wethought it was beneficial. Were you thinking immutability would be apositive or a negative?For the viewing audience at home, Mark and I spent some timebrainstorming around this issue over the past week. Here's my bestattempt 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 DarleySenior Security Engineer4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430Soltra | An FS-ISAC & DTCC Companywww.soltra.com--"There are only two hard things in Computer Science: cacheinvalidation and naming things." --Phil Karlton

Attachment:
signature.asc

Description: Message signed with OpenPGP using GPGMail