Jason, I think it would be great to have that. I had posted some ideas for marking "primitives" in March and June. Extract from Jun below and the March discussion is attached. (sorry for that - not sure where the STIX discussions are archived)
===============================================================
Sent: Monday, June 15, 2015 2:45 PM
To: STIX-DISCUSSION-LIST@lists.mitre.org
Subject: RE: [STIX] STIX 1.2 Multiple Descriptions - JSON Options
To: STIX-DISCUSSION-LIST@lists.mitre.org
Subject: RE: [STIX] STIX 1.2 Multiple Descriptions - JSON Options
I’m wondering if it’s possible to define some marking primitives (i.e. a toolbox of markings) upon which we can build a more sophisticated marking structure as thinking and policies evolve/mature. [Also we
could recognize that some of these primitives (or anything built on top of them) might not be usable until infrastructure is built to support the rules/policies.]
For example, I’m seeing several marking topic areas in this discussion that could lend themselves to “marking primitives”:
- Stewardship and Provenance: how do we understand how this information came into being and, related, who is the steward (access control decision-maker?) of the information initially or over time/space?
- What kinds of access control decisions does a steward make
- Allowable actions with this info (e.g. you can’t use this to make money)
- Who is allowed to take what actions (analogy: the allowable action is the preposition and the object of the preposition is who is allowed to do it –or not). (example: Acme Indicators, Inc can’t make money from my shared info.)
- As a subset of “Allowable Actions”, two “allowable actions” deserve special discussion
§ Re-sharing (“Re-“ because the assumption is that the originator-steward doesn’t share the first
time unless they want to share with someone)
§ Stewardship change
· How long does the originator’s stewardship endure?
· Under what conditions does a steward relinquish their stewardship (e.g. if it’s anonymized,
it can be re-shared and someone else can become steward)
· If a steward relinquishes stewardship, what if any allowable actions restrictions are inherited
by the new steward and that the new steward needs to keep with the info? (e.g. Acme Indicators, Inc still can’t make money off of my information)
Sent: Monday, June 15, 2015 2:45 PM
To: STIX-DISCUSSION-LIST@lists.mitre.org
Subject: RE: [STIX] STIX 1.2 Multiple Descriptions - JSON Options
To: STIX-DISCUSSION-LIST@lists.mitre.org
Subject: RE: [STIX] STIX 1.2 Multiple Descriptions - JSON Options
I’m wondering if it’s possible to define some marking primitives (i.e. a toolbox of markings) upon which we can build a more sophisticated marking structure as thinking and policies evolve/mature. [Also we
could recognize that some of these primitives (or anything built on top of them) might not be usable until infrastructure is built to support the rules/policies.]
For example, I’m seeing several marking topic areas in this discussion that could lend themselves to “marking primitives”:
- Stewardship and Provenance: how do we understand how this information came into being and, related, who is the steward (access control decision-maker?) of the information initially or over time/space?
- What kinds of access control decisions does a steward make
- Allowable actions with this info (e.g. you can’t use this to make money)
- Who is allowed to take what actions (analogy: the allowable action is the preposition and the object of the preposition is who is allowed to do it –or not). (example: Acme Indicators, Inc can’t make money from my shared info.)
- As a subset of “Allowable Actions”, two “allowable actions” deserve special discussion
§ Re-sharing (“Re-“ because the assumption is that the originator-steward doesn’t share the first
time unless they want to share with someone)
§ Stewardship change
· How long does the originator’s stewardship endure?
· Under what conditions does a steward relinquish their stewardship (e.g. if it’s anonymized,
it can be re-shared and someone else can become steward)
· If a steward relinquishes stewardship, what if any allowable actions restrictions are inherited
by the new steward and that the new steward needs to keep with the info? (e.g. Acme Indicators, Inc still can’t make money off of my information)
From: cti-users@lists.oasis-open.org <cti-users@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Sent: Wednesday, November 4, 2015 10:09 AM
To: Smith, Pamela A.
Cc: cti-users@lists.oasis-open.org
Subject: Re: [cti-users] "Data Marking" syntaxes
Sent: Wednesday, November 4, 2015 10:09 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
"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/