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


I would agree with including revoked, labels, and suggested using external_references as the means to point to human-readable content thus reserving the schema property to be used for exactly that: a URL to a JSON schema.

 

I didnât include object_marking_refs as it made more sense to mark the added property in the object itself than in the stix-extension object, since itâs more likely the itâs the value not the property that needs different markings.  This keeps the marking process consistent with what is there today.  But I could go either way on this.

 

I get and can see value in the two different models: top-level vs sub-component.  So, I can go along with reasons for supporting both.

 

Paul Patrick

 

 

From: <cti@lists.oasis-open.org> on behalf of aa tt <atcyber1000@gmail.com>
Date: Thursday, August 6, 2020 at 11:41 AM
To: Paul Patrick <ppatrick@darklight.ai>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Updated Extension Proposal

 

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

 



On Aug 5, 2020, at 3:49 PM, Paul Patrick <ppatrick@darklight.ai> wrote:

 

While Iâm a fan of the approach, Iâd like to make a few suggestions:

 

1.       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

 

2.       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.

3.       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

4.       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.

5.       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.

6.       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.

 

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]