OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Usage constraints (machine readable ones of course)

In the long winded thread about multi-langauge support one perhaps related issue comes to mind. We do not as of yet have any robust enumeration vocabulary  of what  are the allowed uses for CTI data in the ‘package'.  With respect to translation I fully anticipate somebody will desire to use automation to translate content from the source language into something useful for them. (We are build automation standards after all).   The notion of Traffic Light Protocol (TLP)alone does not deal with wishes of an originator of information as to what steps may be OK or not OK with enriching data such as translating it (or comparing against something like virus total).   So for example stating for a particular set of STIX objects that enrichment using public source is or is not permissible similar if external public translation service may or may not be utilized.  The reason for this is a desire to not tip information to an adversary in some circumstances. This is often expressed in email based sharing as “for research purposes only” or “passive measures only".  (There are many other usage restrictions so I am just focusing on the translation use case to raise the question)

Some communities handle this as an implication of their TLP process. TLP Red means you can’t share it and you can’t use “active” measures that are observable by an adversary including external enrichment.  IMHO TLP is more about re-distribution constraints  than what you can do with the information you have received, but who am I to tell a community how to construct a TLP in words. The issue is we have no CTI standards vocabulary to support those words with an instruction to downstream automation.

The problem I foresee is the machines will not know the social contract of the TLP unless it is actually instrumented in the data.  So somebody will code up automation to do this enrichment and then wind up running afoul of this rule (not external enrichment) as it wasn’t known to the plumbing as no control instruction was passed to the automation which in turn just went out and enriched the data. I know of one ISAC that has already chosen not to share ANY information with this kind of constraint due to a concern that usage constraint is unsupportable by their members. So there is no utility in the information shared from the reporting source to the ISAC as they won’t pass it onwards to their members. This is because there is not uniform way to describe what the heck this usage constraint  means that will survive  when cascaded from the ISAC through their member into the members security tool ecosystems. This is one of those issues we need to solve to move from human to human sharing towards infrastructure to infrastructure.

We so as near as I can tell have not broached this subject in depth.(If I missed it in the deluge of the CTI mailing list please correct me)

I see groups like FIRST address thing with their Information Exchange Policy working group. https://www.first.org/global/sigs/iep   I do not see us working on this.  

So back to my example of translation.  You could argue this is just a form of enrichment if I want to add a new translation based on content in another source language.  How do I know if I can use a public source like google/bing translate to get the gist of a descriptor in a language or if this is a prohibited constraint on the information if is not instrumented in the CTI data?  If it was TLP Red but in a language I don’t speak and can share it with somebody who does (probably not depending on the TLP Red group) or can I use an internal hosted automated translation tool? How do I know?

So the big question is should we address this in the TC or do we ‘outsource’ to another group like FIRST and then make some kind of extensions into STIX to utilize FIRST’s IEP? (or some other group working this problem solution set)

My $0.02 is this needs to be an integral part  of Oasis CTI standards “.next”.  Maybe it is after MVP, but if so not by much.


Mark Clancy
Chief Executive Officer
+1.813.470.2400 office +1.610.659.6671 US mobile |​  +44 7823 626 535  UK mobile
mclancy@soltra.com | soltra.com
Soltra Edge® The most widely used Threat Communications Platform in the world

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]