[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] RE: Usage constraints (machine readable ones of course)
My hope is that we do have something ready in time for STIX 2.0, as it would be the perfect time to change. We already have created an IEP example showing what a JSON version of the current draft of IEP would look like for exactly that reason...
Cheers
Terry MacDonald
Cosive
Mark,
My initial reaction is that this is a perfect opportunity to work with FIRST and their newly-formed Information Exchange Policy (IEP) SIG. Some of us that are FIRST members have already joined the SIG and I encourage others to do as well. My sense is that the IEP SIG will not be “done” with something we could bake into the STIX 2.0 MVP but as you said it is something we should be tracking and figuring out how to incorporate in a STIX 2.x release down the road.
Rich
From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Mark Clancy
Sent: Tuesday, April 26, 2016 9:57 PM
To: cti@lists.oasis-open.org
Subject: [cti] 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
Mark Clancy
Chief Executive Officer
SOLTRA® | An FS-ISAC and DTCC Company
+1.813.470.2400 office | +1.610.659.6671 US mobile | +44 7823 626 535 UK mobile
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]