To reflect recent conversations, I ve attempted to update the table of common properties :
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
Optional
Optional
N/A
N/A
labels
Optional
Optional
N/A
Optional
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
Optional
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 addition, while attempting to utilize the existing proposal in an effort to transform the existing STIX mapping for MITRE s ATT&CK I came up with a recommendation that I d like to present for consideration. I d like to suggest for consideration
the following modifications to the STIX Extension object as defined in the proposal:
Adding is_extension_object as an OPTIONAL property to indicate whether the STIX Extension is for a custom object or just custom properties. If true, indicates the extension is for a custom
object; if false, the extension is for custom properties Restrict the schema property to be used only to provide a URL to the JSON schema for the extension; as suggested earlier, utilize the
external_references common property to specify a reference the location of human-readable documentation for the STIX Extension Remove the extension_properties from the STIX Extension object and instead have it become a REQUIRED property of the extension specified for the STIX object when the
extends_so_definition property is set as true.
To aid in visualizing this suggestion, I ve provided an update STIX Extension object description and a sample:
Required Comm on Properties
type, spec_version, id, created_modified
Optional Common Properties
created_by_ref, revoked, labels, external_references
Not Applicable Common Properties
confidence, object_marking_refs, granular_markings, lang, defanged, extensions
STIX Extension Specific Properties
name, description, schema, version, is_extension_object, extension_so_definition
Property Name
Required
Type
Details
type
Y
string
The type property identifies the type of object. The value of this property
MUST be stix-extension .
name
Y
string
The name property specifies a name used for display purposes during execution, development or troubleshooting
description
N
string
The description property specified a description that provides more details and context about the STIX Extension, potentially containing an explanation about what this extension does and accomplishes.
schema
Y
string
The schema property specifies a URL reference to the JSON schema for this extension.
version
N
string
The version property specifies the version of this extension. Producers of STIX extensions are encouraged to follow standard semantic versioning procedures where the version number follows the pattern MAJOR.MINOR.PATCH. This will
allow consumers to distinguish between the three different levels of compatibility typically identified by such versioning string
is_extension_object
N
boolean
The is_extension_object property indicates whether the STIX Extension is for a custom object (true) or custom properties on an existing STIX object (false).
extends_so_definition
N
boolean
The extends_so_definition property indicates whether the extension properties are defined at the same level as other STIX object properties (true) or as sub-components (false).
When set to true, the extension specified for the object
MUST contain the extension_properties property which contains the list of custom property names that are usable at the same level as the other STIX object properties.
When set to false, the extension specified for the object
MUST only contain the custom property names and corresponding values.
{
"type" :
"stix-extension" ,
"spec_version" :
"2.1.1" ,
"id" :
"stix-extension--0b5be446-2c34-4c4a-b564-2edbf919a2d5" ,
"created_by_ref" :
"identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5" ,
"created" :
"2020-08-08T19:04:585Z" ,
"modified" :
"2020-08-08T19:04:585Z" ,
"revoked" :
false ,
"labels" : [ "mitre-attack" ],
"external_references" : [
{
"source_name" :
"mitre-attack" ,
"description" :
"Extensions of the STIX spec" ,
"url" :
"https://github.com/mitre/cti/blob/master/USAGE.md#extensions-of-the-stix-spec" ,
"hashes" :
{
"MD5" :
"f41fb12dd57a931339be614c08224f45" ,
"SHA-1" :
"7eefefd325230072fc941b848efa4384f8ad0453" ,
"SHA-256" :
"0db74c60d4ed4d02f4e67cede0341932f31c4b2ac1e99e6a857c2b987c1bf7e3"
}
}
],
"name" :
"MITRE ATT&CK Pattern extensions as Top-Level Properties" ,
"description" :
"This extension adds MITRE ATT&CK pattern extensions to adding the Tactic, and Matrix objects" ,
"schema" :
"https://github.com/mitre/cti/blob/master/schemas/stix-attack-extensions.json" ,
"version" :
"1.0" ,
"is_extension_object" :
true ,
// OPTIONAL: indicates if the extension is for a custom object; default: false
"extends_so_definitions" :
true
// OPTIONAL: indicates if properties are top-level; default: false
},
{
"type" :
"x-mitre-matrix" ,
"spec_version" :
"2.1.1" ,
"id" :
"x-mitre-matrix--eafc1b4c-5e56-4965-bd4e-66a6a89c88cc" ,
"created_by_ref" :
"identity--c78cb6e5-0c4b-4611-8297-d1b8b55e40b5" ,
"created" :
"2018-10-17T00:14:20.652Z" ,
"modified" :
"2020-07-02T14:18:03.651Z" ,
"extensions" : {
"stix-extension--0b5be446-2c34-4c4a-b564-2edbf919a2d5" : {
"extension_properties" : [
// REQUIRED because extends_so_definitions is true; no other properties permitted
"name" ,
"description" ,
"tactic_refs"
]
}
},
"external_references" : [
{
"external_id" :
"enterprise-attack" ,
"source_name" :
"mitre-attack" ,
"url" :
"https://attack.mitre.org/matrices/enterprise"
}
],
"object_marking_refs" : [
"marking-definition--fa42a846-8d90-4e51-bc29-71d5b4802168"
],
"name" :
"Enterprise ATT&CK" ,
"description" :
"Below are the tactics and technique representing the MITRE ATT&CK Matrix for Enterprise. The Matrix contains information for the following platforms: Windows, macOS, Linux, AWS, GCP, Azure,
Azure AD, Office 365, SaaS." ,
"tactic_refs" : [
"x-mitre-tactic--ffd5bcee-6e16-4dd2-8eca-7b3beedf33ca" ,
"x-mitre-tactic--4ca45d45-df4d-4613-8980-bac22d278fa5" ,
"x-mitre-tactic--5bc1d813-693e-4823-9961-abf9af4b0e92" ,
"x-mitre-tactic--5e29b093-294e-49e9-a803-dab3d73b77dd" ,
"x-mitre-tactic--78b23412-0651-46d7-a540-170a1ce8bd5a" ,
"x-mitre-tactic--2558fd61-8c75-4730-94c4-11926db2a263" ,
"x-mitre-tactic--c17c5845-175e-4421-9713-829d0573dbc9" ,
"x-mitre-tactic--7141578b-e50b-4dcc-bfa4-08a8dd689e9e" ,
"x-mitre-tactic--d108ce10-2419-4cf9-a774-46161d6c6cfe" ,
"x-mitre-tactic--f72804c5-f15a-449e-a5da-2eecd181f813" ,
"x-mitre-tactic--9a4e74ab-5008-408c-84bf-a10dfbc53462" ,
"x-mitre-tactic--5569339b-94c2-49ee-afb3-2222936582c8"
],
}
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:
https://docs.google.com/document/d/1TkXv1btieo33BAEcVsprgbVob5qeHOHVAQU0bg9AK-c/edit#heading=h.y2hw6f789m5b 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