Thatâs a fair point. I have to admit my main concern with it is if we see products adding extension objects in each package instead of persisting them that weâll run into a scenario where we need to both maintain long-term stores of extension GUIDs for to resolve internal mappings and read through and update these when each package is parsed.
That feels messier to me than just being able to directly reference a URL, but I also understand the desire to be able to provide versioning for this within STIX. The trouble I run into when thinking about it is that the ID mappings a system will need to persist to handle both types of resolutions may end up forcing redownloading of the schema each time it shows up with the possibility that the same URL would be used for each in which case it would end up still missing out on the precise definition.
The use of an object instead of just pointing to a URL that follows the major / minor / patch versioning scheme makes more sense to me when we inject content to the top level of an object since the extension_properties provide a really useful mechanism to explain these. I might just not be thinking about this enough though.
//SIGNED//
Jeffrey Mates, Civ DC3/TSD
Computer Scientist
Technical Solutions Development
jeffrey.mates@dc3.mil
410-694-4335
From: Bret Jordan <bret.jordan@broadcom.com>
Sent: Monday, October 19, 2020 6:24 PM
To: Mates, Jeffrey CIV DC3/TSD <Jeffrey.Mates@dc3.mil>
Cc: Rich Piazza <rpiazza@mitre.org>; cti@lists.oasis-open.org
Subject: Re: [cti] RE: [Non-DoD Source] [cti] Another STIX 2.1 Extension example
All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.
The thing I like about the nested extension under a UUID is that if you do not know about the extension it is super easy to just capture the data as JSON.Raw data and store it. Putting values at the top-level means you have to parse the data first and pull everything out that you know how to use, then loop back through to see if there is anything else and then try and figure out if you can do anything with it. I find that to be much more problematic.
Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
On Mon, Oct 19, 2020 at 3:12 PM Mates, Jeffrey CIV DC3/TSD <Jeffrey.Mates@dc3.mil < Caution-mailto:Jeffrey.Mates@dc3.mil > > wrote:
Iâve started resuming work on the Incident object recently, and thought it would be a good candidate to test out extensions for a new SDO. Iâve attached a single sample of it with the extension that defines it along with the schema since I havenât been able to get it up to GitHub.
From what I can tell it works well for creating new SDOs, but for extended them I do prefer option #1 as a consumer to option #2 as it means a shallower parse is permitted. I understand the risk of errors, but tracking down sub-properties of potentially variable UUIDs just feels like it will cause all extra grief on the consumer side for non-Internet connected systems.
//SIGNED//
Jeffrey Mates, Civ DC3/TSD
Computer Scientist
Technical Solutions Development
jeffrey.mates@dc3.mil < Caution-mailto:jeffrey.mates@dc3.mil >
410-694-4335
From: cti@lists.oasis-open.org < Caution-mailto:cti@lists.oasis-open.org > <cti@lists.oasis-open.org < Caution-mailto:cti@lists.oasis-open.org > > On Behalf Of Rich Piazza
Sent: Monday, October 19, 2020 3:37 PM
To: cti@lists.oasis-open.org < Caution-mailto:cti@lists.oasis-open.org >
Subject: [Non-DoD Source] [cti] Another STIX 2.1 Extension example
All active links contained in this email were disabled. Please verify the identity of the sender, and confirm the authenticity of all links contained within the message prior to copying and pasting the address to a Web browser.
As part of the MITRE CTI repository (Caution-Caution-https://github.com/mitre/cti < Caution-https://github.com/mitre/cti > < Caution-Caution-https://github.com/mitre/cti < Caution-https://github.com/mitre/cti > > ), we expressed all of the CAPEC attack patterns using STIX.
I converted one of the attack patterns (CAPEC-66: SQL Injection) from using custom properties to using property-extensions.
As in other examples that people have posted â adding properties seems pretty straightforward. Maybe expressing a new object (SDO, SCO, SRO) using the new extension facility is an example someone could share to make sure it doesnât have any gotchas.
Using the schema from the Extension Definition object for validation might be something more interesting to explore.
Rich
--
Rich Piazza
Lead Cyber Security Engineer
The MITRE Corporation
781-271-3760
