Here are examples from an SDO and a SCO. You can clearly see how these are different. We will also add a summary table like the following.
4.1 Attack
Pattern
Type
Name:
attack-pattern
Attack
Patterns are a type of TTP that describe ways that adversaries attempt to compromise targets. Attack Patterns are used to help categorize attacks, generalize specific attacks to the patterns that they follow, and provide detailed information about how attacks
are performed. An example of an attack pattern is "spear phishing": a common type of attack where an attacker sends a carefully crafted e-mail message to a party with the intent of getting them to click a link or open an attachment to deliver malware. Attack
Patterns can also be more specific; spear phishing as practiced by a particular threat actor (e.g., they might generally say that the target won a contest) can also be an Attack Pattern.
The
Attack Pattern SDO contains textual descriptions of the pattern along with references to externally-defined taxonomies of attacks such as CAPEC [CAPEC].
Relationships from Attack Pattern can be used to relate it to what it targets (Vulnerabilities, Locations and Identities) and which tools and malware use it (Tool and Malware).
4.1.1 Properties
Common
Properties Used
|
Required:
type,
spec_version,
id,
created,
modified
Optional:
created_by_ref,
revoked,
labels,
confidence,
lang,
external_references,
object_marking_refs,
granular_markings
|
Common
Properties Not Used or Not Defined
|
id_method,
id_method_details,
is_defanged,
extensions
|
Attack
Pattern Specific Properties
|
name,
description,
kill_chain_phases
|
Property
Name
|
Type
|
Description
|
type
(required)
|
string
|
The value of this property
MUST
be attack-pattern.
|
external_references
(optional)
|
list
of type
external-reference
|
A
list of external references which refer to non-STIX information. This property
MAY
be used to provide one or more Attack Pattern identifiers,
such as a CAPEC ID. When specifying a CAPEC ID, the source_name
property of the external reference MUST
be set to
capec
and the external_id
property MUST
be formatted as CAPEC-[id].
|
name
(required)
|
string
|
A
name used to identify the Attack Pattern.
|
description
(optional)
|
string
|
A
description that provides more details and context about the Attack Pattern, potentially including its purpose and its key characteristics.
|
kill_chain_phases
(optional)
|
list
of type
kill-chain-phase
|
The
list of Kill Chain Phases for which this Attack Pattern is used.
|
6.1 Artifact
Object
Type
Name:
artifact
The
Artifact object permits capturing an array of bytes (8-bits), as a base64-encoded string, or linking to a file-like payload.
One
of payload_bin
or url
MUST
be provided. It is incumbent on object creators to ensure that the URL is accessible for downstream consumers. If a URL is provided, then the
hashes
property MUST
contain the hash of the URL contents.
6.1.1 Properties
Common
Properties Used
|
Required:
type,
id
Optional:
spec_version,
created,
modified,
object_marking_refs,
granular_markings,
id_method,
id_method_details,
is_defanged,
extensions
|
Common
Properties Not Used or Not Defined
|
created_by_ref,
revoked,
labels,
confidence,
lang,
external_references,
|
Artifact
Object Specific Properties
|
mime_type,
payload_bin,
url,
hashes,
encryption_algorithm,
decryption_key
|
ID
Contributing Properties
|
hashes,
payload_bin
Where
-
if
hashes
exists only include 1 hash from this common ordered list (based on the following order of preference) [ md5, sha1, sha256, sha512 ]
-
if no hashes
are defined and payload_bin
exists include only the payload_bin
|
Property
Name
|
Type
|
Description
|
type
(required)
|
string
|
The
value of this property MUST
be artifact.
|
mime_type
(optional)
|
string
|
Whenever
feasible, this value SHOULD
be one of the values defined in the Template column in the IANA media type registry
[Media
Types]. Maintaining a comprehensive universal catalog
of all extant file types is obviously not possible. When specifying a MIME Type not included in the IANA registry, implementers should use their best judgement so as to facilitate interoperability.
|
payload_bin
(optional)
|
binary
|
Specifies
the binary data contained in the artifact as a base64-encoded string.
This
property MUST NOT
be present if url
is provided.
|
url
(optional)
|
string
|
The
value of this property MUST
be a valid URL that resolves to the unencoded content.
This
property MUST NOT
be present if payload_bin
is provided.
|
hashes
(optional)
|
hashes
|
Specifies
a dictionary of hashes for the contents of the url
or the payload_bin.
This
property MUST
be present when the url
property is present.
|
encryption_algorithm
(optional)
|
enum
|
If
the artifact is encrypted, specifies the type of encryption algorithm the binary data (either via
payload_bin
or url)
is encoded in.
The
value of this property MUST
come from the
artifact-encryption-enum
enumeration.
If
both mime_type
and encryption_algorithm
are included, this signifies that the artifact represents an encrypted archive.
|
decryption_key
(optional)
|
string
|
Specifies
the decryption key for the encrypted binary data (either via payload_bin
or url).
For example, this may be useful in cases of sharing malware samples, which are often encoded in an encrypted archive.
This
property MUST NOT
be present when the encryption_algorithm
property is absent.
|
3.2 Requirements
for All Common Properties
This
table lists all common properties and how they are used for each STIX Object type.
|
STIX Core Objects
|
STIX Helper Objects
|
Property
Name
|
SDOs
|
SROs
|
SCOs
|
Language
|
Markings
|
Bundle
|
type
|
Required
|
Required
|
Required
|
Required
|
Required
|
Required
|
spec_version
|
Required
|
Required
|
Optional
|
Required
|
Required
|
N/A
|
id
|
Required
|
Required
|
Required
|
Required
|
Required
|
Required
|
created_by_ref
|
Optional
|
Optional
|
N/A
|
Optional
|
Optional
|
N/A
|
created
|
Required
|
Required
|
Optional
|
Required
|
Required
|
N/A
|
modified
|
Required
|
Required
|
Optional
|
Required
|
N/A
|
N/A
|
revoked
|
Optional
|
Optional
|
N/A
|
Optional
|
N/A
|
N/A
|
labels
|
Optional
|
Optional
|
N/A
|
Optional
|
N/A
|
N/A
|
confidence
|
Optional
|
Optional
|
N/A
|
Optional
|
N/A
|
N/A
|
lang
|
Optional
|
Optional
|
N/A
|
N/A
|
N/A
|
N/A
|
external_references
|
Optional
|
Optional
|
N/A
|
Optional
|
Optional
|
N/A
|
object_marking_refs
|
Optional
|
Optional
|
Optional
|
Optional
|
Optional
|
N/A
|
granular_markings
|
Optional
|
Optional
|
Optional
|
Optional
|
Optional
|
N/A
|
id_method
|
N/A
|
N/A
|
Optional
|
N/A
|
N/A
|
N/A
|
id_method_details
|
N/A
|
N/A
|
Optional
|
N/A
|
N/A
|
N/A
|
is_defanged
|
N/A
|
N/A
|
Optional
|
N/A
|
N/A
|
N/A
|
extensions
|
N/A
|
N/A
|
Optional
|
N/A
|
N/A
|
N/A
|
Bret
From: Allan Thomson <athomson@lookingglasscyber.com>
Sent: Friday, May 3, 2019 2:38:27 PM
To: Bret Jordan
Cc: Piazza, Rich; cti@lists.oasis-open.org
Subject: Re: [EXT] Re: [cti] Proposed Editing Changes to Common Properties in STIX 2.1 CSD 02
That was not clear at all from the email Rich sent.
Was completely confused to say the least.
So you are saying that there will be 4 (FOUR) common property sections for each object type where each table will call out what is required vs optional for that specific object type.
Correct?
Allan
From: Bret Jordan <Bret_Jordan@symantec.com>
Date: Friday, May 3, 2019 at 1:37 PM
To: Allan Thomson <athomson@lookingglasscyber.com>
Cc: "Piazza, Rich" <rpiazza@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [EXT] Re: [cti] Proposed Editing Changes to Common Properties in STIX 2.1 CSD 02
Allan,
This is an example for language content and we can do an example of this for SCOs.
The point is, that we will call out what is used, required, and optional on each object. So modified and such right now, today, are not required for SCOs. The table properties will reflect that.
Sent from my Commodore 128D
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
Rich – SCO does not have a requirement for modified.
Secondly the id definition for a SCO is substantially different when using deterministic ids.
Suggesting that these are ‘common’ with such modified language will confuse more than help in my opinion.
Also most of the common properties defined in this table are not defined for a SCO at all.
This is substantially changing the definition of a SCO and I strongly object to this.
Allan
All,
Bret and I noticed that because we have four different types of STIX Objects (SDOs, SROs, SCOs and STIX Meta Objects) that there is much redundancy in the specification documents describing the common properties.
Up until now, we have had almost the same text in four different places. It is easy to get confused.
We are proposing the following changes. Please review them and give us your feedback in email, Slack or within the document itself.
We have merged all of the common property sections into one (see section 3.2 of the Master Document). Whether a property is optional or required is no longer specified in the new table. The description
should contain the text of any differences that were found in the four source descriptions of each property.
This change has minor consequences for the object property tables. Here is an example of how the Language Content property table might look (see section 7.1.1 of the Master Document):
- The common properties used
and not used are called out in the top of the table
- The properties that are used are split into two lists: the required and optional properties
- If a common property has some difference that is specific to the object type (the grey rows), they remain explicitly in the table
- Object type specific properties are listed as before (not shown here).
Common Properties Used
|
Required:
type,
spec_version,
id,
created,
modified
Optional:
created_by_ref,
revoked,
labels,
confidence,
external_references,
object_marking_refs,
granular_markings
|
Common Properties Not Used or Not Defined
|
lang,
id_method,
id_method_details,
is_defanged,
extensions
|
Property Name
|
Type
|
Description
|
type (required)
|
string
|
The
type property identifies the type of object. The value of this property
MUST be language-content.
|
We hope you find these changes an improvement to the specification.
Rich and Bret
Your Humble Editors
--
Rich Piazza
The MITRE Corporation
781-271-3760
|