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: Re: [cti-taxii] Creating a more complex data-marking construct to support the needs of the secret squirrel community


Yes but in highly restricted sharing group the idea of knowing about each pieces of data shared and where it is going works GREAT with when the number of players is small, the data can be tied back to the people that released it easily, and the amount of volume is not massive.  

Fast forward to 2016-17 when we finish STIX 2.0 and TAXII 2.0 and we get a lot of vendors products integrated in to the mix.  We should also have threat exchanges/brokers that are taking feeds in from lots of different places, doing analysis on them, enriching them, and then sharing the results back out.  Further, lets push the number of indicators / observables up to over 100 Million a day and the number of active enterprise SOCs that are contributing (consuming / producing) to over 50 thousand.  

Thanks,

Bret



Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

On Nov 2, 2015, at 14:01, Terry MacDonald <terry@soltra.com> wrote:

Hi Mark,
 
It might be optimistic, but it’s what’s happening now. People are sharing properly marked text containing high value information over secure email right now. And that marked text is just using the simple TLP rules to ‘control’ it. Most secret squirrel sharing groups have the fight club rules – don’t talk about the sharing group. They have vouching requirements, where you have to be trusted by multiple parties in order to be allowed into the group.
 
And they have rules that say that if you share something when you are not allowed to, you will be banished from the group. And if you are banished from the group then those who vouched for you will also likely be restricted in some way.
 
In my experience, being held accountable for the actions of who you vouch for, and the threat of being kicked out if you are irresponsible drives good behavior.  In this way groups are able to effectively restrict the dissemination of information even through an uncontrolled medium such as email.
 
These same trustgroups *should* be able to enforce the same controls with STIX/TAXII as the medium – all we are doing is automating the process that is already done manually right now.
 
That said – I do know that there have been grumblings about the ability for people to describe their restrictions on their data quickly and succinctly. My understanding is that is what prompted the development of the Information Exchange Policy Framework (IEPF) I mentioned in an earlier post to the list.
 
I do believe that TLP has gotten us to where we are now, but producers of data need a slightly more descriptive (but not complex) way of describing what they are allowing to be done with their data.
 
Cheers
 
Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA | An FS-ISAC and DTCC Company
+61 (407) 203 206 | terry@soltra.com
 
 
From: Davidson II, Mark S [mailto:mdavidson@mitre.org] 
Sent: Tuesday, 3 November 2015 5:19 AM
To: Jordan, Bret <bret.jordan@bluecoat.com>; Patrick Maroney <Pmaroney@Specere.org>
Cc: Aharon Chernin <achernin@soltra.com>; cti@lists.oasis-open.org; Wunder, John A. <jwunder@mitre.org>; cti-taxii@lists.oasis-open.org; Terry MacDonald <terry@soltra.com>; Trey Darley <trey@soltra.com>
Subject: RE: [cti-taxii] Creating a more complex data-marking construct to support the needs of the secret squirrel community
 
I’d like to throw out a completely different set of ideas.
 
To me, the idea that I send a properly marked data object out into the wilderness and hope that any and all recipients will honor its markings is optimistic. Please prove me wrong, but I just don’t see how data markings can be reliably enforced in this manner – and I expect enforcement to be critical to creators of high value information.
 
I see the idea of owning a resource and controlling access to that resource as a desirable end run to the problem. Think of a (not yet invented) STIX Repository where I can post all my STIX Indicators and then individually allow/deny access to each requestor. Other people can reference them (e.g., idref), but cannot inline them in their content (if decide to go reference-only, this can be enforced technologically by the spec). Since I this scenario an org controls all access to their data, I hope many of the Data Marking use cases could be re-thought of as access controls on (for instance) a REST API.
 
Thoughts? Is this crazy talk? I realize it represents a bit of a shift from how we’ve thought about the problem, I hope that I have offered a simplification.
 
Thank you.
-Mark
 
From: cti-taxii@lists.oasis-open.org [mailto:cti-taxii@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Monday, November 02, 2015 12:16 PM
To: Patrick Maroney <Pmaroney@Specere.org>
Cc: Aharon Chernin <achernin@soltra.com>; cti@lists.oasis-open.org; Wunder, John A. <jwunder@mitre.org>; cti-taxii@lists.oasis-open.org; Terry MacDonald <terry@soltra.com>; Trey Darley <trey@soltra.com>
Subject: Re: [cti-taxii] Creating a more complex data-marking construct to support the needs of the secret squirrel community
 
I like how we are now working together to find a solution.  Lets just not let this thread die, lets run it to group and get a proposal on the table in the next week or so.  

 

Thanks,
 
Bret
 
 
 
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 
 
On Nov 2, 2015, at 10:59, Patrick Maroney <Pmaroney@Specere.org> wrote:
 
Aharon, 
 
[+1] On a Top Level Object Marking approach.  If combined with the Top Level Relationship Object, one could split/disseminate/secure/transport TLOs/Packages based on Sensitivity while still providing an easy mechanism to reassemble the aggregated intelligence as required for each recipient class. 
 
Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: (856)983-0001
Cell: (609)841-5104
Email: pmaroney@specere.org
 
_____________________________
From: Jordan, Bret <bret.jordan@bluecoat.com>
Sent: Monday, November 2, 2015 11:50 AM
Subject: Re: [cti-taxii] Creating a more complex data-marking construct to support the needs of the secret squirrel community
To: Aharon Chernin <achernin@soltra.com>
Cc: <cti@lists.oasis-open.org>, Wunder, John A. <jwunder@mitre.org>, <cti-taxii@lists.oasis-open.org>, Patrick Maroney <pmaroney@specere.org>, Terry MacDonald <terry@soltra.com>, Trey Darley <trey@soltra.com>


Well said Aharon...   

 

Thanks,
 
Bret
 
 
 
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 
 
On Nov 2, 2015, at 08:08, Aharon Chernin < achernin@soltra.com> wrote: 
 

My hope is that we can help the community move towards marking top level STIX objects at the object level. This is drastically easier to implement and comprehend than an XPATH statement. I plan to also take a look at package level marking in general, as STIX objects flowing over a network may not contain the original STIX Package header. 

We can try to make all communities happy by allowing both TLP marking of objects and Simple Marking of objects. 

Aharon 




On 11/2/15, 9:02 AM, " cti-taxii@lists.oasis-open.org on behalf of Wunder, John A." < cti-taxii@lists.oasis-open.org on behalf ofjwunder@mitre.org> wrote: 

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 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



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