OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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

Subject: RE: [cti] Updated Extension Proposal

The reality is that people will always tack their own properties onto the JSON regardless of if it is an official customization mechanism of STIX or not. After all in some environments, simply the process of serializing and deserializing JSON can add fields.
All the fact that we have it in the STIX specification means, is that we are making a clear statement that adding new fields should not cause validation to fail (in JSON-schema parlance, that "additionalProperties" should be left alone at it's default in the schema, which is "true"), and that fields should be preserved during the serialization/deserialization process. 
Therefore I do not think we should remove it, although I would say we should definitely water down the language around it , and remove references to "custom properties", instead pointing them at this new mechanism to encourage it.
Jason Keirstead
Chief Architect - IBM Security Threat Management

Co-Chair - Open Cybersecurity Alliance, Project Governing Board
----- Original message -----
From: Paul Patrick <ppatrick@darklight.ai>
Sent by: <cti@lists.oasis-open.org>
To: aa tt <atcyber1000@gmail.com>, "masuoka.ryusuke@fujitsu.com" <masuoka.ryusuke@fujitsu.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [EXTERNAL] Re: [cti] Updated Extension Proposal
Date: Thu, Aug 6, 2020 12:47 PM



I generally agree with Allan in that I see the STIX Extension proposal as a candidate to replace the way customization of STIX 2.1 is done today.  Like Allan, I too would be supportive of replacing the existing customization mechanism with this proposal but would recommend that the TC deprecate, not remove, the current approach until a future release.


To that end, I believe the section in the spec on Customizing STIX be updated to not only provide guidance on how to use the STIX Extension approach but provide guidance how to use it IN PLACE OF the existing schema.  I can also imagine what an update to STIX Elevator could be to aid in stepping-up from STIX 2.1 to STIX 2.1.1 to make that transition easier for people to move to the new scheme.


Paul Patrick

DarkLight, Inc.



From: <cti@lists.oasis-open.org> on behalf of aa tt <atcyber1000@gmail.com>
Date: Thursday, August 6, 2020 at 11:33 AM
To: "masuoka.ryusuke@fujitsu.com" <masuoka.ryusuke@fujitsu.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Updated Extension Proposal


Hi Ryu -


My personal feeling is that customization of STIX will remain in the standard as-is but industry best-practices will steer orgs towards using the extension proposal as the primary mechanism to change STIX.


The rationale: JSON content can always be modified regardless of what the CTI TC decides and the customization language in the current specification can just remain as most people already have done customization in products.


However, if the TC felt that it was better to remove the customization language and replace with this extension proposal then I would be supportive of that also.


Other proponents of the extension proposal, as well as other TC members should speak up on this topic.





On Aug 5, 2020, at 11:35 PM, masuoka.ryusuke@fujitsu.com wrote:


Hi Allan,


I might have missed some discussions, but

what are the relationships between

"11 Customizing STIX" of STIX 2.1 (custom properties,

custom objects, and custom extensions) and

this SEP proposal?






From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of aa tt
Sent: Thursday, August 6, 2020 12:28 AM
To: cti@lists.oasis-open.org
Subject: [cti] Updated Extension Proposal




Please find attached an updated STIX extension proposal that the mini-group worked with IBM (Jason/Emily) to incorporate an acceptable compromise to their concerns.


In summary:


1) Previously presented extension proposal is maintained and has been named âsub-component extensionâ to clarify the distinction between when it would/should be used vs the additional mechanism added for top-level extension.

2) Added the concept of Top-Level object extension to allow extension properties directly with existing STIX standard objects.

3) Clarified language/definitions around use for both aspects.


The google doc containing the specification changes are here: 


This proposal represents the agreement by all mini-group participants. We would like to encourage the TC to consider this proposal and incorporate the changes to the STIX standard.


Allan Thomson





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