STIX 2.0 Proposal1 : Extend core constructs from a single base class (#148) - STIXProject/specifications GitHub Wiki
Issue Summary
Currently all core "IDable" constructs (often referred to as "top-level objects" in STIX are defined separately with each one redefining the same set of basic shared properties. This leads to unnecessary complexity, parsing uncertainty and maintainability issues.
Proposed Solution
Define a new single base class for core "IDable" constructs specifying the set of shared properties and have each core "IDable" construct class be defined as an extension from the base class.
This lends simplicity and maintainability to the data model but would not be visible in serialized instance content other than all such constructs consistently sharing the same base properties. This should also make parsing such structures much more straightforward as you always know what to expect.
Set of shared properties
- Id
- Timestamp
- Language_Version
- Revision
- External_IDs
- Marking_Definitions
- Marking_Refs
- Structured_Markings
List of properties explicitly not shared on the base class
- Idref (this solution presumes that issue #201 will be resolved to deprecate embedded nesting of IDable constructs within each other thus eliminating the need for the idref property)
- Title and Description (not applicable to all IDable constructs and so will be captured in a DescribableProperties class that describable constructs will derive from in addition to from the IDableConstruct class.
- Confidence (not applicable to all IDable constructs and so will be added only to those appropriate)
- Information_Source (presumes that issue #233 will be resolved to abstract Source to its own IDable construct level, that issue #291 will be resolved to abstract relationships to their own IDable construct level and that issue #201 will be resolved to deprecate embedded nesting of IDable constructs within each other. Thus information source for each IDable construct will be asserted via a relationship to a Source instance rather than as a direct property of the IDable construct.)
List of core "IDable" constructs
The below list presumes that issue #386 will be resolved to remove the abstract base types for current "top-level" objects obviating them being included in this list.
(bold entries are currently existing "IDable constructs"; italic entries are new "IDable constructs" depending on acceptance of other issue proposals)
- Package (Presumes approval and resolution of issue #383)
- Indicator
- Incident
- TTP
- AttackPattern (Presumes approval of proposal for issue #360)
- MalwareInstance (Presumes approval of proposal for issue #360)
- Exploit (Presumes approval of proposal for issue #360)
- Infrastructure (Presumes approval of proposal for issue #360)
- AttackToolInformation (Presumes approval of proposal for issue #360)
- Persona (Presumes approval of proposal for issue #360)
- VictimTargeting (Presumes approval of proposal for issue #360)
- KillChain (Presumes approval of proposal for issue #360)
- KillChainPhase (Presumes approval of proposal for issue #360)
- ThreatActor
- Campaign
- ExploitTarget
- Vulnerability (Presumes approval of proposal for issue #387)
- Weakness (Presumes approval of proposal for issue #387)
- Configuration (Presumes approval of proposal for issue #387)
- CourseOfAction
- Report
- cyboxObservation (Presumes approval of proposal for issue #160)
- Identity
- Assertion (Presumes approval of proposal for issue #291)
- RelationshipBase (Presumes approval of proposal for issue #291)
- There will be various specific relationship types derived from the base type
- Sighting (Presumes approval of proposal for issue #306)
- Victim (Presumes approval of proposal for issue #149)
- Source (Presumes approval of proposal for issue #233)
- ActionImpact
- ActorType
- Cost
- Efficacy
- IntendedEffect
- LikelyImpact
- Motivation
- PlanningAndOperationalSupport
- Sophistication
CybOX IDable constructs as envisioned by applying this set of proposals to CybOX for 3.0 (this list is not asserted as complete):
- Package
- Observation
- Event
- Action
- Object
- Relationship (and a set of sub-class relationships)
- Location
Actions:
- Create a new IDableConstruct class in stixCommon with properties for the shared properties listed above
- Create new VersionType enumeration in stixCommon with a single literal of "stix-2.0"
- Modify each IDableConstruct class (e.g. Indicator) identified above by making them specializations of the IDableConstruct class or contextual specialization thereof (e.g. Identity) and removing any property definitions that are redundant with the shared properties defined on the IDableConstruct class
Significantly simplifies the model, yields much greater consistency and removes a TON of redundant property specifications.
Proposed Model
IDableConstruct class with shared properties
Set of IDable constructs and their specialization/inheritance chains
Examples
Example #1: simple TTP
Example #2: simple indicator
Example #3: simple Related_TTP relationship from the Indicator to the TTP
JSON Schema Serialization snippets
Example #1: simple TTP
{
"id": "example:ttp-6796e1db-a84d-4017-87d5-cdebfe4303be",
"type": "malware-instance",
"timestamp": { "value" : "2015-12-21T19:59:11.000000+00:00" },
"title": "Sakurel Malware"
}
Example #2: simple Indicator
{
"id": "example:ind-b8e37090-5d62-45a1-ac2e-a88601b08432",
"type": "indicator",
"timestamp": { "value" : "2015-12-21T19:59:11.000000+00:00" },
"title": "Sakurel Malware",
"indicator_expression": "this would be an observable pattern for a particular file hash using the new CybOX patterning language under consideration",
"indicator_type": [
{
"value": "File Hash Watchlist",
"vocab": "indicator-type-vocab-1.1"
}
]
}
Example #3: simple Related_TTP relationship from the Indicator to the TTP
{
"id": "example:rel-fd81e9fb-5c3b-4922-9307-dd226079c00f",
"type": "related-ttp",
"timestamp": { "value" : "2015-12-21T19:59:12.000000+00:00" },
"confidence": {
"value": {
"value": "High",
"vocab": "high-medium-low-vocab-1.0"
}
},
"from" : "example:ind-b8e37090-5d62-45a1-ac2e-a88601b08432",
"to": "example:ttp-6796e1db-a84d-4017-87d5-cdebfe4303be",
"relationship_nature": {
"value": "Indicated TTP"
}
}
JSON Serialization example snippets
Open Questions
- Should Timestamp be required?
- Should Language_Version be required?
- Should data markings be applicable for all IDable constructs or only at STIX "top-level" core constructs (Indicator, TTP, etc.)?