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.
From:
<cti@lists.oasis-open.org> on behalf of aa tt <atcyber1000@gmail.com>
Date: Wednesday, August 5, 2020 at 11:28 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Updated Extension Proposal
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.
|