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
410-694-4335
From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Rich Piazza
Sent: Monday, October 19, 2020 3:37 PM
To: 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-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
