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 |
From: Davidson II, Mark S [mailto:]
Sent: Tuesday, 3 November 2015 5:19 AM
To: Jordan, Bret <>; Patrick Maroney <>
Cc: Aharon Chernin <>; ; Wunder, John A. <>; ; Terry MacDonald <>; Trey Darley <>
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:
[mailto:]
On Behalf Of Jordan, Bret
Sent: Monday, November 02, 2015 12:16 PM
To: Patrick Maroney <>
Cc: Aharon Chernin <>;
; Wunder, John A. <>;
; Terry MacDonald <>; Trey Darley <>
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 <> 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:
_____________________________
From: Jordan, Bret <>
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 <>
Cc: <>, Wunder, John A. <>, <>, Patrick Maroney <>,
Terry MacDonald <>, Trey Darley <>
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 <
> 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, " on behalf of Wunder, John A." <
on behalf of
> 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 <
> 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
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
