Details on our hesitancy WRT extension proposal, and a proposed fix

Subject: 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

c) If these properties ever became standardized, the "x_foobar_" would go away, and all code producing or consuming them needs to be changed in some fashion.

I believe that we are all agreed on these points and they were also the main challenges the working group was tackling. As a proposed solution to these, the working group came up with this proposal

{

"type": "stix-extension",
"spec_version": "2.1",
"id": "stix-extension--8c6af861-7b20-41ef-9b59-6344fd872a8f",
"name": "Toxicity And Rank Extension",
"description": "This is an extension that adds toxicity and rank to several SDO objects",
"created_by": "Foobar org",

"schema" : "https://foobar.org/schema.json"

}

This proposal solves (a) and (b) neatly, due to the creation of the stix-extension object as a location where naming, creator, and schema information can exist.

I do not however agree it solves for (c). The reason is because if this CTI TC ever expects this work to become part of the standard, the only way to avoid changing code in producers and consumers is to leave the implementation as an extension *forever*. If these properties are ever added directly to the artifact object, code in producers or consumers *must* change. The other option which has been proposed is that extensions can live pseudo-forever as part of the spec by the CTI TC simply blessing/adopting an extension. I believe this leads to suboptimal results... over time there is going to be a build up of a large number of extensions in the object, and it will become bloatier and bloatier when exchanging large bundles if these can never be officially adopted.

We have an alternative proposal that solves for (a), (b), and (c). It is a combination of this proposal and an earlier one we made two years ago, with adaptations. The proposal is as follows

- Keep the proposed stix-extension object

- Place the properties on the object itself as custom properties, but without any x_ or namespacing.

- Continue to a new optional and global property called "extensions" to all SDOs and SCOs. However, inside this property, instead of having the values themselves directly, you enumerate *which* of the custom properties on the object are part of the extension.

The benefit of this approach is that, if and when this extension is ever adopted to the standard, *no one has to change any code at all*. The only change, which is entirely optional, is for producers to stop marking the properties as being part of an extension.

Here is an example of what this looks like:

{

"schema" : "https://foobar.com/schema.json"

}

"rank" : 5,

"toxicity": 8,
"extensions": {
"rank" : "stix-extension-8c6af861-7b20-41ef-9b59-6344fd872a8f",
"toxicity": "stix-extension-8c6af861-7b20-41ef-9b59-6344fd872a8f"
}
}

There is a downside to this approach. With this approach, there is some reduced tolerance to namespace collisions, in the sense that a producer can not apply two different extensions that both add the property "rank" at the same time. With the minigroup proposal this is possible. However, I think that the idea that a producer will want to create a confusing situation like this, where they want to attach the same conflicting property name from two different places, to be unlikely as it would make their data very confusing to work with. Therefore I think the benefit of having to change your code less often as the standard evolves outweighs this consideration.

-
Jason Keirstead
Chief Architect - IBM Security Threat Management
www.ibm.com/security

Co-Chair - Open Cybersecurity Alliance, Project Governing Board

cti message