| Paul - thanks for the thoughtful response and feedback.
Hereâs my input.
1) Extension as a meta-object vs SDO.
AT: I could support it being classified as a meta-object provided we allow the following fields
a) revoked - used for revoking extension use
b) labels - useful for categorization of extension purposes and helps describe them/differentiate them
c) external_referneces - useful for additional background on spec of extension
d) object_marking_refs - useful for copyright and other markings associated with extensions (not just data treatment)
By the time you include the options of these 4 properties then it starts to look more like a SDO again than a meta-object. So I lean towards keeping as SDO but the TC should debate.
2) Google doc.
AT: Agreed.
3) Splitting schema property into 2 (human readable & machine-readable).
AT: Could support if others do.
4) extends_so_definition description fix.
AT: An extension may introduce only new objects not new properties and therefore this can *not* mandate that you provide a list of properties as the extension may encompass more than a single list of properties to a single object.
5) custom object extension.
AT: Agreed. That was the intention to make sure that this was clear in the spec once incorporated.
6) Two ways of doing things.
AT: I disagree with this assessment but agree that the language and guidance should be clear on when to use top-level vs sub-component. The paragraph early in the google document attempted to make this clear. We would refine once incorporated into the STIX spec.
regards
allan
While Iâm a fan of the approach, Iâd like to make a few suggestions: - Why not make STIX Extension a Metaobject, like Language Content, rather than an SDO. The STIX Extension object actually contains metadata about extensions to a SO. In addition, it shares a lot of the same behaviors as the other Metaobjects:
- not being able to be the source or target of a Relationship
- restricted set of common properties; but unlike the Language Content and Marking Definition objects, a STIX Extension object is prohibited from having an extensions property to avoid the nesting of extensions.
This would make the table of common properties reflect the following : | STIX Core Objects | STIX Helper Object | Property Name | SDOs | SROs | SCO | Extension | Language | Markings | Bundle | type | Required | Required | Required | Required | Required | Required | Required | spec_version | Required | Required | Optional | Required | Required | Required | N/A | id | Required | Required | Required | Required | Required | Required | Required | created_by_ref | Optional | Optional | N/A | Optional | Optional | Optional | N/A | created | Required | Required | N/A | Required | Required | Required | N/A | modified | Required | Required | N/A | Required | Required | N/A | N/A | revoked | Optional | Optional | N/A | N/A | Optional | N/A | N/A | labels | Optional | Optional | N/A | N/A | Optional | N/A | N/A | confidence | Optional | Optional | N/A | N/A | Optional | N/A | N/A | lang | Optional | Optional | N/A | N/A | N/A | N/A | N/A | external_references | Optional | Optional | N/A | N/A | Optional | Optional | N/A | object_marking_refs | Optional | Optional | Optional | N/A | Optional | Optional | N/A | granular_markings | Optional | Optional | Optional | N/A | Optional | Optional | N/A | defanged | N/A | N/A | Optional | N/A | N/A | N/A | N/A | extensions | Optional | Optional | Optional | N/A | Optional | Optional | N/A |
- In the Google doc sections on Modification #1 and Modification #2, remove the last paragraph which discuss use of Extensions with playbooks as playbooks are NOT part of STIX at this time.
- The schema property of the STIX Extension has duel semantics: it could be human-readable document, or it could be a reference to a JSON schema. Recommend splitting these into two separate properties so that the semantics are clear, using schema property to reference a JSON schema. This would allow a tool to programmatically know where it could get a JSON schema that actually describes the datatype and restrictions of the property, such as cardinality and range limits. Consider using external_references for documentation/human-readable descriptions
- The description of extends_so_defintion needs to state that when the property is set to true, the extensions properties MUST, not should, include one or more property names.
- SUGGESTION: For custom object support, why not add the is_extension_object property to the STIX Extension object, to promote a common processing pattern: for each STIX Extension in extensions property, locate the STIX Extension object and determine if itâs a custom object by the value of the is_extension_object property, and if not, then look at the extends_so_definition to understand how the properties are applied. If is_extension_object is true, then all properties are custom and MUST be treated the same as if the extends_so_definition were set to true. This way if a custom object has been extended by another extension, one would know which properties come from which extension.
- Since this is breaking the rule of provide âone and only one way of doing thingsâ, there needs to be a description section in âCustomizing STIXâ that explains both approaches, when to use which approach, and what are the pros and cons.
Paul Patrick DarkLight, Inc. CTI TC - 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. 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.
|