[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [Non-DoD Source] RE: [cti] Details on our hesitancy WRT extension proposal, and a proposed fix
Is the proposal here to only allow top level properties to be added or would we use a dot notation for sub-elements for this? Iâm not sure if this is really necessary, but if we are using it to also map extensions it could be useful. For storage reasons Iâm also curious if it is best to reference extensions in the listed key / value method where both are strings, or if they should be stored as an array based on the extension UUID which would look like this (using dot notation as well): { "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": { "stix-extension--8c6af861-7b20-41ef-9b59-6344fd872a8f": ["rank", "toxicity"], "stix-extension--2e3df9bd-2c9d-4321-9e5e-c7d20856d6f8": ["extensions.analysis-ext"] }, "analysis-ext": { "last_parsed": "2020-07-16T20:00:47Z", "suspected_malicious": true } } } This would save space, but would require iterating through all extensions to find if one is an extension which a simple key /value version wouldnât. //SIGNED// Jeffrey Mates, Civ DC3/TSD Computer Scientist Technical Solutions Development jeffrey.mates@dc3.mil 410-694-4335 From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Jason Keirstead That would work as well, I like it. Paul Patrick --- [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> 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. 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: { 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 <span style="font-size-Your data has been truncated. |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]