[cti-users] "Data Marking" syntaxes

classic Classic list List threaded Threaded
52 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[cti-users] "Data Marking" syntaxes

Dave Cridland
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.


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.
Reply | Threaded
Open this post in threaded view
|

Re: [cti-users] "Data Marking" syntaxes

Smith, Pamela A.

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: [hidden email] <[hidden email]> on behalf of Dave Cridland <[hidden email]>
Sent: Tuesday, November 3, 2015 4:39 AM
To: [hidden email]
Cc: Jordan, Bret; [hidden email]
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.


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.


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: [hidden email]
Unsubscribe: [hidden email]
Post: [hidden email]
List help: [hidden email]
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/

Cooperative Cyber Ecosystem - Functional Description.pdf (384K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [cti-users] "Data Marking" syntaxes

Jason Keirstead

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


Inactive hide details for "Smith, Pamela A." ---2015/11/04 11:03:21 AM---All, I'm skeptical that we can converge on a single ma"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." <[hidden email]>
To: "[hidden email]" <[hidden email]>
Date: 2015/11/04 11:03 AM
Subject: Re: [cti-users] "Data Marking" syntaxes
Sent by: <[hidden email]>





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: [hidden email] <[hidden email]> on behalf of Dave Cridland <[hidden email]>
Sent:
Tuesday, November 3, 2015 4:39 AM
To:
[hidden email]
Cc:
Jordan, Bret; [hidden email]
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: [hidden email]
Unsubscribe: [hidden email]
Post: [hidden email]
List help: [hidden email]
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/


Reply | Threaded
Open this post in threaded view
|

RE: [cti-users] "Data Marking" syntaxes

Collie, Byron S.

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: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Keirstead
Sent: Wednesday, November 04, 2015 10:10 AM
To: Smith, Pamela A.
Cc: [hidden email]
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


Inactive hide details for "Smith, Pamela A." ---2015/11/04 11:03:21 AM---All, I'm skeptical that we can converge on a single ma"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." <[hidden email]>
To: "[hidden email]" <[hidden email]>
Date: 2015/11/04 11:03 AM
Subject: Re: [cti-users] "Data Marking" syntaxes
Sent by: <[hidden email]>





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: [hidden email] <[hidden email]> on behalf of Dave Cridland <[hidden email]>
Sent:
Tuesday, November 3, 2015 4:39 AM
To:
[hidden email]
Cc:
Jordan, Bret; [hidden email]
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: [hidden email]
Unsubscribe: [hidden email]
Post: [hidden email]
List help: [hidden email]
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/


Reply | Threaded
Open this post in threaded view
|

Re: [cti-users] "Data Marking" syntaxes

Smith, Pamela A.
In reply to this post by Jason Keirstead

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: [hidden email]
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: [hidden email]
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: [hidden email] <[hidden email]> on behalf of Jason Keirstead <[hidden email]>
Sent: Wednesday, November 4, 2015 10:09 AM
To: Smith, Pamela A.
Cc: [hidden email]
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


Inactive hide details for "Smith, Pamela A." ---2015/11/04 11:03:21 AM---All, I'm skeptical that we can converge on a single ma"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." <[hidden email]>
To: "[hidden email]" <[hidden email]>
Date: 2015/11/04 11:03 AM
Subject: Re: [cti-users] "Data Marking" syntaxes
Sent by: <[hidden email]>





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: [hidden email] <[hidden email]> on behalf of Dave Cridland <[hidden email]>
Sent:
Tuesday, November 3, 2015 4:39 AM
To:
[hidden email]
Cc:
Jordan, Bret; [hidden email]
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: [hidden email]
Unsubscribe: [hidden email]
Post: [hidden email]
List help: [hidden email]
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/




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: [hidden email]
Unsubscribe: [hidden email]
Post: [hidden email]
List help: [hidden email]
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/

STIX-DISCUSSION-MARCH-2015.pdf (107K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [cti-users] "Data Marking" syntaxes

Jordan, Bret
In reply to this post by Jason Keirstead
If we agree that we want different groups to communicate and share CTI, then we need to have at least a base line as Jason calls out so that tools can know what to do with it.  Free form blobs of data are impossible to code for and would guarantee that we will have zero interoperability.  If there is no interoperability then there is no need for STIX.


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 4, 2015, at 09:09, Jason Keirstead <[hidden email]> wrote:

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 


<graycol.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." <[hidden email]>
To:  "[hidden email]" <[hidden email]>
Date:  2015/11/04 11:03 AM
Subject:  Re: [cti-users] "Data Marking" syntaxes
Sent by:  <[hidden email]>





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: [hidden email] <[hidden email]> on behalf of Dave Cridland <[hidden email]>
Sent:
 Tuesday, November 3, 2015 4:39 AM
To:
 [hidden email]
Cc:
 Jordan, Bret; [hidden email]
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: [hidden email]
Unsubscribe: [hidden email]
Post: [hidden email]
List help: [hidden email]
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/


signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: [cti-users] "Data Marking" syntaxes

Jason Keirstead
In reply to this post by Collie, Byron S.

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


Inactive hide details for "Collie, Byron S." ---2015/11/04 11:38:40 AM---Our internal platform implementation is tied to the Tr"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." <[hidden email]>
To: Jason Keirstead/CanEast/IBM@IBMCA, "Smith, Pamela A." <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Date: 2015/11/04 11:38 AM
Subject: RE: [cti-users] "Data Marking" syntaxes
Sent by: <[hidden email]>





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: [hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
Wednesday, November 04, 2015 10:10 AM
To:
Smith, Pamela A.
Cc:
[hidden email]
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


Inactive hide details for "Smith, Pamela A." ---2015/11/04 11:03:21 AM---All, I'm skeptical that we can converge on a single ma"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." <[hidden email]>
To:
"[hidden email]" <[hidden email]>
Date:
2015/11/04 11:03 AM
Subject:
Re: [cti-users] "Data Marking" syntaxes
Sent by:
<[hidden email]>






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:
[hidden email] <[hidden email]> on behalf of Dave Cridland <[hidden email]>
Sent:
Tuesday, November 3, 2015 4:39 AM
To:
[hidden email]
Cc:
Jordan, Bret; [hidden email]
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:
[hidden email]
Unsubscribe:
[hidden email]
Post:
[hidden email]
List help:
[hidden email]
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/



Reply | Threaded
Open this post in threaded view
|

Re: [cti-users] "Data Marking" syntaxes

Smith, Pamela A.
In reply to this post by Collie, Byron S.

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 <[hidden email]>
Sent: Wednesday, November 4, 2015 11:04 AM
To: Collie, Byron S.
Cc: Smith, Pamela A.; [hidden email]
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


Inactive hide details for "Collie, Byron S." ---2015/11/04 11:38:40 AM---Our internal platform implementation is tied to the Tr"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." <[hidden email]>
To: Jason Keirstead/CanEast/IBM@IBMCA, "Smith, Pamela A." <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Date: 2015/11/04 11:38 AM
Subject: RE: [cti-users] "Data Marking" syntaxes
Sent by: <[hidden email]>





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: [hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
Wednesday, November 04, 2015 10:10 AM
To:
Smith, Pamela A.
Cc:
[hidden email]
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


Inactive hide details for "Smith, Pamela A." ---2015/11/04 11:03:21 AM---All, I'm skeptical that we can converge on a single ma"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." <[hidden email]>
To:
"[hidden email]" <[hidden email]>
Date:
2015/11/04 11:03 AM
Subject:
Re: [cti-users] "Data Marking" syntaxes
Sent by:
<[hidden email]>






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:
[hidden email] <[hidden email]> on behalf of Dave Cridland <[hidden email]>
Sent:
Tuesday, November 3, 2015 4:39 AM
To:
[hidden email]
Cc:
Jordan, Bret; [hidden email]
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:
[hidden email]
Unsubscribe:
[hidden email]
Post:
[hidden email]
List help:
[hidden email]
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/



Reply | Threaded
Open this post in threaded view
|

RE: [cti-users] "Data Marking" syntaxes

Michael Hammer

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

[hidden email]

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

www.yaanatech.com

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Smith, Pamela A.
Sent: Wednesday, November 04, 2015 12:11 PM
To: Jason Keirstead <[hidden email]>; Collie, Byron S. <[hidden email]>
Cc: [hidden email]
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 <[hidden email]>
Sent: Wednesday, November 4, 2015 11:04 AM
To: Collie, Byron S.
Cc: Smith, Pamela A.; [hidden email]
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


Inactive hide details for "Collie, Byron S." ---2015/11/04 11:38:40 AM---Our internal platform implementation is tied to the Tr
"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." <[hidden email]>
To: Jason Keirstead/CanEast/IBM@IBMCA, "Smith, Pamela A." <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Date: 2015/11/04 11:38 AM
Subject: RE: [cti-users] "Data Marking" syntaxes
Sent by: <[hidden email]>





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: [hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
Wednesday, November 04, 2015 10:10 AM
To:
Smith, Pamela A.
Cc:
[hidden email]
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


Inactive hide details for "Smith, Pamela A." ---2015/11/04 11:03:21 AM---All, I'm skeptical that we can converge on a single ma"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." <[hidden email]>
To:
"[hidden email]" <[hidden email]>
Date:
2015/11/04 11:03 AM
Subject:
Re: [cti-users] "Data Marking" syntaxes
Sent by:
<[hidden email]>






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:
[hidden email] <[hidden email]> on behalf of Dave Cridland <[hidden email]>
Sent:
Tuesday, November 3, 2015 4:39 AM
To:
[hidden email]
Cc:
Jordan, Bret; [hidden email]
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:
[hidden email]
Unsubscribe:
[hidden email]
Post:
[hidden email]
List help:
[hidden email]
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/



smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: [cti-users] "Data Marking" syntaxes

Camp, Warren (CTR)

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: [hidden email] [mailto:[hidden email]] On Behalf Of Michael Hammer
Sent: Wednesday, November 04, 2015 1:43 PM
To: [hidden email]; [hidden email]; [hidden email]
Cc: [hidden email]
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

[hidden email]

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

www.yaanatech.com

 

From: [hidden email] [[hidden email]] On Behalf Of Smith, Pamela A.
Sent: Wednesday, November 04, 2015 12:11 PM
To: Jason Keirstead <[hidden email]>; Collie, Byron S. <[hidden email]>
Cc: [hidden email]
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 <[hidden email]>
Sent: Wednesday, November 4, 2015 11:04 AM
To: Collie, Byron S.
Cc: Smith, Pamela A.; [hidden email]
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


Inactive hide details for "Collie, Byron S." ---2015/11/04 11:38:40 AM---Our internal platform implementation is tied to the Tr
"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." <[hidden email]>
To: Jason Keirstead/CanEast/IBM@IBMCA, "Smith, Pamela A." <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Date: 2015/11/04 11:38 AM
Subject: RE: [cti-users] "Data Marking" syntaxes
Sent by: <[hidden email]>





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: [hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
Wednesday, November 04, 2015 10:10 AM
To:
Smith, Pamela A.
Cc:
[hidden email]
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


Inactive hide details for "Smith, Pamela A." ---2015/11/04 11:03:21 AM---All, I'm skeptical that we can converge on a single ma"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." <[hidden email]>
To:
"[hidden email]" <[hidden email]>
Date:
2015/11/04 11:03 AM
Subject:
Re: [cti-users] "Data Marking" syntaxes
Sent by:
<[hidden email]>






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:
[hidden email] <[hidden email]> on behalf of Dave Cridland <[hidden email]>
Sent:
Tuesday, November 3, 2015 4:39 AM
To:
[hidden email]
Cc:
Jordan, Bret; [hidden email]
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:
[hidden email]
Unsubscribe:
[hidden email]
Post:
[hidden email]
List help:
[hidden email]
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/

Reply | Threaded
Open this post in threaded view
|

RE: [cti-users] "Data Marking" syntaxes

Collie, Byron S.

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:[hidden email]]
Sent: Wednesday, November 04, 2015 1:57 PM
To: Michael Hammer; [hidden email]; [hidden email]; Collie, Byron S. [Tech]
Cc: [hidden email]
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: [hidden email] [[hidden email]] On Behalf Of Michael Hammer
Sent: Wednesday, November 04, 2015 1:43 PM
To: [hidden email]; [hidden email]; [hidden email]
Cc: [hidden email]
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

[hidden email]

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

www.yaanatech.com

 

From: [hidden email] [[hidden email]] On Behalf Of Smith, Pamela A.
Sent: Wednesday, November 04, 2015 12:11 PM
To: Jason Keirstead <[hidden email]>; Collie, Byron S. <[hidden email]>
Cc: [hidden email]
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 <[hidden email]>
Sent: Wednesday, November 4, 2015 11:04 AM
To: Collie, Byron S.
Cc: Smith, Pamela A.; [hidden email]
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


Inactive hide details for "Collie, Byron S." ---2015/11/04 11:38:40 AM---Our internal platform implementation is tied to the Tr
"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." <[hidden email]>
To: Jason Keirstead/CanEast/IBM@IBMCA, "Smith, Pamela A." <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Date: 2015/11/04 11:38 AM
Subject: RE: [cti-users] "Data Marking" syntaxes
Sent by: <[hidden email]>





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: [hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
Wednesday, November 04, 2015 10:10 AM
To:
Smith, Pamela A.
Cc:
[hidden email]
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


Inactive hide details for "Smith, Pamela A." ---2015/11/04 11:03:21 AM---All, I'm skeptical that we can converge on a single ma"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." <[hidden email]>
To:
"[hidden email]" <[hidden email]>
Date:
2015/11/04 11:03 AM
Subject:
Re: [cti-users] "Data Marking" syntaxes
Sent by:
<[hidden email]>






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:
[hidden email] <[hidden email]> on behalf of Dave Cridland <[hidden email]>
Sent:
Tuesday, November 3, 2015 4:39 AM
To:
[hidden email]
Cc:
Jordan, Bret; [hidden email]
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:
[hidden email]
Unsubscribe:
[hidden email]
Post:
[hidden email]
List help:
[hidden email]
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/

Reply | Threaded
Open this post in threaded view
|

Re: [cti-users] "Data Marking" syntaxes

Dave Cridland
(To avoid this email being automatically filtered by crufty systems, classifications have been starred)

The usual solutions to these kinds of problems are one of:

1) Everyone uses a common core policy with their own extensions. Example: The UK's Government Classification Scheme defines the basic classification levels (OFFI***L, SE***T, TOP SE***T), and some additional caveats (or tags), such as SENSITIVE (applies only to OFFI***L), PERSONAL, etc. Different government agencies extend this with additional tags as required. These tags may be "lost in translation", or simplified into common tags.

2) A common policy is used in areas of cooperation, and existing labels are translated into this. NATO is an example of this; a UK SE***T marking becomes a NATO SE***T, which is then understood by any other nation.

3) Everyone uses their own policy internally, but there is a lingua-franca policy unused by anyone that is used as a translation layer - similar to Pam Smith's broker concept. Keen eyes may note this as a simple generalization of the above two concepts.

The translation is carried out by either party (either the sender translates, using "encrypt equivalence rules", or the reciever translates using "decrypt equivalence rules"). In either case, the rules are included as part of the Security Information Policy File, and can be quite complex (for a real example, translating UK OFFI***L SENSITIVE PERSONAL into NATO ends up as, I think, NATO CONFIDEN***L PERSONNEL, though given NATO security policy is itself NATO CONFIDEN***L it's hard to be sure).

Note that even in case (1) above, each actor is using their own policy - they simply have simpler translation rules. It's this simple case that I think is the right solution here, since every actor either knows, or can easily learn, the existing TLP markings, but I've no doubt that organizations like FS-ISAC will act like NATO does for militaries in this respect as well.

In some cases, organizations (and nations) prefer to maintain any foreign label and use it wherever possible (the UK does this, for example, in some cases), whereas other organization may prefer to always translate and use their native policy - the US has special classifications for foreign data as a result.

In the cases you outline, you'll note that TLP GREEN is unused, which is really quite interesting - it's a common problem with classification schemes that low-grade classifications tend to end up less commonly used. Part of the UK's redesign was to reduce this effect (though it hasn't worked very well). I think you'll need to add additional tags in order to usefully express the handling rules for data across FS-ISAC.

So for your cases, I would suggest that FS-ISAC maintains its own policy, probably using the TLP as classifications, with additional tags for which peers may see the data. As such, "TLP:GREEN" would mean "share throughout FS-ISAC and any peers", but "TLP:AMBER JURISDICTION:US" would prevent it being shared with EU members or partners. "TLP:AMBER JURISDICTION:US,EU" would allow it (but still nobody else). "TLP:AMBER JURISDICTION:US" would mean that US partners (not members, who presumably understand your policy) would only see "TLP:AMBER", and not share further.

In the interests of safety, a bare "TLP:AMBER" in the FS-ISAC policy would be invalid and rejected; instead we'd want to ensure users described what they meant with AMBER, and didn't leave it blank. Inbound TLP:AMBER would be marked up as "TLP:AMBER FS-ISAC" or some such to indicate no external sharing. (Security Policy Information Files also hold validation information as well as equivalent policy handling, so can express all this).

Adding an extra tag for anonymity is relatively straightforward (although it means a hardcoded tag instead of clearance attributes, which annoys me).

You'll note that this means a system in which almost every actor has a clearance up to TLP:RED; this isn't entirely unlike most intelligence communities where everyone is cleared to TOP SE***T.

A benefit to using SDN.801c model labels here is that there's plenty of COTS software that already handles these, including email gateways, IM servers, etc - so side-channel conversations can, in principle, be marked as well - but I'd expect that for external peers not aware of FS-ISAC's policy, we'd drop-down to a simple text label.

Finally, I'd note that this is, in case it's not already obvious, an area of great interest to me - if there's anyone who'd like to give me sets of use-cases like these I'm all ears, and happy to work in confidence as required (subject to any formal NDA being approved by Surevine). I'd similarly appreciate being able to run solutions past people for feedback.

Dave.

On 4 November 2015 at 21:19, Collie, Byron S. <[hidden email]> wrote:

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:[hidden email]]
Sent: Wednesday, November 04, 2015 1:57 PM
To: Michael Hammer; [hidden email]; [hidden email]; Collie, Byron S. [Tech]


Cc: [hidden email]
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: [hidden email] [[hidden email]] On Behalf Of Michael Hammer
Sent: Wednesday, November 04, 2015 1:43 PM
To: [hidden email]; [hidden email]; [hidden email]
Cc: [hidden email]
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

[hidden email]

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

www.yaanatech.com

 

From: [hidden email] [[hidden email]] On Behalf Of Smith, Pamela A.
Sent: Wednesday, November 04, 2015 12:11 PM
To: Jason Keirstead <[hidden email]>; Collie, Byron S. <[hidden email]>
Cc: [hidden email]
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 <[hidden email]>
Sent: Wednesday, November 4, 2015 11:04 AM
To: Collie, Byron S.
Cc: Smith, Pamela A.; [hidden email]
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


Inactive hide details for "Collie, Byron S." ---2015/11/04 11:38:40 AM---Our internal platform implementation is tied to the Tr
"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." <[hidden email]>
To: Jason Keirstead/CanEast/IBM@IBMCA, "Smith, Pamela A." <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Date: 2015/11/04 11:38 AM
Subject: RE: [cti-users] "Data Marking" syntaxes
Sent by: <[hidden email]>





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: [hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
Wednesday, November 04, 2015 10:10 AM
To:
Smith, Pamela A.
Cc:
[hidden email]
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


Inactive hide details for "Smith, Pamela A." ---2015/11/04 11:03:21 AM---All, I'm skeptical that we can converge on a single ma"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." <[hidden email]>
To:
"[hidden email]" <[hidden email]>
Date:
2015/11/04 11:03 AM
Subject:
Re: [cti-users] "Data Marking" syntaxes
Sent by:
<[hidden email]>






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:
[hidden email] <[hidden email]> on behalf of Dave Cridland <[hidden email]>
Sent:
Tuesday, November 3, 2015 4:39 AM
To:
[hidden email]
Cc:
Jordan, Bret; [hidden email]
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:
[hidden email]
Unsubscribe:
[hidden email]
Post:
[hidden email]
List help:
[hidden email]
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/


Reply | Threaded
Open this post in threaded view
|

RE: [cti-users] "Data Marking" syntaxes

Jason Keirstead
In reply to this post by Collie, Byron S.

@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


Inactive hide details for "Collie, Byron S." ---2015/11/04 05:20:06 PM---Use Case 1: IE - Image the FS-ISAC peered with another"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." <[hidden email]>
To: "Camp, Warren (CTR)" <[hidden email]>, Michael Hammer <[hidden email]>, "[hidden email]" <[hidden email]>, Jason Keirstead/CanEast/IBM@IBMCA
Cc: "[hidden email]" <[hidden email]>
Date: 2015/11/04 05:20 PM
Subject: RE: [cti-users] "Data Marking" syntaxes
Sent by: <[hidden email]>





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) [[hidden email]]
Sent:
Wednesday, November 04, 2015 1:57 PM
To:
Michael Hammer; [hidden email]; [hidden email]; Collie, Byron S. [Tech]
Cc:
[hidden email]
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: [hidden email] [[hidden email]] On Behalf Of Michael Hammer
Sent:
Wednesday, November 04, 2015 1:43 PM
To:
[hidden email]; [hidden email]; [hidden email]
Cc:
[hidden email]
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
[hidden email]
Mobile: +1 408 202 9291
542 Gibraltar Drive
Milpitas, CA 95035 USA
www.yaanatech.com

From: [hidden email] [[hidden email]] On Behalf Of Smith, Pamela A.
Sent:
Wednesday, November 04, 2015 12:11 PM
To:
Jason Keirstead <[hidden email]>; Collie, Byron S. <[hidden email]>
Cc:
[hidden email]
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 <[hidden email]>
Sent:
Wednesday, November 4, 2015 11:04 AM
To:
Collie, Byron S.
Cc:
Smith, Pamela A.; [hidden email]
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


Inactive hide details for "Collie, Byron S." ---2015/11/04 11:38:40 AM---Our internal platform implementation is tied to the Tr"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." <[hidden email]>
To:
Jason Keirstead/CanEast/IBM@IBMCA, "Smith, Pamela A." <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>
Date:
2015/11/04 11:38 AM
Subject:
RE: [cti-users] "Data Marking" syntaxes
Sent by:
<[hidden email]>





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:
[hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
Wednesday, November 04, 2015 10:10 AM
To:
Smith, Pamela A.
Cc:
[hidden email]
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


Inactive hide details for "Smith, Pamela A." ---2015/11/04 11:03:21 AM---All, I'm skeptical that we can converge on a single ma"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." <[hidden email]>
To:
"[hidden email]" <[hidden email]>
Date:
2015/11/04 11:03 AM
Subject:
Re: [cti-users] "Data Marking" syntaxes
Sent by:
<[hidden email]>






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:
[hidden email] <[hidden email]> on behalf of Dave Cridland <[hidden email]>
Sent:
Tuesday, November 3, 2015 4:39 AM
To:
[hidden email]
Cc:
Jordan, Bret; [hidden email]
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:
[hidden email]
Unsubscribe:
[hidden email]
Post:
[hidden email]
List help:
[hidden email]
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/


Reply | Threaded
Open this post in threaded view
|

RE: [cti-users] "Data Marking" syntaxes

mdavidson

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

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Keirstead
Sent: Thursday, November 05, 2015 8:43 AM
To: Collie, Byron S. <[hidden email]>
Cc: Camp, Warren (CTR) <[hidden email]>; Michael Hammer <[hidden email]>; [hidden email]; [hidden email]
Subject: RE: [cti-users] "Data Marking" syntaxes

 

@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


Inactive hide details for "Collie, Byron S." ---2015/11/04 05:20:06 PM---Use Case 1: IE - Image the FS-ISAC peered with another"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." <[hidden email]>
To: "Camp, Warren (CTR)" <[hidden email]>, Michael Hammer <[hidden email]>, "[hidden email]" <[hidden email]>, Jason Keirstead/CanEast/IBM@IBMCA
Cc: "[hidden email]" <[hidden email]>
Date: 2015/11/04 05:20 PM
Subject: RE: [cti-users] "Data Marking" syntaxes
Sent by: <[hidden email]>





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) [[hidden email]]
Sent:
Wednesday, November 04, 2015 1:57 PM
To:
Michael Hammer; [hidden email]; [hidden email]; Collie, Byron S. [Tech]
Cc:
[hidden email]
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: [hidden email] [[hidden email]] On Behalf Of Michael Hammer
Sent:
Wednesday, November 04, 2015 1:43 PM
To:
[hidden email]; [hidden email]; [hidden email]
Cc:
[hidden email]
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
[hidden email]
Mobile: +1 408 202 9291
542 Gibraltar Drive
Milpitas, CA 95035 USA
www.yaanatech.com

From: [hidden email] [[hidden email]] On Behalf Of Smith, Pamela A.
Sent:
Wednesday, November 04, 2015 12:11 PM
To:
Jason Keirstead <
[hidden email]>; Collie, Byron S. <[hidden email]>
Cc:
[hidden email]
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 <[hidden email]>
Sent:
Wednesday, November 4, 2015 11:04 AM
To:
Collie, Byron S.
Cc:
Smith, Pamela A.;
[hidden email]
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


Inactive hide details for "Collie, Byron S." ---2015/11/04 11:38:40 AM---Our internal platform implementation is tied to the Tr"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." <[hidden email]>
To:
Jason Keirstead/CanEast/IBM@IBMCA, "Smith, Pamela A." <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>
Date:
2015/11/04 11:38 AM
Subject:
RE: [cti-users] "Data Marking" syntaxes
Sent by:
<[hidden email]>






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:
[hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
Wednesday, November 04, 2015 10:10 AM
To:
Smith, Pamela A.
Cc:
[hidden email]
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


Inactive hide details for "Smith, Pamela A." ---2015/11/04 11:03:21 AM---All, I'm skeptical that we can converge on a single ma"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." <[hidden email]>
To:
"[hidden email]" <[hidden email]>
Date:
2015/11/04 11:03 AM
Subject:
Re: [cti-users] "Data Marking" syntaxes
Sent by:
<[hidden email]>







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:
[hidden email] <[hidden email]> on behalf of Dave Cridland <[hidden email]>
Sent:
Tuesday, November 3, 2015 4:39 AM
To:
[hidden email]
Cc:
Jordan, Bret; [hidden email]
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:
[hidden email]
Unsubscribe:
[hidden email]
Post:
[hidden email]
List help:
[hidden email]
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/

Reply | Threaded
Open this post in threaded view
|

RE: [cti-users] "Data Marking" syntaxes

Jason Keirstead

I do not believe the marking has to know or care about the organizational membership. What matters is that the marking can contain a reference to it, so that software can dereference it if required.

It is easier to use examples - this is the current TLP marking:

          <stix:Handling>
          <marking:Marking>
          <marking:Controlled_Structure>//node() | //@*</marking:Controlled_Structure>
          <marking:Marking_Structure xsi:type="tlp:TLPMarkingStructureType" tlp:color="AMBER" />
          </marking:Marking>
          </stix:Handling>

What is required is something akin to this, where I can mark one piece of data with multiple different controls based on target
          <stix:Handling>
          <marking:Marking>
          <marking:Controlled_Structure>//node() | //@*</marking:Controlled_Structure>
          <marking:Marking_Structure xsi:type="tlp_plus:TLPPlusMarkingStructureType" tlp:color="RED" tlp:target="//fs-isac.com" />
          </marking:Marking>
          <marking:Marking>
          <marking:Controlled_Structure>//node() | //@*</marking:Controlled_Structure>
          <marking:Marking_Structure xsi:type="tlp_plus:TLPPlusMarkingStructureType" tlp:color="AMBER" tlp:target="//dhs.gov" />
          </marking:Marking>
          <marking:Marking>
          <marking:Controlled_Structure>//node() | //@*</marking:Controlled_Structure>
          <marking:Marking_Structure xsi:type="tlp_plus:TLPPlusMarkingStructureType" tlp:color="AMBER" tlp:target="//mycompany.com" />
          </marking:Marking>
          </stix:Handling>

As others pointed out in the past - it's up to the consuming software implementation and/or humans to decide to enforce or not enforce the marking, so we don't need to worry about STIX caring about who belongs to an organization.

The important part is that the marking can contain the orgnization at all - today, with TLP, it can not.


-
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


Inactive hide details for "Davidson II, Mark S" ---2015/11/05 10:14:45 AM---For me, the concept of an organization is nebulous "Davidson II, Mark S" ---2015/11/05 10:14:45 AM---For me, the concept of an organization is nebulous enough that it’s really hard for a software syste

From: "Davidson II, Mark S" <[hidden email]>
To: Jason Keirstead/CanEast/IBM@IBMCA, "Collie, Byron S." <[hidden email]>
Cc: "Camp, Warren (CTR)" <[hidden email]>, Michael Hammer <[hidden email]>, "[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>
Date: 2015/11/05 10:14 AM
Subject: RE: [cti-users] "Data Marking" syntaxes




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
      From: [hidden email] [[hidden email]] On Behalf Of Jason Keirstead
      Sent:
      Thursday, November 05, 2015 8:43 AM
      To:
      Collie, Byron S. <[hidden email]>
      Cc:
      Camp, Warren (CTR) <[hidden email]>; Michael Hammer <[hidden email]>; [hidden email]; [hidden email]
      Subject:
      RE: [cti-users] "Data Marking" syntaxes

      @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


      Inactive hide details for "Collie, Byron S." ---2015/11/04 05:20:06 PM---Use Case 1: IE - Image the FS-ISAC peered with another"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." <[hidden email]>
      To:
      "Camp, Warren (CTR)" <[hidden email]>, Michael Hammer <[hidden email]>, "[hidden email]" <[hidden email]>, Jason Keirstead/CanEast/IBM@IBMCA
      Cc:
      "[hidden email]" <[hidden email]>
      Date:
      2015/11/04 05:20 PM
      Subject:
      RE: [cti-users] "Data Marking" syntaxes
      Sent by:
      <[hidden email]>






      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) [[hidden email]]
      Sent:
      Wednesday, November 04, 2015 1:57 PM
      To:
      Michael Hammer; [hidden email]; [hidden email]; Collie, Byron S. [Tech]
      Cc:
      [hidden email]
      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:
      [hidden email] [[hidden email]] On Behalf Of Michael Hammer
      Sent:
      Wednesday, November 04, 2015 1:43 PM
      To:
      [hidden email]; [hidden email]; [hidden email]
      Cc:
      [hidden email]
      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

      [hidden email]
      Mobile:
      +1 408 202 9291
      542 Gibraltar Drive
      Milpitas, CA 95035 USA

      www.yaanatech.com

      From:
      [hidden email] [[hidden email]] On Behalf Of Smith, Pamela A.
      Sent:
      Wednesday, November 04, 2015 12:11 PM
      To:
      Jason Keirstead <[hidden email]>; Collie, Byron S. <[hidden email]>
      Cc:
      [hidden email]
      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 <[hidden email]>
      Sent:
      Wednesday, November 4, 2015 11:04 AM
      To:
      Collie, Byron S.
      Cc:
      Smith, Pamela A.; [hidden email]
      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


      Inactive hide details for "Collie, Byron S." ---2015/11/04 11:38:40 AM---Our internal platform implementation is tied to the Tr"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." <[hidden email]>
      To:
      Jason Keirstead/CanEast/IBM@IBMCA, "Smith, Pamela A." <[hidden email]>
      Cc:
      "[hidden email]" <[hidden email]>
      Date:
      2015/11/04 11:38 AM
      Subject:
      RE: [cti-users] "Data Marking" syntaxes
      Sent by:
      <[hidden email]>






      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:
      [hidden email] [[hidden email]] On Behalf Of Jason Keirstead
      Sent:
      Wednesday, November 04, 2015 10:10 AM
      To:
      Smith, Pamela A.
      Cc:
      [hidden email]
      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


      Inactive hide details for "Smith, Pamela A." ---2015/11/04 11:03:21 AM---All, I'm skeptical that we can converge on a single ma"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." <[hidden email]>
      To:
      "[hidden email]" <[hidden email]>
      Date:
      2015/11/04 11:03 AM
      Subject:
      Re: [cti-users] "Data Marking" syntaxes
      Sent by:
      <[hidden email]>







      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:
      [hidden email] <[hidden email]> on behalf of Dave Cridland <[hidden email]>
      Sent:
      Tuesday, November 3, 2015 4:39 AM
      To:
      [hidden email]
      Cc:
      Jordan, Bret; [hidden email]
      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:
      [hidden email]
      Unsubscribe:
      [hidden email]
      Post:
      [hidden email]
      List help:
      [hidden email]
      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/



Reply | Threaded
Open this post in threaded view
|

Re: [cti-users] "Data Marking" syntaxes

Dave Cridland
In reply to this post by mdavidson
Fully automated is relatively easy - labels and clearances are evaluated in realtime in both email and XMPP systems deployed across and between governments and militaries, including in theatre. At scale is harder to pinpoint, because we don't know what you may mean by that - but I think I can get software to handle the ACDF from raw data in the order of 100k operations per second per core without too much effort. I can do 10k per second per core now, without any of the easy optimizations. So can you of course - the code is free for use after all.

The existing systems do require that all participants have some policy which can express those attributes of each policy which are required in order to share the data.

That's an awful sentence, so let me explain:

I may have a number of controls and caveats I want to mark data with; for example jurisdictional, how it might be displayed, whether it's actionable data, and so on. Some of these are really an internal issue to my group, and simply don't make sense outside of it. Others - jurisdiction, for example - might be important for me to express to partners.

If your policy cannot express a jurisdictional restriction (or I do not know how to do it), then I cannot share jurisdictionally-restricted information with you.

On the other hand, if there's a lingua-franca policy (say a TLP++ which has such things in) then translating from that to your internal policy is something I can trust you to do (assuming you've signed up to it).



On 5 November 2015 at 14:14, Davidson II, Mark S <[hidden email]> wrote:

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

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Keirstead
Sent: Thursday, November 05, 2015 8:43 AM
To: Collie, Byron S. <[hidden email]>
Cc: Camp, Warren (CTR) <[hidden email]>; Michael Hammer <[hidden email]>; [hidden email]; [hidden email]


Subject: RE: [cti-users] "Data Marking" syntaxes

 

@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


Inactive hide details for "Collie, Byron S." ---2015/11/04 05:20:06 PM---Use Case 1: IE - Image the FS-ISAC peered with another"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." <[hidden email]>
To: "Camp, Warren (CTR)" <[hidden email]>, Michael Hammer <[hidden email]>, "[hidden email]" <[hidden email]>, Jason Keirstead/CanEast/IBM@IBMCA
Cc: "[hidden email]" <[hidden email]>
Date: 2015/11/04 05:20 PM
Subject: RE: [cti-users] "Data Marking" syntaxes
Sent by: <[hidden email]>





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) [[hidden email]]
Sent:
Wednesday, November 04, 2015 1:57 PM
To:
Michael Hammer; [hidden email]; [hidden email]; Collie, Byron S. [Tech]
Cc:
[hidden email]
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: [hidden email] [[hidden email]] On Behalf Of Michael Hammer
Sent:
Wednesday, November 04, 2015 1:43 PM
To:
[hidden email]; [hidden email]; [hidden email]
Cc:
[hidden email]
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
[hidden email]
Mobile: +1 408 202 9291
542 Gibraltar Drive
Milpitas, CA 95035 USA
www.yaanatech.com

From: [hidden email] [[hidden email]] On Behalf Of Smith, Pamela A.
Sent:
Wednesday, November 04, 2015 12:11 PM
To:
Jason Keirstead <
[hidden email]>; Collie, Byron S. <[hidden email]>
Cc:
[hidden email]
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 <[hidden email]>
Sent:
Wednesday, November 4, 2015 11:04 AM
To:
Collie, Byron S.
Cc:
Smith, Pamela A.;
[hidden email]
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


Inactive hide details for "Collie, Byron S." ---2015/11/04 11:38:40 AM---Our internal platform implementation is tied to the Tr"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." <[hidden email]>
To:
Jason Keirstead/CanEast/IBM@IBMCA, "Smith, Pamela A." <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>
Date:
2015/11/04 11:38 AM
Subject:
RE: [cti-users] "Data Marking" syntaxes
Sent by:
<[hidden email]>






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:
[hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
Wednesday, November 04, 2015 10:10 AM
To:
Smith, Pamela A.
Cc:
[hidden email]
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


Inactive hide details for "Smith, Pamela A." ---2015/11/04 11:03:21 AM---All, I'm skeptical that we can converge on a single ma"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." <[hidden email]>
To:
"[hidden email]" <[hidden email]>
Date:
2015/11/04 11:03 AM
Subject:
Re: [cti-users] "Data Marking" syntaxes
Sent by:
<[hidden email]>







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:
[hidden email] <[hidden email]> on behalf of Dave Cridland <[hidden email]>
Sent:
Tuesday, November 3, 2015 4:39 AM
To:
[hidden email]
Cc:
Jordan, Bret; [hidden email]
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:
[hidden email]
Unsubscribe:
[hidden email]
Post:
[hidden email]
List help:
[hidden email]
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/


Reply | Threaded
Open this post in threaded view
|

RE: [cti-users] "Data Marking" syntaxes

pmaroney
In reply to this post by mdavidson
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.

Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: <a dir="ltr" href="tel:(856)983-0001" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="0/1"> (856)983-0001
Cell: <a dir="ltr" href="tel:(609)841-5104" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="0/2"> (609)841-5104
Email: [hidden email]

_____________________________
From: Davidson II, Mark S <[hidden email]>
Sent: Thursday, November 5, 2015 9:15 AM
Subject: RE: [cti-users] "Data Marking" syntaxes
To: Jason Keirstead <[hidden email]>, Collie, Byron S. <[hidden email]>
Cc: Camp, Warren (CTR) <[hidden email]>, <[hidden email]>, Michael Hammer <[hidden email]>, <[hidden email]>


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

 

From: [hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent: Thursday, November 05, 2015 8:43 AM
To: Collie, Byron S. <[hidden email]>
Cc: Camp, Warren (CTR) <[hidden email]>; Michael Hammer <[hidden email]>; [hidden email]; [hidden email]
Subject: RE: [cti-users] "Data Marking" syntaxes

 

@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


Inactive hide details for "Collie, Byron S." ---2015/11/04 05:20:06 PM---Use Case 1: IE - Image the FS-ISAC peered with another"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." <[hidden email]>
To: "Camp, Warren (CTR)" <[hidden email]>, Michael Hammer <[hidden email]>, "[hidden email]" <[hidden email]>, Jason Keirstead/CanEast/IBM@IBMCA
Cc: "[hidden email]" <[hidden email]>
Date: 2015/11/04 05:20 PM
Subject: RE: [cti-users] "Data Marking" syntaxes
Sent by: <[hidden email]>





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) [[hidden email]]
Sent:
Wednesday, November 04, 2015 1:57 PM
To:
Michael Hammer; [hidden email]; [hidden email]; Collie, Byron S. [Tech]
Cc:
[hidden email]
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: [hidden email] [[hidden email]] On Behalf Of Michael Hammer
Sent:
Wednesday, November 04, 2015 1:43 PM
To:
[hidden email]; [hidden email]; [hidden email]
Cc:
[hidden email]
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
[hidden email]
Mobile: <a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2">+1 <a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2">408 202 9291
<a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3">542 Gibraltar Drive
<a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3">Milpitas, CA 95035 USA
www.yaanatech.com

From: [hidden email] [[hidden email]] On Behalf Of Smith, Pamela A.
Sent:
Wednesday, November 04, 2015 12:11 PM
To:
Jason Keirstead <
[hidden email]>; Collie, Byron S. <[hidden email]>
Cc:
[hidden email]
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 <[hidden email]>
Sent:
Wednesday, November 4, 2015 11:04 AM
To:
Collie, Byron S.
Cc:
Smith, Pamela A.;
[hidden email]
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


Inactive hide details for "Collie, Byron S." ---2015/11/04 11:38:40 AM---Our internal platform implementation is tied to the Tr"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." <[hidden email]>
To:
Jason Keirstead/CanEast/IBM@IBMCA, "Smith, Pamela A." <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>
Date:
2015/11/04 11:38 AM
Subject:
RE: [cti-users] "Data Marking" syntaxes
Sent by:
<[hidden email]>






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:
[hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
Wednesday, November 04, 2015 10:10 AM
To:
Smith, Pamela A.
Cc:
[hidden email]
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


Inactive hide details for "Smith, Pamela A." ---2015/11/04 11:03:21 AM---All, I'm skeptical that we can converge on a single ma"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." <[hidden email]>
To:
"[hidden email]" <[hidden email]>
Date:
2015/11/04 11:03 AM
Subject:
Re: [cti-users] "Data Marking" syntaxes
Sent by:
<[hidden email]>







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:
[hidden email] <[hidden email]> on behalf of Dave Cridland <[hidden email]>
Sent:
Tuesday, November 3, 2015 4:39 AM
To:
[hidden email]
Cc:
Jordan, Bret; [hidden email]
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:
[hidden email]
Unsubscribe:
[hidden email]
Post:
[hidden email]
List help:
[hidden email]
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/



Reply | Threaded
Open this post in threaded view
|

Re: [cti-users] "Data Marking" syntaxes

pmaroney
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

From: <[hidden email]> on behalf of Patrick Maroney <[hidden email]>
Date: Thursday, November 5, 2015 at 10:02 AM
To: Mark Davidson <[hidden email]>, Jason Keirstead <[hidden email]>, Byron Collie <[hidden email]>
Cc: "Camp, Warren (CTR)" <[hidden email]>, Pamela Smith <[hidden email]>, Michael Hammer <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: RE: [cti-users] "Data Marking" syntaxes

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.

Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: <a dir="ltr" href="tel:(856)983-0001" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="0/1"> (856)983-0001
Cell: <a dir="ltr" href="tel:(609)841-5104" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="0/2"> (609)841-5104
Email: [hidden email]

_____________________________
From: Davidson II, Mark S <[hidden email]>
Sent: Thursday, November 5, 2015 9:15 AM
Subject: RE: [cti-users] "Data Marking" syntaxes
To: Jason Keirstead <[hidden email]>, Collie, Byron S. <[hidden email]>
Cc: Camp, Warren (CTR) <[hidden email]>, <[hidden email]>, Michael Hammer <[hidden email]>, <[hidden email]>


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

 

From:[hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent: Thursday, November 05, 2015 8:43 AM
To: Collie, Byron S. <[hidden email]>
Cc: Camp, Warren (CTR) <[hidden email]>; Michael Hammer <[hidden email]>; [hidden email]; [hidden email]
Subject: RE: [cti-users] "Data Marking" syntaxes

 

@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


Inactive hide details for "Collie, Byron S." ---2015/11/04 05:20:06 PM---Use Case 1: IE - Image the FS-ISAC peered with another"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." <[hidden email]>
To: "Camp, Warren (CTR)" <[hidden email]>, Michael Hammer <[hidden email]>, "[hidden email]" <[hidden email]>, Jason Keirstead/CanEast/IBM@IBMCA
Cc: "[hidden email]" <[hidden email]>
Date: 2015/11/04 05:20 PM
Subject: RE: [cti-users] "Data Marking" syntaxes
Sent by: <[hidden email]>





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) [[hidden email]]
Sent:
Wednesday, November 04, 2015 1:57 PM
To:
Michael Hammer; [hidden email]; [hidden email]; Collie, Byron S. [Tech]
Cc:
[hidden email]
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:[hidden email] [[hidden email]] On Behalf Of Michael Hammer
Sent:
Wednesday, November 04, 2015 1:43 PM
To:
[hidden email]; [hidden email]; [hidden email]
Cc:
[hidden email]
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
[hidden email]
Mobile: <a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2"><a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2">+1<a dir="ltr" href="tel:&#43;1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2">408 202 9291
<a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3"><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3">542 Gibraltar Drive
<a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3">Milpitas, CA 95035 USA
www.yaanatech.com

From:[hidden email] [[hidden email]] On Behalf Of Smith, Pamela A.
Sent:
Wednesday, November 04, 2015 12:11 PM
To:
Jason Keirstead <
[hidden email]>; Collie, Byron S. <[hidden email]>
Cc:
[hidden email]
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 <[hidden email]>
Sent:
Wednesday, November 4, 2015 11:04 AM
To:
Collie, Byron S.
Cc:
Smith, Pamela A.;
[hidden email]
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


Inactive hide details for "Collie, Byron S." ---2015/11/04 11:38:40 AM---Our internal platform implementation is tied to the Tr"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." <[hidden email]>
To:
Jason Keirstead/CanEast/IBM@IBMCA, "Smith, Pamela A." <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>
Date:
2015/11/04 11:38 AM
Subject:
RE: [cti-users] "Data Marking" syntaxes
Sent by:
<[hidden email]>






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:
[hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
Wednesday, November 04, 2015 10:10 AM
To:
Smith, Pamela A.
Cc:
[hidden email]
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


Inactive hide details for "Smith, Pamela A." ---2015/11/04 11:03:21 AM---All, I'm skeptical that we can converge on a single ma"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." <[hidden email]>
To:
"[hidden email]" <[hidden email]>
Date:
2015/11/04 11:03 AM
Subject:
Re: [cti-users] "Data Marking" syntaxes
Sent by:
<[hidden email]>







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:
[hidden email] <[hidden email]> on behalf of Dave Cridland <[hidden email]>
Sent:
Tuesday, November 3, 2015 4:39 AM
To:
[hidden email]
Cc:
Jordan, Bret; [hidden email]
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:
[hidden email]
Unsubscribe:
[hidden email]
Post:
[hidden email]
List help:
[hidden email]
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/





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: [hidden email]
Unsubscribe: [hidden email]
Post: [hidden email]
List help: [hidden email]
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/
Reply | Threaded
Open this post in threaded view
|

Re: [cti-users] "Data Marking" syntaxes

Jordan, Bret
In reply to this post by pmaroney
Okay I have kept quite on this topic for a few days, just watching and listening...  Now maybe I am overly simplifying things a bit.  But it seems to be that there are really only a few things people honestly care about, at least all of the examples so far only point to these things:

1) Can you share this data I am sending to you

2) If you can share it, who else can you share it with

3) If you share it do you need to anonymize it


It seems like if we use TLP, we need some sort of magic decoder ring to keep track of what WHITE is, what GREEN is what AMBER is etc...

So why not just say:

{
"share": "public || restricted",
"group": "group members if share==restricted",
"anonymize": "true || false"


Does this cover the very advanced stuff some group need.  No.  But with it being JSON, the can just add their own text fields for extra context.  Since a human will need to read them anyway.    But, does something like this get us 60% or 70%, or 80% there?


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 5, 2015, at 08:02, Patrick Maroney <[hidden email]> wrote:

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.

Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: <a dir="ltr" href="tel:(856)983-0001" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="0/1" style="color: purple; text-decoration: underline;" class="">(856)983-0001
Cell: <a dir="ltr" href="tel:(609)841-5104" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="0/2" style="color: purple; text-decoration: underline;" class="">(609)841-5104
Email: [hidden email]

__

signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [cti-users] "Data Marking" syntaxes

Jordan, Bret
In reply to this post by pmaroney
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 {
delete.object.if.I.can.not.handle.it()
} elsif {
do.someting.since.I.know.how.to.handle.it()
}


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 5, 2015, at 09:34, Patrick Maroney <[hidden email]> wrote:

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

From: <[hidden email]> on behalf of Patrick Maroney <[hidden email]>
Date: Thursday, November 5, 2015 at 10:02 AM
To: Mark Davidson <[hidden email]>, Jason Keirstead <[hidden email]>, Byron Collie <[hidden email]>
Cc: "Camp, Warren (CTR)" <[hidden email]>, Pamela Smith <[hidden email]>, Michael Hammer <[hidden email]>, "[hidden email]" <[hidden email]>
Subject: RE: [cti-users] "Data Marking" syntaxes

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.

Patrick Maroney
President
Integrated Networking Technologies, Inc.
Desk: <a dir="ltr" href="tel:(856)983-0001" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="0/1" style="color: purple; text-decoration: underline;" class="">(856)983-0001
Cell: <a dir="ltr" href="tel:(609)841-5104" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="0/2" style="color: purple; text-decoration: underline;" class="">(609)841-5104
Email: [hidden email]

_____________________________
From: Davidson II, Mark S <[hidden email]>
Sent: Thursday, November 5, 2015 9:15 AM
Subject: RE: [cti-users] "Data Marking" syntaxes
To: Jason Keirstead <[hidden email]>, Collie, Byron S. <[hidden email]>
Cc: Camp, Warren (CTR) <[hidden email]>, <[hidden email]>, Michael Hammer <[hidden email]>, <[hidden email]>


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

 

From:[hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent: Thursday, November 05, 2015 8:43 AM
To: Collie, Byron S. <[hidden email]>
Cc: Camp, Warren (CTR) <[hidden email]>; Michael Hammer <[hidden email]>; [hidden email]; [hidden email]
Subject: RE: [cti-users] "Data Marking" syntaxes

 

@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." <[hidden email]>
To: "Camp, Warren (CTR)" <[hidden email]>, Michael Hammer <[hidden email]>, "[hidden email]" <[hidden email]>, Jason Keirstead/CanEast/IBM@IBMCA
Cc: "[hidden email]" <[hidden email]>
Date: 2015/11/04 05:20 PM
Subject: RE: [cti-users] "Data Marking" syntaxes
Sent by: <[hidden email]>





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) [[hidden email]] 
Sent:
 Wednesday, November 04, 2015 1:57 PM
To:
 Michael Hammer; [hidden email]; [hidden email]; Collie, Byron S. [Tech]
Cc:
 [hidden email]
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:[hidden email] [[hidden email]] On Behalf Of Michael Hammer
Sent:
 Wednesday, November 04, 2015 1:43 PM
To:
 
[hidden email]; [hidden email]; [hidden email]
Cc:
 [hidden email]
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
[hidden email]
Mobile: <a dir="ltr" href="tel:+1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="tel:+1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="tel:+1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="tel:+1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="tel:+1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="tel:+1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="tel:+1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="tel:+1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="tel:+1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="tel:+1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="tel:+1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="tel:+1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="tel:+1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="tel:+1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2" style="color: purple; text-decoration: underline;" class="">+1<a dir="ltr" href="tel:+1%20408%20202%209291" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="46/2" style="color: purple; text-decoration: underline;" class="">408 202 9291
<a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3" style="color: purple; text-decoration: underline;" class=""><a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3" style="color: purple; text-decoration: underline;" class="">542 Gibraltar Drive
<a dir="ltr" href="x-apple-data-detectors://46/3" x-apple-data-detectors="true" x-apple-data-detectors-type="address" x-apple-data-detectors-result="46/3" style="color: purple; text-decoration: underline;" class="">Milpitas, CA 95035 USA
www.yaanatech.com

From:[hidden email] [[hidden email]] On Behalf Of Smith, Pamela A.
Sent:
 Wednesday, November 04, 2015 12:11 PM
To:
 Jason Keirstead <
[hidden email]>; Collie, Byron S. <[hidden email]>
Cc:
 
[hidden email]
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 <[hidden email]>
Sent:
 Wednesday, November 4, 2015 11:04 AM
To:
 Collie, Byron S.
Cc:
 Smith, Pamela A.; 
[hidden email]
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." <[hidden email]>
To: 
Jason Keirstead/CanEast/IBM@IBMCA, "Smith, Pamela A." <[hidden email]>
Cc: 
"[hidden email]" <[hidden email]>
Date: 
2015/11/04 11:38 AM
Subject: 
RE: [cti-users] "Data Marking" syntaxes
Sent by: 
<[hidden email]>





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:
[hidden email] [[hidden email]] On Behalf Of Jason Keirstead
Sent:
 Wednesday, November 04, 2015 10:10 AM
To:
 Smith, Pamela A.
Cc:
 
[hidden email]
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." <[hidden email]>
To: 
"[hidden email]" <[hidden email]>
Date: 
2015/11/04 11:03 AM
Subject: 
Re: [cti-users] "Data Marking" syntaxes
Sent by: 
<[hidden email]>






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:
[hidden email] <[hidden email]> on behalf of Dave Cridland <[hidden email]>
Sent:
 Tuesday, November 3, 2015 4:39 AM
To:
 
[hidden email]
Cc:
 Jordan, Bret; [hidden email]
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: 
[hidden email]
Unsubscribe: 
[hidden email]
Post: 
[hidden email]
List help: 
[hidden email]
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: [hidden email]
Unsubscribe: [hidden email]
Post: [hidden email]
List help: [hidden email]
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/


signature.asc (859 bytes) Download Attachment
123