[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti] Details on our hesitancy WRT extension proposal, and a proposed fix
| From: | "Paul Patrick" <ppatrick@darklight.ai> |
| To: | "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>, cti@lists.oasis-open.org |
| Date: | Thu., Jul. 16, 2020 9:22 p.m. |
| Subject: | [EXTERNAL] Re: [cti] Details on our hesitancy WRT extension proposal, and a proposed fix |
Jason,
I really like the idea of using the extensions mechanism to handle this. But rather than have the custom property names as dictionary keys in the extension, might I suggest that instead create a STIX-defined customization extension that
is a dictionary of the customer property and extension names.
This would make the customization extension look consistent with other STIX predefined extensions and it was having a well-defined purpose to aide in understanding.
{
"type": "artifact",
"spec_version": "2.1",
"id": "artifact--8c6af861-7b20-41ef-9b59-6344fd872a8f",
"mime_type": "application/zip",
"payload_bin": "ZX...",
"encryption_algorithm": "mime-type-indicated",
"rank" : 5,
"toxicity": 8,
"extensions": {
"object-customizations-ext": {
"rank" : "stix-extension--8c6af861-7b20-41ef-9b59-6344fd872a8f",
"toxicity": "stix-extension--8c6af861-7b20-41ef-9b59-6344fd872a8f",
"analysis-ext" : "stix-extension--2e3df9bd-2c9d-4321-9e5e-c7d20856d6f8"
},
"analysis-ext": {
"last_parsed": "2020-07-16T20:00:47Z",
"suspected_malicious": true
}
}
}
Iâve shown the STIX pre-defined customization extension as âobject-customizations-extâ which contains a dictionary of where the key is the name of the custom property or extension and a value is the identifier of the stix-extension object
that describes it.
Paul Patrick
From:
<cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Thursday, July 16, 2020 at 3:44 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Details on our hesitancy WRT extension proposal, and a proposed fix
Below I am going to attempt to outline in detail the hesitancy I have with the extension proposal presented on the TC call this month, and also a new
proposal that I think solves for the problem.
Here is the theoretical use case I am going to walk through, with a real object: A, entity (vendor / sharing group / etc) called "Foobar", decides they want to extend the "artifact" object in two ways - by adding a fictional property called "rank", and another
one called "toxicity". In this example both of these properties are simple types (numbers) but it is important to note that a property could be complex objects as well.
Today the way this is done is via custom properties, and the STIX 2.1 specification recommends that those properties SHOULD be prefixed with x_. A further
best practice is to add namespacing to reduce the chance of collisions.
This would look roughly like below:
{
"type": "artifact",
"spec_version": "2.1",
"id": "artifact--8c6af861-7b20-41ef-9b59-6344fd872a8f",
"mime_type": "application/zip",
"payload_bin": "ZX...",
"encryption_algorithm": "mime-type-indicated",
"x_foobar_rank": 5,
"x_foobar_toxicity": 8,
}
The standard "custom property approach" has 3 key drawbacks:
a) There is no way for a recipient to know what these properties are for if they are encountered, nor is there a clear way to find that out, so how do
you collaborate
b) There is no schema that a recipient can reference to validate them, so your code has to either throw them on the floor, or just blindly trust the
data is OK
RE: [Non-DoD Source] RE: [cti] Details on our hesitancy WRT extension proposal, and a proposed fix
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]