This proposal attempts to define a middle ground between the current state of cyber observables and the option to make observables SDOs.
- Maintain as much compatibility as possible with STIX 2.0.
- Allow for use cases that require external relationships between observables, as well as relationships from an observable object and another SDO.
- Relationships used to define an object should remain part of a single observable. For example, the IP address in a Network Traffic object is an inherent part of the record of that network traffic. It isn't going to change down the road. It does not need to be an external relationship. In Option 1 Prime, these are captured as embedded references.
- Relationships between separate observable objects should be external when describing a state that exists, in most cases temporarily, between different observables. For example, an IP resolving to a domain is not an event record itself or a part of either the domain or IP, it's a relationship between two separate observables. It might change. In Option 1 Prime, these are captured as external relationship objects.
- Relationships directly from SDOs to observable objects should be permitted via the Observed Data wrapper.
At a practical level, we would go through the relationships defined at the root of any cyber observable object and identify the ones that should be made external. Similarly, we would identify relationships between SDOs and observed data in order to define them.
This could be implemented in two ways:
A. Redefine observed-data by making the timestamps and count optional, and ensure that you can add disconnected graphs of observable objects. The definition would be updated to capture this additional use case, and to make the semantics clear when you have an SDO->Observed Data relationship (you aren't saying that the Threat Actor "registered" an observation of a domain name, you're saying the registered the domain name). The pros of this are you only have one object to represent observables. The cons are that it means some ambiguity in how patterning works against data shared as observed-data.
B. Adding a new observable object, that does not have timestamps or count and allows lists of observables. The pros of this are cleaner specification definitions and less breakage to how observed-data works now. The cons are that there may be cases where it's unclear whether you should use observed-data or observable.
The examples below use (A).
Properties listed would be removed and captured by standard SRO relationships. All other reference properties would stay the same.
Note that this is just a proposal to get started. We can obviously work to define this more correctly as a TC.
Artifact: No changes
AS: No changes
Directory: No changes
Domain Name: resolves_to_refs
Email Address: belongs_to_ref
Email Message: No changes
File: No changes
IPv4 and IPv6: resolves_to_refs, belongs_to_refs
Network Traffic: No changes
Process: No changes
Software: No changes
URL: No changes
User Account: No changes
Windows Registry Key: No changes
X.509: No changes
- The vast majority of observable object properties are the same. This will give very good compatibility with STIX 2.0.
- In some cases, producers will repeat information about some observables. For example, if you have a destination domain name in a network traffic observation and then separately indicate that the domain resolves to a specific IP, then you would repeat the text of the domain name in the two objects.
- All use cases achievable with Option 1 Prime are achievable here. If there are cases that are not we should investigate how to do so.
(Note that this is as-is).
{
"type": "observed-data",
...
"0": {
"type": "network-traffic",
"dst_ref": "1"
},
"1": {
"type": "domain-name",
"value": "bad.com"
}
}New object (or observed-data with optional properties) captures top-level observables and represents resolved_to relationship.
{
"type": "bundle",
"objects": [
{
"type": "threat-actor",
"spec_version": "2.1",
"name": "APT472",
"modified": "2018-10-01T15:35:36.956000Z",
"labels": [
"crime-syndicate"
],
"id": "threat-actor--2fcc3593-5e15-4d98-90e3-69a7f444ac06",
"description": "The Evil Org threat actor group",
"created_by_ref": "identity--0f6532e2-7ed0-4614-9d2e-b99a27293a52",
"created": "2018-10-01T15:35:36.956000Z"
},
{
"type": "infrastructure",
"spec_version": "2.1",
"name": "APT472 Scanning Infrastructure",
"modified": "2018-10-01T15:35:36.956000Z",
"infrastructure_type": "scanning",
"id": "infrastructure--a5ee1b2d-4fb8-4d56-b46d-486486a4d7ea",
"created_by_ref": "identity--0f6532e2-7ed0-4614-9d2e-b99a27293a52",
"created": "2018-10-01T15:35:36.956000Z"
},
[
{
"type": "relationship",
"target_ref": "infrastructure--a5ee1b2d-4fb8-4d56-b46d-486486a4d7ea",
"start_time": "2018-10-01T15:35:36.956000Z",
"spec_version": "2.1",
"source_ref": "threat-actor--2fcc3593-5e15-4d98-90e3-69a7f444ac06",
"relationship_type": "uses",
"modified": "2018-10-01T15:35:36.956000Z",
"id": "relationship--02be5a09-21fb-40d8-bea4-5f32879da5d6",
"created_by_ref": "identity--0f6532e2-7ed0-4614-9d2e-b99a27293a52",
"created": "2018-10-01T15:35:36.956000Z"
}
],
{
"type": "observed-data",
"spec_version": "2.1",
"objects": {
"0": {
"value": "1.2.3.4",
"type": "ipv4-addr"
}
},
"modified": "2018-10-01T15:35:36.956000Z",
"id": "observed-data--eb428a1b-8b45-4662-b184-92d245b9c306",
"created_by_ref": "identity--0f6532e2-7ed0-4614-9d2e-b99a27293a52",
"created": "2018-10-01T15:35:36.956000Z"
},
{
"type": "relationship",
"target_ref": "infrastructure--a5ee1b2d-4fb8-4d56-b46d-486486a4d7ea",
"start_time": "2015-07-01T00:00:00.000000Z",
"spec_version": "2.1",
"source_ref": "observed-data--eb428a1b-8b45-4662-b184-92d245b9c306",
"relationship_type": "component-of",
"modified": "2018-10-01T15:35:36.956000Z",
"id": "relationship--ad4e8116-d60b-4d91-b948-888fcb23cd58",
"end_time": "2016-07-01T00:00:00.000000Z",
"created_by_ref": "identity--0f6532e2-7ed0-4614-9d2e-b99a27293a52",
"created": "2018-10-01T15:35:36.956000Z"
},
{
"type": "observed-data",
"spec_version": "2.1",
"objects": {
"0": {
"value": "1.1.1.1",
"type": "ipv4-addr"
}
},
"modified": "2018-10-01T15:35:36.956000Z",
"id": "observed-data--f8732258-16b4-4000-bea0-f8ef60850abf",
"created_by_ref": "identity--0f6532e2-7ed0-4614-9d2e-b99a27293a52",
"created": "2018-10-01T15:35:36.956000Z"
},
{
"type": "relationship",
"target_ref": "infrastructure--a5ee1b2d-4fb8-4d56-b46d-486486a4d7ea",
"start_time": "2016-07-01T00:00:00.000000Z",
"spec_version": "2.1",
"source_ref": "observed-data--f8732258-16b4-4000-bea0-f8ef60850abf",
"relationship_type": "component-of",
"modified": "2018-10-01T15:35:36.956000Z",
"id": "relationship--90481706-f6f2-44b9-bcf5-7e58373fff09",
"end_time": "2017-07-01T00:00:00.000000Z",
"created_by_ref": "identity--0f6532e2-7ed0-4614-9d2e-b99a27293a52",
"created": "2018-10-01T15:35:36.956000Z"
},
{
"type": "observed-data",
"spec_version": "2.1",
"objects": {
"0": {
"value": "bad.com",
"type": "domain-name"
}
},
"modified": "2018-10-01T15:35:36.956000Z",
"id": "observed-data--bde042de-43d9-4335-8b20-d6bf8844bd0d",
"created_by_ref": "identity--0f6532e2-7ed0-4614-9d2e-b99a27293a52",
"created": "2018-10-01T15:35:36.956000Z"
},
{
"type": "relationship",
"target_ref": "infrastructure--a5ee1b2d-4fb8-4d56-b46d-486486a4d7ea",
"start_time": "2017-07-01T00:00:00.000000Z",
"spec_version": "2.1",
"source_ref": "observed-data--bde042de-43d9-4335-8b20-d6bf8844bd0d",
"relationship_type": "component-of",
"modified": "2018-10-01T15:35:36.956000Z",
"id": "relationship--7fcf09f8-2064-4462-af12-e2f4938a0ed0",
"end_time": "2018-07-01T00:00:00.000000Z",
"created_by_ref": "identity--0f6532e2-7ed0-4614-9d2e-b99a27293a52",
"created": "2018-10-01T15:35:36.956000Z"
}
],
"id": "bundle--da749f10-539a-4e43-bfb3-a9a3329512c5"
}
New object (or observed-data with optional properties) captures top-level observables and represents uses relationship.
{
"type": "bundle",
"objects": [
{
"type": "threat-actor",
"spec_version": "2.1",
"name": "APT472",
"modified": "2018-10-01T15:35:36.940000Z",
"labels": [
"crime-syndicate"
],
"id": "threat-actor--5f84d09c-215f-4471-8ac3-6f6500868eb8",
"description": "The Evil Org threat actor group",
"created_by_ref": "identity--0f6532e2-7ed0-4614-9d2e-b99a27293a52",
"created": "2018-10-01T15:35:36.909000Z"
},
{
"type": "observed-data",
"spec_version": "2.1",
"objects": {
"0": {
"value": "joebob@example.com",
"type": "email-addr"
}
},
"modified": "2018-10-01T15:35:36.940000Z",
"id": "observed-data--e07e6947-aab8-45dc-9a22-fa8740be8d4c",
"created_by_ref": "identity--0f6532e2-7ed0-4614-9d2e-b99a27293a52",
"created": "2018-10-01T15:35:36.940000Z"
},
{
"type": "relationship",
"target_ref": "observed-data--e07e6947-aab8-45dc-9a22-fa8740be8d4c",
"start_time": "2015-07-01T00:00:00.000000Z",
"spec_version": "2.1",
"source_ref": "threat-actor--5f84d09c-215f-4471-8ac3-6f6500868eb8",
"relationship_type": "uses",
"modified": "2018-10-01T15:35:36.940000Z",
"id": "relationship--e1acfc31-a249-474c-b6b2-fd171c188ad6",
"end_time": "2016-07-01T00:00:00.000000Z",
"created_by_ref": "identity--0f6532e2-7ed0-4614-9d2e-b99a27293a52",
"created": "2018-10-01T15:35:36.940000Z"
}
],
"id": "bundle--a068bded-1c9a-4530-adb5-1d4516ccf1e1"
}
Actions could be done either via the relationship-based approach proposed by Jeff, or by including all the data in relationships as proposed by Jason, or something else. This only really gets at how you define individual, distinct, objects where it attempts to retain as much compatibility as possible.