[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] STIX 2.1 WD03 to WD04 changes
Chris compared WD03 to WD04 on purpose, as MITRE tries to make changes to python-stix2 one WD at a time.
😊 He will probably generate a similar list when WD05 is âfinalizedâ. Rich From: <cti@lists.oasis-open.org> on behalf of "Lenk, Chris" <clenk@mitre.org> Hello, See below for a list of the changes I found between WD03 and WD04 of the STIX 2.1 specification. I generated this list to help with updating the schemas, tools, and libraries, but maybe youâll find it helpful as well. Note that these are
just changes to normative statements; the list doesnât include typo fixes or non-normative wording changes. Thank you, Chris Lenk MITRE Pt 1 core/master document ========================= ids MUST be UUID (RFC 4122) compliant SDOs/SROs/SHOs SHOULD use UUIDv4 SDOs/SROs/SHOs MUST NOT use a namespace of 00abedb4-aa42-466c-9c01-fed23315a9b7 if generating a UUIDv5 SCOs SHOULD use UUIDv5, with namespace 00abedb4-aa42-466c-9c01-fed23315a9b7, value set to the ID-contributing properties for the SCO markings can have markings, but can't mark themselves (no circular references) is_defanged, extensions must not be properties on non-SCO objects infrastructure is no longer a reserved type action is now a reserved type new property: marking-definition.name new requirements on custom objects: must have at least 1 property name MUST be in ASCII and MUST only contain the characters aâz (lowercase ASCII), 0â9, and underscore (_) property names must be 3-250 characters in length custom extensions requirements removed: name MUST be in ASCII and MUST only contain the characters aâz (lowercase ASCII), 0â9, and underscore (_) property names must be 3-250 characters in length requirements enforceable by validator and not schemas: all SCOs relationships requirements we can't enforce: The UUID part of the identifier MUST be unique across all objects produced by a given producer regardless of the type identified by the object-type prefix. Meaning, a producer MUST NOT reuse the UUID portion of the identifier
for objects of different types. SCOs: Producers not following these rules [for IDs] MUST NOT use a namespace of 00abedb4-aa42-466c9c01-fed23315a9b7 cyber observable container is deprecated and SHOULD NOT be used For Custom Properties that use the hex type, the property name MUST end with '_hex'. For Custom Properties that use the binary type, the property name MUST end with '_bin'. Pt 2 SDOs and SROs ================== new relationship: attack-pattern delivers malware new relationship: campaign compromises infrastructure new relationship: campaign uses infrastructure course of action: action property removed course of action: new properties: action_type, os_execution_envs, action_bin, action_reference course of action: only one of following can be present: action_bin, action_reference new relationship: course-of-action investigates indicator new relationship: course-of-action mitigates indicator new relationship: course-of-action remediates malware, vulnerability new object type: Grouping new relationship: indicator indicates infrastructure new object type: Infrastructure new relationship: intrusion-set compromises infrastructure new relationship: intrusion-set hosts, owns infrastructure new relationship: intrusion-set uses infrastructure location.street_address is renamed to 'code' in WD04 but renamed back in WD05... malware: new properties: is_family, aliases, first_seen, last_seen, os_execution_envs, architecture_execution_envs, implementation_languages, capabilities, sample_refs malware.aliases is now optional new relationship: malware authored-by threat-actor, intrusion-set new relationship: malware beacons-to, exfiltrate-to (renamed exfiltrate-to in WD04) infrastructure new relationship: malware communicates-with ipv4-addr, ipv6-addr, domain-name, url new relationship: malware controls malware new relationship: malware downloads, drops malware, tool, file new relationship: malware exploits vulnerability new relationship: malware targets infrastructure new relationship: malware variant-of malware new object type: malware-analysis new relationship: threat-actor compromises infrastructure new relationship: threat-actor hosts, owns infrastructure new relationship: threat-actor uses infrastructure new property: tool.aliases new relationship: tool delivers malware new relationship: tool drops malware new relationship: tool targets infrastructure new relationship: tool uses infrastructure new relationship: vulnerability impacts infrastructure, tool relationship source_ref aht target_map must not point to language-content requirements enforceable by validator and not schemas: course-of-action.action_type SHOULD come from course-of-action-type-ov course-of-action.os_execution_envs SHOULD be a CPE v2.3 entry grouping.context SHOULD come from grouping-context-ov infrastructure.infrastructure_types SHOULD come from infrastructuretype-ov infrastructure.last_seen MUST be greater than or equal to first seen malware.last_seen MUST be greater than or equal to first seen malware.os_execution_envs SHOULD be a CPE v2.3 entry malware.os_execution_envs SHOULD come from processor-architecture-ov malware.implementation_languages SHOULD come from implementation-language-ov malware.capabilities SHOULD come from malware-capabilities-ov malware-analysis.product SHOULD be all lowercase with words separated by a dash "-". malware-analysis.av_result SHOULD come from malware-av-result-ov observed-data exactly one of [objects, object_refs] must be present requirements we can't enforce: Malware SHOULD contain defanged content Malware MUST contain the 'name' property if it represents a malware family rather than a malware instance If malware.is_family is false, then all samples listed in sample_refs MUST refer to the same binary data malware family variant-of malware instance MUST NOT be used malware-analysis.product MUST = "anonymized" if name of product cannot be used Multiple SCOs not related to each other MUST NOT be contained within the same Observed Data instance.
Pt 3 SCOs ========= new properties on all SCOs: id, spec_version, object_marking_refs, granular_markings, is_defanged each SCO now defines properties that should be used in the algorithm to generate its ID all *_ref/s properties (on SCOs and SCO extensions) point to stix ids now, not object_refs email-message new property: message_id email-message.additional_header_fields: values must be list of type string windows-peoptional-header-type must contain at least 1 of its properties http-request-ext.request_header: values must be list of type string requirements enforceable by validator and not schemas: 'hashes' properties must come from hash-algorithm-ov artifact.encryption_algorithm must be from encryption-algorithm-enum artifact-encryption-enum removed file.hashes: uses hash-algorithm-ov, not -enum windows-pebinary-ext.file_header_hashes MUST come from hash-algorithm-ov Pt 4 Vocabs =========== new vocab: course-of-action-type-ov rename artifact-encryption-enum to encryption-algorithm-enum new vocab: grouping-context-ov new vocab: implementation-language-ov new value: indicator-type-ov: unknown new vocab: infrastructure-type-ov new vocab: malware-av-result-ov new vocab: malware-capabilities-ov new values: malware-type-ov: bootkit, downloader, unknown, webshell, wiper new vocab: processor-architecture-ov region oceana renamed to oceania new value: threat-actor-type-ov: unknown new value: tool-type-ov: unknown new value: windows-registry-datatype-enum: REG_DWORD_LITTLE_ENDIAN Pt 5 Patterning =============== No substantive changes |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]