|
FWIW I wrote most of the profiles stuff and I agree with Bret.
Profiles are a good theory but (my caveat) as they work now (end caveat) they are not practical. I do think if we spent a little more time formalizing and standardizing some common set of profiles rather than everyone defining their own we could
get some value out of them.
John
Ok so assuming it's the case, Houston we have a problem http://stixproject.github.io/documentation/profiles/
With that said I would, personally, not rely on just tagging/data marking to do a DLP on Top S. data...
If there's a requirement for security, I would like it to be covered by the MTI, and that developers face it and find a way to implement it. I suggested something like this at least http://www.w3.org/TR/XAdES/But better appropriate solution should come from experts (and I am not)
On Friday, 6 November 2015, Jordan, Bret < bret.jordan@bluecoat.com> wrote:
Profiles are not a solution to this. They are great in ivory tower theory, but not in practical day-2-day use.
Bret
Sent from my Commodore 64
I think there is an overlap with the Profiles concept that has not been introduced here yet.
Also, regarding the IDs, information_source, producer, broker, trust communities... This leads again to the Organisation concept. (Which could be abstracted as the Asset concept)
On Friday, 6 November 2015, Jordan, Bret < bret.jordan@bluecoat.com> wrote:
In general I like the idea of doing marking at a package level or an object level. I really dislike the way it is done today. I would much rather have the marking be at the object I am reading and processing...
Think:
read.object.into.struct()
if object.has.special.marking {
} elsif {
}
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."
I should add: In the simplified Package Level Marking approach outlined in the previous message:
Consumers might need to decompose the STIX packages and apply the markings at the object level before commingling with their internal data representation models. This also highlights again why I (strongly) advocate inclusion of the following
Straw Man concepts.
(1) Object IDs [MUST be] constructed from one way hashes of [1] Namespace and [2] Object Value, with [3] an optional private seed parameter for input into the Hash Generation Method to prevent Brute Force Namespace determination attacks.
(2) CTI Standards Compliant
(2.1) Producers: [MUST] only Publish CTI Objects they originally source from direct observation or analysis under their Namespace.
(2.2) Aggregators: [MUST] pass unaltered original Object IDs UUIDs prefixed with their Namespaces
In other words, if I ensure as a CTI Standards Compliant content Producer that I don't publish anything under my NameSpace that I don't originally Source, then I don't need overly complicated internal atomic level data marking and controls.
If I'm an Aggregator, then I will need to implement atomic level data marking controls over any commingled intelligence as required to meet the specific data marking and handling policies and controls defined in my agreements with each original
CTI source (or upstream aggregator). Note that this only gets as complex as is required within my Communities of Trust.
For example:
(1) if I'm collecting, aggregating, correlating, and publishing Open Source "TLP White" [Public Domain, No Copyright/Licensing Restrictions], then I don't need any internal marking and control constructs.
(2) If I'm collecting, aggregating, correlating, and [POSSIBLY] publishing different levels of Classified, SBU, FOUO, LEO, Confidential, etc. CTI, then I will need very complex atomic level data marking and handling controls.
Patrick Maroney
President
Integrated Networking Technologies, Inc.
Office: (856)983-0001
Cell: (609)841-5104
Intelligence passed within a "Community of Trust" instantiation carries a de facto domain context (i.e., FS-ISAC) and controlling "TLP Policy" within that domain. The challenges come at the intersections of "Communities of Trust". This includes
"Spoke and Hub", "Meshed", "Point to Point" and potentially complex hybrid aggregations of these topologies.
While very much an implementation specific detail, the CTI standard should provide well defined constructs for mapping/transforming Data Marking and Handling policies at the Intersections of these domains. Ultimately it would be great if we
could apply DRM concepts and controls (including encryption, content expiration, etc.) to STIX Packages.
As an aside, I'm really liking the emerging concept of using Data Marking at the Package level and just sending multiple Packages (i.e., this package contains the TLP Green stuff, this package contains the TLP Amber stuff, and this package contains
the TLP Red stuff). I would then distribute the Green to the NCI (which would contain my mapping policy that NCI sends as TLP Amber to it's Member ISACs), the Orange to my ISAC, and the Red to other known Victims. The Packages and Objects within these individual
packages will include all of the RefIDs required to reassemble the pieces I have in my possession (including updates to same). In this model the mapping/transforming Data Marking and Handling policies are then applied at the Package level which makes this
simpler by orders of magnitude (V.s. Our discussions on how to manage this at the Object Level).
This would actually enable those interested in the direct application of existing DRM capabilities to these Packages, which just become another specialized form of a document with associated DRM policies.
_____________________________
From: Davidson II, Mark S < mdavidson@mitre.org>
Sent: Thursday, November 5, 2015 9:15 AM
Subject: RE: [cti-users] "Data Marking" syntaxes
To: Jason Keirstead < jason.keirstead@ca.ibm.com>, Collie, Byron S. < byron.collie@gs.com>
Cc: Camp, Warren (CTR) < warren.camp@associates.hq.dhs.gov>, < pam.smith@jhuapl.edu>, Michael Hammer < michael.hammer@yaanatech.com>,
< cti-users@lists.oasis-open.org>
For me, the concept of an organization is nebulous enough that it’s really hard for a software system to determine organizational membership without a very well curated
dataset or some other simplifying constraint(s). I believe that there are solutions that work well for their current case (as many on this list provide evidence for), but do those solutions also work in a fully automated, at-scale future? Partly I don’t know,
because partly I don’t know exactly what the future will look like.
The threat sharing vision today seems to include this idea that a blob of threat information can be properly marked, sent to property functioning threat sharing system(s),
and properly distributed throughout the threat sharing ecosystem, which depending on who you ask might include hundreds of to-be ISAOs. I have two pieces of evidence that suggest this might not work. The first is that I’m not aware of any existing technology
that works this way (if there is, we can just steal that and call it a day). The second is that, to the best of my knowledge (which I readily admit is incomplete), the implementations that I know about make simplifying assumptions that will not work for widespread
and automated threat sharing. Partly I make these assertions as a challenge – please show that I’m wrong and that we have a workable, scalable design.
@Byron, I’m also interested in how the TLP setup works for FS-ISAC. I’m anticipating a simplifying assumption (e.g., centrally managed credentials), but I hope there isn’t
one and that we can just leverage what’s already been invented.
I’ll also re-iterate my earlier suggestion for end-running the re-sharing problem. If information owners also perform access control instead of trusting the community
to do it for them, then I’m hoping that many of the marking uses can be simplified out of existence.
Thank you.
-Mark
@Byron, can you expound on this
"TLP AMBER to the FS-ISAC membership only. We do this all the time. "
If you are using a shared system for Threat Intelligence, how do you mark one piece of data as TLP Amber "For FS-ISAC Only" and then mark a different piece of data TLP Amber for Entity 2. This is my exact point.. there is no way to mark data as "TLP Amber For
FS-ISAC Only" today with STIX. You would have to run two different, independent repository systems to do something like that, and have most of your intelligence duplicated, along with all of the systems consuming the intelligence.
-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown
<image001.gif>"Collie, Byron S." ---2015/11/04 05:20:06 PM---Use Case 1: IE - Image the FS-ISAC peered with another entity, such as DHS or the EU or some other g
From: "Collie, Byron S." <Byron.Collie@gs.com>
To: "Camp, Warren (CTR)" <warren.camp@associates.hq.dhs.gov>, Michael
Hammer <michael.hammer@yaanatech.com>, "Pam.Smith@jhuapl.edu" <Pam.Smith@jhuapl.edu>,
Jason Keirstead/CanEast/IBM@IBMCA
Cc: "cti-users@lists.oasis-open.org" <cti-users@lists.oasis-open.org>
Date: 2015/11/04 05:20 PM
Subject: RE: [cti-users] "Data Marking" syntaxes
Sent by: <cti-users@lists.oasis-open.org>
Use Case 1: IE - Image the FS-ISAC peered with another entity, such as DHS or the EU or some other global entity, for threat sharing. Company A in FS-ISAC wants to share
an indicator and make it visible to FS-ISAC but not the other global entity. TLP does not allow one to do this. This problem with TLP is very bad and makes intra-organizational sharing impossible with TLP.
Ø TLP AMBER to the FS-ISAC membership only. We do this
all the time. Often times we may try and remove attribution to allow broader sharing with partners but if the submitting member says FS-ISAC only, we honor Originator Control, just the same as the Intel Community does.
Use Case 2: Image the FS-ISAC peered with another entity, such as DHS or the EU or some other global entity, for threat sharing. Company A in FS-ISAC wants to share an
indicator and make it visible to FS-ISAC but, when the information is shared globally, Company A wants (or does not want) anonymity.
Ø Currently anonymity is afforded through manual submission
on the FS-ISAC portal only. Automated anonymity is a bit harder to implement and still maintain some level of integrity around the source of the data.
Use Case 3: Company A shares an indicator with FS-ISAC with the restriction that FS-ISAC is allowed to share with members of FS-ISAC only. So when Company B (in the FS-ISAC) gets that indicator
from FS-ISAC, they aren't allowed to share it further. In this case, does Company A submit it as TLP Amber but the FS-ISAC ups the ante and changes it to TLP-Red before publishing to members of the FS-ISAC?
Ø TLP AMBER. TLP RED would mean no one not on the direct
communication could action it.
Use Case 4: Acme Indicators supplying indicators for profit to Company C. Company C is not allowed to do further sharing but is allowed to create and share, without restriction, any derivative
works.
Ø ACME > Company C TLP AMBER. The question is what is considered
a derivative work? The general understanding we have with most sources/organizations is, we can share any direct observations and information not considered proprietary under the ACME – Company C NDA. We also have contractual caveats to allow sharing with
law enforcement in response scenarios as well.
Use Case 5: Company A posts an indicator that is free to share, no restrictions, no anonymity required (Does TLP White as-is work for this?).
Ø TLP WHITE.
Use Case 6: Company A shares an indicator with Company B. No further sharing allowed with anyone. (Does TLP Red as-is work for this?)
Ø TLP AMBER.
Byron
From: Camp, Warren (CTR) [mailto:warren.camp@associates.hq.dhs.gov]
Sent: Wednesday, November 04, 2015 1:57 PM
To: Michael Hammer; Pam.Smith@jhuapl.edu; Jason.Keirstead@ca.ibm.com;
Collie, Byron S. [Tech]
Cc: cti-users@lists.oasis-open.org
Subject: RE: [cti-users] "Data Marking" syntaxes
Is the question concern TLP limitation more vertical or horizontal flexibility? That is do we need to drill down or have more refinement for a data category or have more data categories
or both.
Thank you,
Warren
From:cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On
Behalf Of Michael Hammer
Sent: Wednesday, November 04, 2015 1:43 PM
To: Pam.Smith@jhuapl.edu; Jason.Keirstead@ca.ibm.com; Byron.Collie@gs.com
Cc: cti-users@lists.oasis-open.org
Subject: RE: [cti-users] "Data Marking" syntaxes
In the list below, I am only seeing a single tag type and values.
This still begs the question of the possibility of multiple tags:
Owner: CTI (keep for all communities)
Indicator: Type X
Values: Red, Yellow, Green
Owner: Black Squirrels (remove when leaving community – not shared)
Indicator: Type X
Values: Red, Orange, Yellow, Chartreuse, Green, Blue, Indigo
So, some may be stripped or added at borders.
That might relieve the need to make changes at border, which might happen in any case.
________________________________
Michael Hammer
Principal Engineer
michael.hammer@yaanatech.com
Mobile: +1408
202 9291
542
Gibraltar Drive
Milpitas, CA 95035 USA
www.yaanatech.com
From:cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On
Behalf Of Smith, Pamela A.
Sent: Wednesday, November 04, 2015 12:11 PM
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>;
Collie, Byron S. <Byron.Collie@gs.com>
Cc: cti-users@lists.oasis-open.org
Subject: Re: [cti-users] "Data Marking" syntaxes
Building on Jason's example, maybe we can create a few key use cases and then prioritize needed elements in TLP++:
Use Case 1 (Jason's)
Use Case 2: Image the FS-ISAC peered with another entity, such as DHS or the EU or some other global entity, for threat sharing. Company A in FS-ISAC wants to share an
indicator and make it visible to FS-ISAC but, when the information is shared globally, Company A wants (or does not want) anonymity.
Use Case 3: Company A shares an indicator with FS-ISAC with the restriction that FS-ISAC is allowed to share with members of FS-ISAC only. So when Company B (in the FS-ISAC) gets that indicator
from FS-ISAC, they aren't allowed to share it further. In this case, does Company A submit it as TLP Amber but the FS-ISAC ups the ante and changes it to TLP-Red before publishing to members of the FS-ISAC?
Use Case 4: Acme Indicators supplying indicators for profit to Company C. Company C is not allowed to do further sharing but is allowed to create and share, without restriction, any derivative
works.
Use Case 5: Company A posts an indicator that is free to share, no restrictions, no anonymity required (Does TLP White as-is work for this?).
Use Case 6: Company A shares an indicator with Company B. No further sharing allowed with anyone. (Does TLP Red as-is work for this?)
Etc...
From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Sent: Wednesday, November 4, 2015 11:04 AM
To: Collie, Byron S.
Cc: Smith, Pamela A.; cti-users@lists.oasis-open.org
Subject: RE: [cti-users] "Data Marking" syntaxes
Here is the problem I have with TLP (I have outlined it a number of times) - TLP is not granular and has no definition for "Organization" and thus makes the intra-organizational
sharing paradigms we are trying to create very difficult
IE - Image the FS-ISAC peered with another entity, such as DHS or the EU or some other global entity, for threat sharing. Company A in FS-ISAC wants to share an indicator and make it visible to FS-ISAC but not the other global entity. TLP does not allow one
to do this. This problem with TLP is very bad and makes intra-organizational sharing impossible with TLP.
If we create a more robust and workable marking standard - it is not like this leaves TLP-required organizations up a creek without a paddle. The more robust standard could simply be "TLP ++" and if you want to ignore the other bits, then ignore them.
The main thing I would like to see from our marking is that when you say "TLP Green" that there is also a notion in the marking of *WHO* you are saying that about.
-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown
<image001.gif>"Collie, Byron S." ---2015/11/04 11:38:40 AM---Our internal platform implementation is tied to the Traffic Light Protocol
at its core. We then have
From: "Collie, Byron S." <Byron.Collie@gs.com>
To: Jason Keirstead/CanEast/IBM@IBMCA, "Smith, Pamela A." <Pam.Smith@jhuapl.edu>
Cc: "cti-users@lists.oasis-open.org"
<cti-users@lists.oasis-open.org>
Date: 2015/11/04 11:38 AM
Subject: RE: [cti-users] "Data Marking" syntaxes
Sent by: <cti-users@lists.oasis-open.org>
Our internal platform implementation is tied to the Traffic Light Protocol at its core. We then have other controls on top including Groups, Roles and some demographic data.
We implement FS-SAC and vendor proprietary feeds with a default of TLP AMBER. Public sourced information is generally tagged TLP GREEN depending on source.
We are not publishing automatically via STIX/TAXII as yet but would prefer to stick to the TLP Model https://en.wikipedia.org/wiki/Traffic_Light_Protocol given
a number of global information sharing organizations use it.
Cheers
Byron
From:cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On
Behalf Of Jason Keirstead
Sent: Wednesday, November 04, 2015 10:10 AM
To: Smith, Pamela A.
Cc: cti-users@lists.oasis-open.org
Subject: Re: [cti-users] "Data Marking" syntaxes
What if we came up with the idea, instead of having many different makings all independent, to have a marking standard, and allow trust groups to implement marking extensions?
What I would like to see is a baseline standard for marking that tools can implement.
If certain trust groups using internal toolsets want to go above that baseline, they are free to do so - but without some kind of a baseline, generic tool vendors that need to consider the whole market, have nothing to write code to, and there will be no interoperability
on markings between tools.
-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com
Without data, all you are is just another person with an opinion - Unknown
<image001.gif>"Smith, Pamela A." ---2015/11/04 11:03:21 AM---All, I'm skeptical that we can converge on a single marking approach, given the unique needs of each
From: "Smith, Pamela A." <Pam.Smith@jhuapl.edu>
To: "cti-users@lists.oasis-open.org"
<cti-users@lists.oasis-open.org>
Date: 2015/11/04 11:03 AM
Subject: Re: [cti-users] "Data Marking" syntaxes
Sent by: <cti-users@lists.oasis-open.org>
All,
I'm skeptical that we can converge on a single marking approach, given the unique needs of each sharing/trust community. We had a discussion on this topic last year via the STIX list-server. Yes, I know that proposing the use of multiple markings approaches
goes counter to the idea of a standard. But I think there will be trust communities where the usage/handling constraints are actually handled outside the markings perhaps in signed sharing agreements.
If we can consider the idea of different trust communities that operate independently, one of the most important things for a trust community to decide is how/if a member can broker to (send/receive) an external trust community. The ability to do that brokering
or filtering in real time is facilitated by unambiguous business rules either encoded in each shared document or documented/agreed-to out-of-band.
Main point here for those who want to develop an in-band marking structure: consider two types of markings: those used by a consumer directly and those used by a broker in making a decision on how/if to share outside a trust community.
If anyone is interested in additional features of community-to-community brokering, attached is a white paper I've been noodling over for a while dealing with that topic in general.
Pam Smith
JHU/APL Systems Engineer
From:cti-users@lists.oasis-open.org <cti-users@lists.oasis-open.org>
on behalf of Dave Cridland <dave@cridland.net>
Sent: Tuesday, November 3, 2015 4:39 AM
To: cti-users@lists.oasis-open.org
Cc: Jordan, Bret; trey@soltra.com
Subject: [cti-users] "Data Marking" syntaxes
Folks (and particularly Trey and Bret),
I was pointed at a discussion about security labelling on the main CTI list by a colleague at Surevine, and I'm mildly concerned that the CTI group may be reinventing security labelling and protective markings entirely anew. That's quite a big wheel, and I
have a nice round one right here.
TL;DR: https://github.com/surevine/spiffing/blob/master/FAQ.md
Firstly, the good news:
* There's been an existing model for handling security labelling in computer applications for a couple of decades, and the newest generation of that was published 16 years ago as SDN.801 Revision C. So this is as solved as a problem gets.
* While I've not yet got to a couple of bits, I and my employer published an MIT-licensed chunk of C++ for handling these a few months back. See https://github.com/surevine/Spiffing
* Policy files dictate how to present machine-readable labels, so in principle internationalization can be performed at the policy file (or SPIF) level.
* Policy files can also include information on how labels from *other* policies should be converted, and how to convert labels into other policies. So if different organizations want to have entirely different labelling schemes, this is fine.
* There's a dozen label formats, and although the oldest formats are ASN.1 schemas, there are XML ones too, and it'd be trivial to write a JSON one if you want.
* Clearances are also handled, so you can easily perform machine-level filtering of feeds, etc.
* These standards have been successfully implemented even in cases where only the server understands the policy, and the client-side doesn't, in XMPP and email. In XMPP for example, XEP-0258 describes a mechanism for marking XMPP messages whereby the clients
are unaware of policy or the label semantics, operating purely on text strings.
Now the not so good news:
* Because of the nature of the field, and the unaccountable desire of various national agencies from a number of countries to ensure they're paying way over the odds, much of the information is not publically available. An example is SDN.801 Revision C, which
is "specifically prohibited from posting on unrestricted electronic web sites", for example, or the NATO XML labelling format which is (I think) NATO CONFIDENTIAL.
* The knock-on effect of the above is that even though I can publish a liberally-licensed open-source library, I'm not allowed to support all formats, and I cannot even easily produce comprehensive documentation for it.
* There are way too many formats, and I've not implemented them all yet (even the public ones). Some of these, such as the US IC ISM XML syntax, are policy-specific, which means that organizations may struggle to fit their own policy in. This is especially
true if the policy doesn't use the "standard" classifications - true of, for example, the UK policy and the TLP (if modelled that way).
With all that in mind, while I'm entirely happy to answer questions, there is a limit to how much I can answer in public and without an NDA in place - this isn't down to me, I would much prefer if these documents and formats were all public.
Dave.[attachment "Cooperative Cyber Ecosystem - Functional Description.pdf" deleted by Jason Keirstead/CanEast/IBM]
This publicly archived list provides a forum for asking questions,
offering answers, and discussing topics of interest on STIX,
TAXII, and CybOX. Users and developers of solutions that leverage
STIX, TAXII and CybOX are invited to participate.
In order to verify user consent to OASIS mailing list guidelines
and to minimize spam in the list archive, subscription is required
before posting.
Subscribe: cti-users-subscribe@lists.oasis-open.org
Unsubscribe: cti-users-unsubscribe@lists.oasis-open.org
Post: cti-users@lists.oasis-open.org
List help: cti-users-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/cti-users/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
CTI Technical Committee: https://www.oasis-open.org/committees/cti/
Join OASIS: http://www.oasis-open.org/join/
<image001.gif>
This
publicly archived list provides a forum for asking questions,
offering
answers, and discussing topics of interest on STIX,
TAXII,
and CybOX. Users and developers of solutions that leverage
STIX,
TAXII and CybOX are invited to participate.
In
order to verify user consent to OASIS mailing list guidelines
and
to minimize spam in the list archive, subscription is required
before
posting.
Subscribe: cti-users-subscribe@lists.oasis-open.org
Unsubscribe: cti-users-unsubscribe@lists.oasis-open.org
Post: cti-users@lists.oasis-open.org
List
help: cti-users-help@lists.oasis-open.org
List
archive: http://lists.oasis-open.org/archives/cti-users/
List
Guidelines: http://www.oasis-open.org/maillists/guidelines.php
|