[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Storing the Incident extension definition in the OASIS CTI common STIX object repository
Sorry for resending this I am still working on getting my new email address on the OASIS approved list so I can add it to the account. //SIGNED// Jeffrey Mates, Civ DC3/TSD Computer Scientist Technical Solutions Development jeffrey.mates@dc3.mil 410-694-4335 From: MATES, JEFFREY F GS-14 USAF AFOSI AFOSI/TSD Sorry for the delay in responding I was on leave. One of our major goals with this is to create a single highly flexible extension that is not just suited for DC3âs ICFs, but also works across the industry. I can definitely see about getting what we have posted up, but my concern is that once something is publicly shared it will become more difficult to change. As such I wanted to bring it to the TC for feedback before doing so. If there are no objections or suggestions with what I sent out however I can see about getting it pushed up to GitHub. Rich, for the shared repository is it best if I provide an account that can be added as a contributor so that it can create a branch directly or should I fork the repo and generate a pull request from that? //SIGNED// Jeffrey Mates, Civ DC3/TSD Computer Scientist Technical Solutions Development 410-694-4335 From: MARONEY, PATRICK <rx118r@att.com> 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. Since weâre (evidently) not going to try to address the global issue of representing Incidents as a top-level concept (at this time), then does it make sense to just create this extension (or create another) as a model of the DC3 ICF? Given the OMB ICF tie-in it needs to be an exact match. Curious what the DC3 Team thinks. Patrick Maroney From:cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Rich Piazza <rpiazza@mitre.org> Hi Jeff, You may have seen the email that is forwarded (below) about where to store extension definitions. I was wondering if you could create a pull request for your Incident extension definition. As it says below, DHS/CISA is trying to encourage individuals/organizations who are creating extension definitions to store them in a common repository. If you feel that your extension definition is just a draft, you may want to wait, but I donât think there is any harm in âadvertisingâ it now in the common repository. There is a version property on the extension definition object which would help deal with improvements to the draft. Rich -- Rich Piazza Lead Cyber Security Engineer The MITRE Corporation 781-271-3760 From: <cti@lists.oasis-open.org> on behalf of Rich Piazza <rpiazza@mitre.org> Hi All, With introduction of extensions in STIX 2.1, we are left with the issue of where to store extension definition objects, related schemas, and documentation. Previously we had the SEP repository, which would have been the location to store such information and âadvertiseâ it to other community members. What is being proposed in this email is NOT required of anyone defining extensions or producing and/or consuming content with extensions, but it is something like the SEP repository which would be useful to STIX users. We are not sure if this proposal needs to be voted on by the TC. However, we are looking for comments, suggestions, etc., to make this as useful as possible to the community. The recently introduced OASIS CTI common object repository (Caution-https://github.com/oasis-open/cti-stix-common-objects < Caution-https://urldefense.com/v3/__https:/github.com/oasis-open/cti-stix-common-objects__;!!BhdT!y17I-LCzB3pA8N-rdAT3WIKBNgaLcDp4YaSZXNQYhUp7icj1s5lEURSN4kSj32Hmgg$ > ) seems like a good place to store extension information. As part of AIS, DHS/CISA defined ACS data markings and it has been implemented as an extension. We will use it as an example of what we have in mind for storing extension information in that repository. If you go to the repository, it contains a directory called objects. Within this directory are subdirectories for each STIX object type, which contain individual common objects of that object type. Each file contains one object. The format of the file is a bundle that contains the one object. A directory for extension objects would contain files who names are extension-definition-<id property of object>.json. See: Caution-https://github.com/oasis-open/cti-stix-common-objects/tree/adding-extensions/objects/extensions < Caution-https://urldefense.com/v3/__https:/github.com/oasis-open/cti-stix-common-objects/tree/adding-extensions/objects/extensions__;!!BhdT!y17I-LCzB3pA8N-rdAT3WIKBNgaLcDp4YaSZXNQYhUp7icj1s5lEURSN4kSB7GqclQ$ > Here is the file contents for the ACS data marking extension definition: { "type": "bundle", "id": "bundle--1d3fa741-e3bd-451a-acf5-b2f01d075ba7", "objects": [ { "id": "extension-definition--3a65884d-005a-4290-8335-cb2d778a83ce", "type": "extension-definition", "spec_version": "2.1", "name": "isa-acs-3-0", "description": "This schema adds ACS data markings", "created": "2021-02-01T00:00:00.000000Z", "modified": "2021-02-01T00:00:00.000000Z", "created_by_ref": "identity--b3bca3c2-1f3d-4b54-b44f-dac42c3a8f01", "schema": "Caution-https://github.com/oasis-open/cti-stix-common-objects/tree/main/extension-definition-specifications/acs-data-markings" < Caution-https://urldefense.com/v3/__https:/github.com/oasis-open/cti-stix-common-objects/tree/main/extension-definition-specifications/acs-data-markings*22__;JQ!!BhdT!y17I-LCzB3pA8N-rdAT3WIKBNgaLcDp4YaSZXNQYhUp7icj1s5lEURSN4kQu29Wg0Q$ > , "version": "1.0.0", "extension_types": [ "property-extension" ] } ] } Notice the created_by_ref property. This is the id of a STIX identity object that DHS/CISA has chosen for itself. In this repository (NOT a STIX spec requirement) , the name property of the extension definition must correspond with the name of the json schema file (which we will discuss next), assuming there is a json schema for the extension. The schema property of that object contains a URL that refers to the directory that contains the json schema and documentation for the STIX representation of ACS data markings. These are stored in a different directory which is a sibling of the objects directory - extension-definition-specifications. Caution-https://github.com/oasis-open/cti-stix-common-objects/tree/adding-extensions/extension-definition-specifications/acs-data-markings < Caution-https://urldefense.com/v3/__https:/github.com/oasis-open/cti-stix-common-objects/tree/adding-extensions/extension-definition-specifications/acs-data-markings__;!!BhdT!y17I-LCzB3pA8N-rdAT3WIKBNgaLcDp4YaSZXNQYhUp7icj1s5lEURSN4kTwlBfobg$ > Note: these URLs are âliveâ so you can see what is being proposed, but they are not final, as they exist on a branch in the GitHub repository (for instance, in the final URLs âadding-extensionsâ would be replace by âmainâ) Since the name property of the extension definition is âisa-acs-3-0â, the json schema will be found in: Caution-https://github.com/oasis-open/cti-stix-common-objects/blob/adding-extensions/extension-definition-specifications/acs-data-markings/isa-acs-3-0.json < Caution-https://urldefense.com/v3/__https:/github.com/oasis-open/cti-stix-common-objects/blob/adding-extensions/extension-definition-specifications/acs-data-markings/isa-acs-3-0.json__;!!BhdT!y17I-LCzB3pA8N-rdAT3WIKBNgaLcDp4YaSZXNQYhUp7icj1s5lEURSN4kTU_3X8Jg$ > Documentation for this extension is provided in the same directory. It should be in the same style as the STIX specification. Using Word is suggested. If a JSON schema is included, another file is needed by the CTI STIX Validator. It must be named using the type of object that is being extended. For instance, since ACS data markings are an extension of the marking-definition type â the following file is needed: Caution-https://github.com/oasis-open/cti-stix-common-objects/blob/adding-extensions/extension-definition-specifications/acs-data-markings/marking-definition.json < Caution-https://urldefense.com/v3/__https:/github.com/oasis-open/cti-stix-common-objects/blob/adding-extensions/extension-definition-specifications/acs-data-markings/marking-definition.json__;!!BhdT!y17I-LCzB3pA8N-rdAT3WIKBNgaLcDp4YaSZXNQYhUp7icj1s5lEURSN4kQcG4GdpQ$ > View that file to understand the concept. Some details of the contents of this file still need to be worked out to specify extensions so they are easy to incorporate into the validator. Contributing Your Extension Assuming this proposal is acceptable, the following guidelines would be used to add new extension definitions to the repository.
Currently the maintainers of this repository are me and Chris Lenk (both of MITRE), but it would be preferable to have others from the TC involved. Rich P. -- Rich Piazza Lead Cyber Security Engineer The MITRE Corporation 781-271-3760 |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]