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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-taxii message

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


Subject: Re: [cti-taxii] Creating a more complex data-marking construct to support the needs of the secret squirrel community


To be honest I’m not sure defining the actual marking statement is the hard part here. It’s allowing producers to mark things at the individual field level.

I remember an earlier conversation on the list when we talked about markings and a lot of suggestions were to have a set of markings (or marking IDs, whatever) on each of the top-level objects. So you could mark an indicator as TLP:RED by including that marking in the indicator. But, you couldn’t mark the indicator title as TLP:GREEN and the indicator description as TLP:RED.

In STIX 1.x we “solved" this by using XPath references to the data you wanted to mark. Pretty much everyone, including the people with the requirement to mark at the field level, hates this solution. In my mind, the key question on markings is whether we can come up with a better solution for doing that that’s usable for the people who want to simply mark top level objects as well as people who want to mark at the field level.

John

> On Nov 2, 2015, at 5:42 AM, Trey Darley <trey@soltra.com> wrote:
> 
> On 01.11.2015 02:26:23, Jordan, Bret wrote:
>> Do we really think it is realistic to build a data making
>> implementation that is actually going to work for the vastly
>> different solutions that the more advanced people need and still
>> have it be implementable in generic code? I can see some structured
>> and well defined parts working well. But completely free formed, do
>> anything, data making that "secret groups" use today is like trying
>> to boil the ocean in code.
>> 
> 
> [Note: changing thread subject and copying the top-level
> cti@oasis-open.org list, since this discussion cuts across domains]
> 
> Can we build a data-marking construct able to address *all* of the
> needs of the secret squirrel community? No, probably not. Can we make
> something close enough to support the data-marking needs of *most* of
> the secret squirrel community? Maybe, it's worth a try.
> 
> I've seen a lot of secret squirrel data-marking schemes. They
> generally look like:
> 
> SECRET SQUIRREL CLUB COSMIC TOP ACORN RELEASEABLE TO GREY SQUIRRELS, RED SQUIRRELS
> 
> The 'SECRET SQUIRREL CLUB' bit is a mandatory field identifying the
> community associated with the data-marking scheme.
> 
> The 'COSMIC TOP ACORN' bit is a mandatory field identifying the data
> confidentiality level. (This would be a controlled vocabulary
> enumerating the levels of confidentiality defined within the
> data-marking scheme.)
> 
> The RELEASEABLE bit is an optional field identifying the
> sub-communities within the community with who sharing is authorized.
> (This would be a controlled vocabulary enumerating the sub-communities
> defined within the data-marking scheme.)
> 
> What we *can't* do is codify the controlled vocabularies. These are
> going to vary widely across the secret squirrel community. But we
> *can* define an template construct into which each secret squirrel
> community can interpolate their specific controlled vocabularies. 
> 
> End result: a STIX data-marking scheme that should address the needs
> of *most* of these communities.
> 
> Things *do* get more complicated. For example, there might be
> localization issues between the German-speaking GREY SQUIRREL
> community and the Spanish-speaking RED SQUIRREL community. But I think
> we can build in an (optional) localization mapping element to address
> the possibility that various factions of the SECRET SQUIRREL CLUB
> might use different phraseology to indicate 'COSMIC TOP ACORN'.
> 
> Note that this is a strawman. Those within the OASIS CTI community
> better versed in such matters, feel free to elaborate.
> 
> -- 
> Cheers,
> Trey
> --
> Trey Darley
> Senior Security Engineer
> 4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
> Soltra | An FS-ISAC & DTCC Company
> www.soltra.com
> --
> "Every old idea will be proposed again with a different name and a
> different presentation, regardless of whether it works." --RFC 1925



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