And IEP is intended to fix at least some of the issues with TLP.
So if you wanted to start fixing things then suggest you look at IEP 2.0 and then provide comments to that.
Allan
From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Monday, July 22, 2019 at 6:06 AM
To: "Piazza, Rich" <rpiazza@mitre.org>
Cc: Chris O'Brien <chris@eclecticiq.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Re: [EXT] [cti] MarkingDefinition - TLP (amber/red) named distributions
My own POV;
RE "Iâm not proposing to try and âfix TLP"...
Actually, it sounds like you are :).
The CTI TC does not have the ability or mission to re-define what TLP means. I see this as binary: Either you want to use TLP as FIRST and US-CERT define it, which is purposefully very vague, or you want to use a more fine-grained and well defined marking -
which is fine and actually very encouraged - but that is not TLP. TLP is what it is.
I would suggest that some of the ideas below should be brought to FIRST to see if folks want to incorporate them into IEP.
-
Jason Keirstead
Chief Architect - IBM Security Threat Management
www.ibm.com/security
"Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure."
- Thomas J. Watson
From: "Piazza, Rich" <rpiazza@mitre.org>
To: Chris O'Brien <chris@eclecticiq.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 07/21/2019 08:32 PM
Subject: [EXTERNAL] [cti] Re: [EXT] [cti] MarkingDefinition - TLP (amber/red) named distributions
Sent by: <cti@lists.oasis-open.org>
Hi Chris,
I found your email very interesting. I think a lot of people on the committee have a very rudimentary understanding of TLP â and that is why we decided to define specific instances, which for efficiency purposes,
didnât need to be shared.
As far as discussing possible changes to TLP or the specification in general, you have sent your email to the right place. There are other avenues to discuss the specification â i.e., Slack, but this is a good starting
point. Adding an issue to
https://github.com/oasis-tcs/cti-stix2/issueswould also be useful.
As far as your options, I would be reticent to change the basic TLP markings as described in the specification. Off the top of my head, I could see a newly defined marking definition structure that uses TLP as a
reference. Something like this:
{
âtypeâ: âmarking_defintionâ,
â"id": "marking-definition--34098fce-860f-48ae-8e50-ebd3cc5e41da",
"created": "2019-08-01T00:00:00.000Z",
"definition_type": "TLP_Plus",
âdefinitionâ: {
âtlp_marking_def_refâ: "marking-definition--f88d31f6-486f-44da-b317-01333bde0b82",
ârestrictionsâ: âsome text or something more formalâ
}
}
Iâm sure others would have some very different approaches on how to represent this. However, I think any consideration of changing the TLP marking would be for the next release. But that is my opinion â any member
of the CTI committee is able to make proposals.
Rich
--
Rich Piazza
The MITRE Corporation
781-271-3760
From:
<cti@lists.oasis-open.org> on behalf of Chris O'Brien <chris@eclecticiq.com>
Date: Saturday, July 20, 2019 at 8:22 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [EXT] [cti] MarkingDefinition - TLP (amber/red) named distributions
Hi all,
Apologies if this has already been discussed. Please feel free to redirect me to appropriate literature but my own searching is unfruitful (apart from the discussions on whether to include descriptions and a mention
from Rich about working on different definitions for specific implementers).
So my question is on the TLP library that is documented in the latest WSD and shipped in the cti-python-stix api. The documentation clearly states:
The following standard marking definitions MUST be used to reference or represent TLP markings. Other instances of tlp-marking MUST NOT be used or created (the only instances of TLP marking definitions permitted
are those defined here).
Whilst I understand the reason for the restriction to start aligning users to a single common library, I donât think the defined object structure _coupled with_ the above allows users to effectively implement
a true TLP marking. Using the US-CERT websiteâs definition[1] of the protocol (for sake of âmost authoritativeâ I suppose) there is an inference that TLP AMBER (and RED, but will focus on 1 for sake of brevityâkinda) is not just an object-oriented marking
but also has certain contextual distribution filters applied based on the specific data being shared:
Recipients may only share TLP:AMBER information with members of their own organization, and with clients or customers who need to know the information to protect themselves or prevent further harm. Sources are
at liberty to specify additional intended limits of the sharing: these must be adhered to.
Ie: Based on the information you are sharing, certain identities can (or should) receive the data you are referencing, and some should not. As most of us on this committee are surely _painfully_ aware, this
often leads to overloading of TLP AMBER to mean different things in different situations and even multiple working groups who have attempted to create âsub categoriesâ for these TLPs. Personal experience with AMBER and RED is that, to make it effective, it
has to come with a distribution list of named recipients in order to be handled in the objectively âcorrectâ way. In truth, the existing TLP structure facilitates the old-school method of threat intelligence _sharing_ as opposed to threat intelligence
_collaboration_ - the former being more 1-to-1/many, and the latter being a many-to-many approach which requires more specific detail in the handling instruction to capture the implied rules of a sharing construct.
Iâm not proposing to try and âfix TLPâ, of course, but specifying these objects in the specification in such a way (ie: MUST NOT create new instances and only use the definitions as provided) prohibits users from
either extending the as-written objects or creating more usable (perhaps custom) marking objects for TLPâother than doing something weird like creating the âReady, set, goâ (RSG) protocol would beâbasically the same, but with support for named distributions
to support AMBER and RED (potentially allowing for some degree of data leak tracking which seems like a useful feature of a structured threat intel exchange language). I could see that as a simple extension of the existing definitions using a `distribution_refs`
field containing identity references â but thatâs by-the-by, not what Iâm specifically askingâ
So I guess there are 3 options that come to mind regarding how to manage the specified TLP marking definition approach for implementers who want to use TLP:
-
Do nothing, and with the as-is state people like myself would either have to get used to the limited existing TLP format
-
Do nothing and recognize that people will create obvious rip-offs of TLP that actually work for scalable threat intelligence collaboration
-
Would the committee be open to actively maintaining suggested up-versioning of the existing TLP library specifications to better support collaborative sharing of TLP marked data? If so, how does that process get handled? And who do I send my ideas to?
?
As an implementer â option 1 doesnât work for me. Since we are now publishing a âlibraryâ (however small), option 3 feels âcorrectâ.
Thoughts?
Chris
[1]
https://www.us-cert.gov/tlp