Re: [EXT] [cti] RE: Proposed STIX extension for TLP 2.0

[Rich Piazza <rpiazza@mitre.org>]

Hi Jeff,

 

Thanks for the response. Comments below in red.

 

ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ Rich

 

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of MATES, JEFFREY F GS-14 USAF AFOSI AFOSI/DC3/TSD <jeffrey.mates@us.af.mil>
Date: Friday, October 21, 2022 at 11:57 AM
To: Rich Piazza <rpiazza@mitre.org>, 'cti@lists.oasis-open.org' <cti@lists.oasis-open.org>
Subject: [EXT] [cti] RE: Proposed STIX extension for TLP 2.0

I agree with creating an extension for TLP 2.0 for this mapping, but a few minor items:

 

1. The JSON schema here appears to apply to the entire marking object and not just the extension itself.  My understanding is that property extension JSON schemas should just be for the extension to avoid conflicts.  That said given what it is overwriting / revising I can understand why this might make sense in this case.  

 

There needs to be best practices guide on how to write a JSON schema for an extension (Iâve started working on that). It should be a topic of discussion at one of the future working calls. ÂI have based my extension schemas on the current implementation of the OASIS-open STIX-validator, which will look in a directory given in the command line (or as an argument to its API) for a file with the name of the STIX object being extended to handle the extension. BTW â any extension is acceptable to the base JSON schemas â since the specification does not require a JSON schema be available.

 

Additionally, introducing a new marking-definition object type is tricky because it was already supported before extension definitions were included in the specification. I wanted to make sure that the TLP 2.0 schema didnât allow for the deprecated properties: definition and definition_type.

 

The Word document also appears to redescribe the entire object instead of just describing the property extension.  Iâm not 100% sure of which approach is best here but just food for thought.

 

Agreed, but I did it for the same reasons mentioned above.

 

2. I believe that the extension definition object in the Word document be placed into objects/extensions

 

Already there 😊

 

3. We might want to the pull request to also have the samples listed in objects/marking-definition to help with reuse of the same IDs

 

Is this in addition to the ones in the examples directory?

 

4. Once this gets merged should we add it to the best practices and then have a new vote for the additional best practice of using it for TLP 2?  This is how we had codified the Incident Core extension previously.

 

Yes - that makes sense. That brings up a more general issue â how to update the best practices guide.

 

//SIGNED//

 

Jeffrey Mates, Civ DC3/TSD

Computer Scientist

Technical Solutions Development

jeffrey.mates@us.af.mil

410-694-4335

 

From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Rich Piazza
Sent: Friday, October 21, 2022 11:30 AM
To: cti@lists.oasis-open.org
Subject: [URL Verdict: Neutral][Non-DoD Source] [cti] Proposed STIX extension for TLP 2.0

 

Hi All,

 

You are probably already aware of the new 2.0 version of TLP that has been released by FIRST (https://www.first.org/tlp/).  CISA has indicated that they intend to move to TLP 2.0 soon (https://www.cisa.gov/uscert/ncas/current-activity/2022/09/29/cisa-publishes-user-guide-prepare-nov-1-move-tlp-20).  For this reason, CISA asked MITRE to determine a way to represent TLP 2.0 in STIX 2.1.

 

The result can be reviewed in a GitHub pull request for the CTI STIX Common Object Repository (https://github.com/rpiazza/cti-stix-common-objects/tree/tlp-2-0/extension-definition-specifications/tlp-2.0).

 

To avoid confusion among the STIX community, we would like to merge this pull request and have the TC approve it as the canonical way to represent TLP 2.0.

 

After you review it, please reply with any suggestions or objections to this mailing list.

 

I have attached a note which contains reference information about this, if you want to see the reasoning behind the solution that is being proposed.

 

If there are no objections, we would like to merge the pull request on 1 November.

 

All the best,

 

                Rich

 

--

Rich Piazza

Lead Cyber Security Engineer

The MITRE Corporation

781-271-3760

ââââââââââââââââââââââââââââââââââââ

MITRE - Solving Problems for a Safer Worldâ

 

 

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature