CTI STIX Subcommittee

Hi folks, I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me if I'm missing something, or retracing your steps, or going about things to wrong way. The current section 6.5 appears to discuss aspects of object level markings, and suggests these might cover both legal permissioning (such as Copyright), and MAC systems (such as security labelling). Mixing the two is interesting - I hadn't considered this but it makes sense. Also, the system operates by reference. This is going to be very difficult to manage, and is traditionally avoided in most cases. This is especially true if the referenced label data for the marking is not present within the same transmission, since automated tooling for MAC will become extremely complex (and complexity begets unhappy accreditors). Has the group considered prior art in this space? I'm thinking particularly of XMPP's XEP-0258, but others may also apply. I'm particularly keen to ensure that multipolicy systems will work effectively, since I see that as being very likely in the CTI world shortly. As for multiple orthogonal rules - I don't understand where precedence comes into this. Taking Copyright as an example, if one derives a work from an existing work, the copyright changes, and the license may also change - I don't see the benefit in including a list of previous copyright notices, and then having the systems decide which one applies. I would expect that every marking present would need to be adhered to (some might not be practical to adhere to programmatically, of course). But you can't share something, say, UK SECRET, no matter what the copyright notice says - and vice-versa, an unclassified document cannot be shared if the copyright license is not available. Happy to discuss this further, or or out of any particuar call. Dave.

Dave, Great comments and questions.....   Let me try and fill in some of the gaps....  Yes, in STIX 2.0 we will have two types of relationships....  And as a general rule most everything will use a relationship in STIX 2.0.  Nested content in STIX 1.x proved to be a bad design in the wild.   1) Embedded references (like created_by_ref and object_markings_ref).  These references are "facts" that will be known to the TLO.  However, like you said, a consumer may not have the reference yet, or may not have access to the referenced object.  For data markings we say, that if you do not have the object_markings_ref object, and you can not get it via another TAXII call, than you MUST stop processing the TLO.  In the real-world, you will have out-of-band gates that prevent you from ever sharing threat intelligence with someone that does not have access to the same the data-markings that you have access to.   2) Relationship Objects.  These relationships are used for assertions or opinions about things.  So if you link an Observation to a Campaign, or an Incident to an IntrusionSet, you would use one of these external relationships to link it together.  This will allow you, in the future, to place a confidence score on your assertion that these two things are related.  It will also allow in the future for others to potentially down-vote your assertions.   Bret   From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Dave Cridland <dave.cridland@surevine.com> Sent: Sunday, June 12, 2016 7:09 AM To: cti-stix@lists.oasis-open.org Subject: [cti-stix] Object Level Markings   Hi folks, I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me if I'm missing something, or retracing your steps, or going about things to wrong way. The current section 6.5 appears to discuss aspects of object level markings, and suggests these might cover both legal permissioning (such as Copyright), and MAC systems (such as security labelling). Mixing the two is interesting - I hadn't considered this but it makes sense. Also, the system operates by reference. This is going to be very difficult to manage, and is traditionally avoided in most cases. This is especially true if the referenced label data for the marking is not present within the same transmission, since automated tooling for MAC will become extremely complex (and complexity begets unhappy accreditors). Has the group considered prior art in this space? I'm thinking particularly of XMPP's XEP-0258, but others may also apply. I'm particularly keen to ensure that multipolicy systems will work effectively, since I see that as being very likely in the CTI world shortly. As for multiple orthogonal rules - I don't understand where precedence comes into this. Taking Copyright as an example, if one derives a work from an existing work, the copyright changes, and the license may also change - I don't see the benefit in including a list of previous copyright notices, and then having the systems decide which one applies. I would expect that every marking present would need to be adhered to (some might not be practical to adhere to programmatically, of course). But you can't share something, say, UK SECRET, no matter what the copyright notice says - and vice-versa, an unclassified document cannot be shared if the copyright license is not available. Happy to discuss this further, or or out of any particuar call. Dave.

To explain a bit more, doing markings by reference was something that was requested by some US government folks who wanted to avoid representing duplicative markings over and over again.
While things like TLP are very short and can easily be duplicated over and over, other marking statements (copyrights, government markings, and likely whatever the FIRST SIG creates) will be larger and more complicated and so being able to reference those
from 1000 indicators rather than duplicate them seems to make sense. As Bret said, we added normative text to make sure we covered this case.
 
As for precedence, it’s a bit of a hard topic. In some cases (TLP) you really only have one marking that can apply…it doesn’t make sense for an object to have both TLP:GREEN and TLP:RED.
In other cases, like terms of use, you have several that apply. In other cases, like more complicated structured markings, it’s possible for multiple to apply and override parts of the other. We didn’t want to address this in STIX so simply defined what it
meant for markings to have precedence and will let the marking definitions themselves figure out what that means. Note that, as you said, it’s definitely true that markings of different types will not override each other. This is why we said that precedence
rules only apply to markings of the same type.
 
When first designing data markings in 1.x and discussing them for 2.0 we had very good participation from people in government who mark things every day and that led us to the reference
approach (among other things). We did discuss other approaches, in particular NIEM…I also did a quick search and it looks like you actually brought up XEP-0258 at the time. You can review here:
https://lists.oasis-open.org/archives/cti-users/201511/msg00002.html . The conversation was a bit different than applying markings, it was about the markings that get applied
themselves, and I think is what led to our following the FIRST SIG on Information Sharing.
 
Anyway, how would you like me to treat this comment? Should I assume it’s an objection to the motion for unanimous consent that I made on Friday? If so, as a community we need to decide
whether we want to open a data markings discussion or just hold a ballot to accept what we have.
 
John
 

From:
<cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Sunday, June 12, 2016 at 5:14 PM
To: Dave Cridland <dave.cridland@surevine.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Object Level Markings


 




Dave,
 
Great comments and questions.....   Let me try and fill in some of the gaps....  Yes, in STIX 2.0 we will have two types of relationships....  And as a general rule most everything will
use a relationship in STIX 2.0.  Nested content in STIX 1.x proved to be a bad design in the wild.  
 
1) Embedded references (like created_by_ref and object_markings_ref).  These references are "facts" that will be known to the TLO.  However, like you said, a consumer may not have the
reference yet, or may not have access to the referenced object.  For data markings we say, that if you do not have the object_markings_ref object, and you can not get it via another TAXII call, than you MUST stop processing the TLO.  In the real-world, you
will have out-of-band gates that prevent you from ever sharing threat intelligence with someone that does not have access to the same the data-markings that you have access to.  
 
2) Relationship Objects.  These relationships are used for assertions or opinions about things.  So if you link an Observation to a Campaign, or an Incident to an IntrusionSet, you would
use one of these external relationships to link it together.  This will allow you, in the future, to place a confidence score on your assertion that these two things are related.  It will also allow in the future for others to potentially down-vote your assertions.
 
 
Bret  
 






From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on
behalf of Dave Cridland <dave.cridland@surevine.com>
Sent: Sunday, June 12, 2016 7:09 AM
To: cti-stix@lists.oasis-open.org
Subject: [cti-stix] Object Level Markings


 



Hi folks,
I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me if I'm missing something, or retracing your steps, or going about things to wrong way.
The current section 6.5 appears to discuss aspects of object level markings, and suggests these might cover both legal permissioning (such as Copyright), and MAC systems (such as security
labelling). Mixing the two is interesting - I hadn't considered this but it makes sense.
Also, the system operates by reference. This is going to be very difficult to manage, and is traditionally avoided in most cases. This is especially true if the referenced label data
for the marking is not present within the same transmission, since automated tooling for MAC will become extremely complex (and complexity begets unhappy accreditors).
Has the group considered prior art in this space? I'm thinking particularly of XMPP's XEP-0258, but others may also apply. I'm particularly keen to ensure that multipolicy systems will
work effectively, since I see that as being very likely in the CTI world shortly.
As for multiple orthogonal rules - I don't understand where precedence comes into this. Taking Copyright as an example, if one derives a work from an existing work, the copyright changes,
and the license may also change - I don't see the benefit in including a list of previous copyright notices, and then having the systems decide which one applies.
I would expect that every marking present would need to be adhered to (some might not be practical to adhere to programmatically, of course). But you can't share something, say, UK SECRET,
no matter what the copyright notice says - and vice-versa, an unclassified document cannot be shared if the copyright license is not available.
Happy to discuss this further, or or out of any particuar call.
Dave.

Sorry, I'm sitting in the FIRST SIG meeting and realizing that I gave the wrong name in my message below. It's the FIRST SIG on Information Exchange Policy (IEP). https://www.first.org/global/sigs/iep Sorry about that!  John From: Wunder, John A. < jwunder@mitre.org > Date: Monday, Jun 13, 2016, 7:31 AM To: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Object Level Markings To explain a bit more, doing markings by reference was something that was requested by some US government folks who wanted to avoid representing duplicative markings over and over again. While things like TLP are very short and can easily be duplicated over and over, other marking statements (copyrights, government markings, and likely whatever the FIRST SIG creates) will be larger and more complicated and so being able to reference those from 1000 indicators rather than duplicate them seems to make sense. As Bret said, we added normative text to make sure we covered this case.   As for precedence, it’s a bit of a hard topic. In some cases (TLP) you really only have one marking that can apply…it doesn’t make sense for an object to have both TLP:GREEN and TLP:RED. In other cases, like terms of use, you have several that apply. In other cases, like more complicated structured markings, it’s possible for multiple to apply and override parts of the other. We didn’t want to address this in STIX so simply defined what it meant for markings to have precedence and will let the marking definitions themselves figure out what that means. Note that, as you said, it’s definitely true that markings of different types will not override each other. This is why we said that precedence rules only apply to markings of the same type.   When first designing data markings in 1.x and discussing them for 2.0 we had very good participation from people in government who mark things every day and that led us to the reference approach (among other things). We did discuss other approaches, in particular NIEM…I also did a quick search and it looks like you actually brought up XEP-0258 at the time. You can review here: https://lists.oasis-open.org/archives/cti-users/201511/msg00002.html . The conversation was a bit different than applying markings, it was about the markings that get applied themselves, and I think is what led to our following the FIRST SIG on Information Sharing.   Anyway, how would you like me to treat this comment? Should I assume it’s an objection to the motion for unanimous consent that I made on Friday? If so, as a community we need to decide whether we want to open a data markings discussion or just hold a ballot to accept what we have.   John   From: <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com> Date: Sunday, June 12, 2016 at 5:14 PM To: Dave Cridland <dave.cridland@surevine.com>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Subject: Re: [cti-stix] Object Level Markings   Dave,   Great comments and questions.....   Let me try and fill in some of the gaps....  Yes, in STIX 2.0 we will have two types of relationships....  And as a general rule most everything will use a relationship in STIX 2.0.  Nested content in STIX 1.x proved to be a bad design in the wild.     1) Embedded references (like created_by_ref and object_markings_ref).  These references are "facts" that will be known to the TLO.  However, like you said, a consumer may not have the reference yet, or may not have access to the referenced object.  For data markings we say, that if you do not have the object_markings_ref object, and you can not get it via another TAXII call, than you MUST stop processing the TLO.  In the real-world, you will have out-of-band gates that prevent you from ever sharing threat intelligence with someone that does not have access to the same the data-markings that you have access to.     2) Relationship Objects.  These relationships are used for assertions or opinions about things.  So if you link an Observation to a Campaign, or an Incident to an IntrusionSet, you would use one of these external relationships to link it together.  This will allow you, in the future, to place a confidence score on your assertion that these two things are related.  It will also allow in the future for others to potentially down-vote your assertions.     Bret     From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Dave Cridland <dave.cridland@surevine.com> Sent: Sunday, June 12, 2016 7:09 AM To: cti-stix@lists.oasis-open.org Subject: [cti-stix] Object Level Markings   Hi folks, I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me if I'm missing something, or retracing your steps, or going about things to wrong way. The current section 6.5 appears to discuss aspects of object level markings, and suggests these might cover both legal permissioning (such as Copyright), and MAC systems (such as security labelling). Mixing the two is interesting - I hadn't considered this but it makes sense. Also, the system operates by reference. This is going to be very difficult to manage, and is traditionally avoided in most cases. This is especially true if the referenced label data for the marking is not present within the same transmission, since automated tooling for MAC will become extremely complex (and complexity begets unhappy accreditors). Has the group considered prior art in this space? I'm thinking particularly of XMPP's XEP-0258, but others may also apply. I'm particularly keen to ensure that multipolicy systems will work effectively, since I see that as being very likely in the CTI world shortly. As for multiple orthogonal rules - I don't understand where precedence comes into this. Taking Copyright as an example, if one derives a work from an existing work, the copyright changes, and the license may also change - I don't see the benefit in including a list of previous copyright notices, and then having the systems decide which one applies. I would expect that every marking present would need to be adhered to (some might not be practical to adhere to programmatically, of course). But you can't share something, say, UK SECRET, no matter what the copyright notice says - and vice-versa, an unclassified document cannot be shared if the copyright license is not available. Happy to discuss this further, or or out of any particuar call. Dave.

Yes, I'm unclear why the US Gov wants to do labels by reference; I've only ever seen that requirement from the US, and never anyone else. I suspect it's due to the US having relative few permutations in the labelling scheme, whereas the UK (for example) has thousands. My thought is that while it's certainly useful to move, for example, a full copyright license to a reference, in the majority of cases a simple label or statement can be presented inline without any problem - it'll likely be shorter than the example identifiers given in many cases. The other issue is that by enforcing everything to be solely by reference, the display marking is lost. I worry that this means we lose the ability to spot issues by eyeball. More information: The display marking is the string that might be printed at the bottom of a document, such as "SECRET//NOFORN", or "NATO SECRET". The label is the machine readable form, and contains information such as what policy is used. Labels come in a variety of formats, from the XML/JSON EDH form that the US uses (quite verbose) to the very terse ESS, used in S/MIME for example. This latter form is usually much smaller than a display marking; a typical US label in ESS form is perhaps 20 bytes - smaller than your identifier. As far as precedence is concerned, the only case I can think of where this might be important is where you have policy translation going on. Say the information originates in NATO, for example, as NATO SECRET, and moves to a UK domain, where it needs marking as UK SECRET (I simplify of course). The "most correct" label is still the NATO one, and the UK Equivalent Label is only there for systems that only understand the local policy. You can exchange "NATO" for "CERT-US" and "UK" for "FS-ISAC" if you prefer. But in this case you want to group the labels and mark the equivalent ones such that they can easily be ignored. I can live with being in the rough on referenced labels, though I would prefer an option to inline the data. I'm worried that "precedence" isn't thought through quite enough. I'm happy to write some text that covers my concerns. On 12 Jun 2016 11:31 p.m., "Wunder, John A." < jwunder@mitre.org > wrote: To explain a bit more, doing markings by reference was something that was requested by some US government folks who wanted to avoid representing duplicative markings over and over again. While things like TLP are very short and can easily be duplicated over and over, other marking statements (copyrights, government markings, and likely whatever the FIRST SIG creates) will be larger and more complicated and so being able to reference those from 1000 indicators rather than duplicate them seems to make sense. As Bret said, we added normative text to make sure we covered this case.   As for precedence, it’s a bit of a hard topic. In some cases (TLP) you really only have one marking that can apply…it doesn’t make sense for an object to have both TLP:GREEN and TLP:RED. In other cases, like terms of use, you have several that apply. In other cases, like more complicated structured markings, it’s possible for multiple to apply and override parts of the other. We didn’t want to address this in STIX so simply defined what it meant for markings to have precedence and will let the marking definitions themselves figure out what that means. Note that, as you said, it’s definitely true that markings of different types will not override each other. This is why we said that precedence rules only apply to markings of the same type.   When first designing data markings in 1.x and discussing them for 2.0 we had very good participation from people in government who mark things every day and that led us to the reference approach (among other things). We did discuss other approaches, in particular NIEM…I also did a quick search and it looks like you actually brought up XEP-0258 at the time. You can review here: https://lists.oasis-open.org/archives/cti-users/201511/msg00002.html . The conversation was a bit different than applying markings, it was about the markings that get applied themselves, and I think is what led to our following the FIRST SIG on Information Sharing.   Anyway, how would you like me to treat this comment? Should I assume it’s an objection to the motion for unanimous consent that I made on Friday? If so, as a community we need to decide whether we want to open a data markings discussion or just hold a ballot to accept what we have.   John   From: < cti-stix@lists.oasis-open.org > on behalf of "Jordan, Bret" < bret.jordan@bluecoat.com > Date: Sunday, June 12, 2016 at 5:14 PM To: Dave Cridland < dave.cridland@surevine.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Object Level Markings   Dave,   Great comments and questions.....   Let me try and fill in some of the gaps....  Yes, in STIX 2.0 we will have two types of relationships....  And as a general rule most everything will use a relationship in STIX 2.0.  Nested content in STIX 1.x proved to be a bad design in the wild.     1) Embedded references (like created_by_ref and object_markings_ref).  These references are "facts" that will be known to the TLO.  However, like you said, a consumer may not have the reference yet, or may not have access to the referenced object.  For data markings we say, that if you do not have the object_markings_ref object, and you can not get it via another TAXII call, than you MUST stop processing the TLO.  In the real-world, you will have out-of-band gates that prevent you from ever sharing threat intelligence with someone that does not have access to the same the data-markings that you have access to.     2) Relationship Objects.  These relationships are used for assertions or opinions about things.  So if you link an Observation to a Campaign, or an Incident to an IntrusionSet, you would use one of these external relationships to link it together.  This will allow you, in the future, to place a confidence score on your assertion that these two things are related.  It will also allow in the future for others to potentially down-vote your assertions.     Bret     From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on behalf of Dave Cridland < dave.cridland@surevine.com > Sent: Sunday, June 12, 2016 7:09 AM To: cti-stix@lists.oasis-open.org Subject: [cti-stix] Object Level Markings   Hi folks, I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me if I'm missing something, or retracing your steps, or going about things to wrong way. The current section 6.5 appears to discuss aspects of object level markings, and suggests these might cover both legal permissioning (such as Copyright), and MAC systems (such as security labelling). Mixing the two is interesting - I hadn't considered this but it makes sense. Also, the system operates by reference. This is going to be very difficult to manage, and is traditionally avoided in most cases. This is especially true if the referenced label data for the marking is not present within the same transmission, since automated tooling for MAC will become extremely complex (and complexity begets unhappy accreditors). Has the group considered prior art in this space? I'm thinking particularly of XMPP's XEP-0258, but others may also apply. I'm particularly keen to ensure that multipolicy systems will work effectively, since I see that as being very likely in the CTI world shortly. As for multiple orthogonal rules - I don't understand where precedence comes into this. Taking Copyright as an example, if one derives a work from an existing work, the copyright changes, and the license may also change - I don't see the benefit in including a list of previous copyright notices, and then having the systems decide which one applies. I would expect that every marking present would need to be adhered to (some might not be practical to adhere to programmatically, of course). But you can't share something, say, UK SECRET, no matter what the copyright notice says - and vice-versa, an unclassified document cannot be shared if the copyright license is not available. Happy to discuss this further, or or out of any particuar call. Dave.

We need to make sure we have "one-way" of doing things.  If there are multiple ways of doing the same thing, then we will have a fragile design.  Further, one of our original designs or hopes was that certain common data markings might become well known thus reducing the need to re-transmit. I think manual visual inspection of raw JSON is only valid during testing or in simple environments.  Inspecting the datamarking in reality is an implementation issue, not a specification issue.  Your tool should be able to easily dereference the datamarkings and display them for you. Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Dave Cridland <dave.cridland@surevine.com> Sent: Monday, June 13, 2016 2:20 AM To: Wunder, John A. Cc: cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Object Level Markings   Yes, I'm unclear why the US Gov wants to do labels by reference; I've only ever seen that requirement from the US, and never anyone else. I suspect it's due to the US having relative few permutations in the labelling scheme, whereas the UK (for example) has thousands. My thought is that while it's certainly useful to move, for example, a full copyright license to a reference, in the majority of cases a simple label or statement can be presented inline without any problem - it'll likely be shorter than the example identifiers given in many cases. The other issue is that by enforcing everything to be solely by reference, the display marking is lost. I worry that this means we lose the ability to spot issues by eyeball. More information: The display marking is the string that might be printed at the bottom of a document, such as "SECRET//NOFORN", or "NATO SECRET". The label is the machine readable form, and contains information such as what policy is used. Labels come in a variety of formats, from the XML/JSON EDH form that the US uses (quite verbose) to the very terse ESS, used in S/MIME for example. This latter form is usually much smaller than a display marking; a typical US label in ESS form is perhaps 20 bytes - smaller than your identifier. As far as precedence is concerned, the only case I can think of where this might be important is where you have policy translation going on. Say the information originates in NATO, for example, as NATO SECRET, and moves to a UK domain, where it needs marking as UK SECRET (I simplify of course). The "most correct" label is still the NATO one, and the UK Equivalent Label is only there for systems that only understand the local policy. You can exchange "NATO" for "CERT-US" and "UK" for "FS-ISAC" if you prefer. But in this case you want to group the labels and mark the equivalent ones such that they can easily be ignored. I can live with being in the rough on referenced labels, though I would prefer an option to inline the data. I'm worried that "precedence" isn't thought through quite enough. I'm happy to write some text that covers my concerns. On 12 Jun 2016 11:31 p.m., "Wunder, John A." < jwunder@mitre.org > wrote: To explain a bit more, doing markings by reference was something that was requested by some US government folks who wanted to avoid representing duplicative markings over and over again. While things like TLP are very short and can easily be duplicated over and over, other marking statements (copyrights, government markings, and likely whatever the FIRST SIG creates) will be larger and more complicated and so being able to reference those from 1000 indicators rather than duplicate them seems to make sense. As Bret said, we added normative text to make sure we covered this case.   As for precedence, it’s a bit of a hard topic. In some cases (TLP) you really only have one marking that can apply…it doesn’t make sense for an object to have both TLP:GREEN and TLP:RED. In other cases, like terms of use, you have several that apply. In other cases, like more complicated structured markings, it’s possible for multiple to apply and override parts of the other. We didn’t want to address this in STIX so simply defined what it meant for markings to have precedence and will let the marking definitions themselves figure out what that means. Note that, as you said, it’s definitely true that markings of different types will not override each other. This is why we said that precedence rules only apply to markings of the same type.   When first designing data markings in 1.x and discussing them for 2.0 we had very good participation from people in government who mark things every day and that led us to the reference approach (among other things). We did discuss other approaches, in particular NIEM…I also did a quick search and it looks like you actually brought up XEP-0258 at the time. You can review here: https://lists.oasis-open.org/archives/cti-users/201511/msg00002.html . The conversation was a bit different than applying markings, it was about the markings that get applied themselves, and I think is what led to our following the FIRST SIG on Information Sharing.   Anyway, how would you like me to treat this comment? Should I assume it’s an objection to the motion for unanimous consent that I made on Friday? If so, as a community we need to decide whether we want to open a data markings discussion or just hold a ballot to accept what we have.   John   From: < cti-stix@lists.oasis-open.org > on behalf of "Jordan, Bret" < bret.jordan@bluecoat.com > Date: Sunday, June 12, 2016 at 5:14 PM To: Dave Cridland < dave.cridland@surevine.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Object Level Markings   Dave,   Great comments and questions.....   Let me try and fill in some of the gaps....  Yes, in STIX 2.0 we will have two types of relationships....  And as a general rule most everything will use a relationship in STIX 2.0.  Nested content in STIX 1.x proved to be a bad design in the wild.     1) Embedded references (like created_by_ref and object_markings_ref).  These references are "facts" that will be known to the TLO.  However, like you said, a consumer may not have the reference yet, or may not have access to the referenced object.  For data markings we say, that if you do not have the object_markings_ref object, and you can not get it via another TAXII call, than you MUST stop processing the TLO.  In the real-world, you will have out-of-band gates that prevent you from ever sharing threat intelligence with someone that does not have access to the same the data-markings that you have access to.     2) Relationship Objects.  These relationships are used for assertions or opinions about things.  So if you link an Observation to a Campaign, or an Incident to an IntrusionSet, you would use one of these external relationships to link it together.  This will allow you, in the future, to place a confidence score on your assertion that these two things are related.  It will also allow in the future for others to potentially down-vote your assertions.     Bret     From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on behalf of Dave Cridland < dave.cridland@surevine.com > Sent: Sunday, June 12, 2016 7:09 AM To: cti-stix@lists.oasis-open.org Subject: [cti-stix] Object Level Markings   Hi folks, I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me if I'm missing something, or retracing your steps, or going about things to wrong way. The current section 6.5 appears to discuss aspects of object level markings, and suggests these might cover both legal permissioning (such as Copyright), and MAC systems (such as security labelling). Mixing the two is interesting - I hadn't considered this but it makes sense. Also, the system operates by reference. This is going to be very difficult to manage, and is traditionally avoided in most cases. This is especially true if the referenced label data for the marking is not present within the same transmission, since automated tooling for MAC will become extremely complex (and complexity begets unhappy accreditors). Has the group considered prior art in this space? I'm thinking particularly of XMPP's XEP-0258, but others may also apply. I'm particularly keen to ensure that multipolicy systems will work effectively, since I see that as being very likely in the CTI world shortly. As for multiple orthogonal rules - I don't understand where precedence comes into this. Taking Copyright as an example, if one derives a work from an existing work, the copyright changes, and the license may also change - I don't see the benefit in including a list of previous copyright notices, and then having the systems decide which one applies. I would expect that every marking present would need to be adhered to (some might not be practical to adhere to programmatically, of course). But you can't share something, say, UK SECRET, no matter what the copyright notice says - and vice-versa, an unclassified document cannot be shared if the copyright license is not available. Happy to discuss this further, or or out of any particuar call. Dave.

Bret, There's no semantic difference between a labelling scheme that mandates inline and a labelling scheme whose mandatory inline form is a reference to external information. If you want a single method, then inlining is the one, and the inline form can then optionally consist of just a reference. But if it's all references, and the reference is to another object within the same PDU, or transaction, then this is mostly a matter of personal taste and not a hill for me to die on. Similarly, while I'd prefer the display marking to be in the JSON payload I can live without it. But I do think there are serious problems with having labelling metadata arrive in a different transaction than the TLO (and therefore potentially not at all). If you're considering only originators and consumers in a corporate setting, this might not seem like a major problem, but if you consider border gateways and guard systems, especially within secure environments, it can introduce an entirely new failure state. If the source system fails before the gateway can ascertain the label of the data, then it is unable to know if the data should be forwarded, rejected (with a logged exception), or stored pending. From a security standpoint, I don't know what happens if an attempt to deference a label reference fails. That's aside from considerations about cryptographic binding of label metadata to the object - we can handwave over that to a degree if we assume that we can carry both the TLO and the labelling object within the same secure channel (TLS, for example), but otherwise there's a risk that a label dereferenced by a later transaction would be different from the intention when the object was transmitted, and this isn't something we can specify around - we need cryptographic proof. Dave. We need to make sure we have "one-way" of doing things.  If there are multiple ways of doing the same thing, then we will have a fragile design.  Further, one of our original designs or hopes was that certain common data markings might become well known thus reducing the need to re-transmit. I think manual visual inspection of raw JSON is only valid during testing or in simple environments.  Inspecting the datamarking in reality is an implementation issue, not a specification issue.  Your tool should be able to easily dereference the datamarkings and display them for you. Bret From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on behalf of Dave Cridland < dave.cridland@surevine.com > Sent: Monday, June 13, 2016 2:20 AM To: Wunder, John A. Cc: cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Object Level Markings   Yes, I'm unclear why the US Gov wants to do labels by reference; I've only ever seen that requirement from the US, and never anyone else. I suspect it's due to the US having relative few permutations in the labelling scheme, whereas the UK (for example) has thousands. My thought is that while it's certainly useful to move, for example, a full copyright license to a reference, in the majority of cases a simple label or statement can be presented inline without any problem - it'll likely be shorter than the example identifiers given in many cases. The other issue is that by enforcing everything to be solely by reference, the display marking is lost. I worry that this means we lose the ability to spot issues by eyeball. More information: The display marking is the string that might be printed at the bottom of a document, such as "SECRET//NOFORN", or "NATO SECRET". The label is the machine readable form, and contains information such as what policy is used. Labels come in a variety of formats, from the XML/JSON EDH form that the US uses (quite verbose) to the very terse ESS, used in S/MIME for example. This latter form is usually much smaller than a display marking; a typical US label in ESS form is perhaps 20 bytes - smaller than your identifier. As far as precedence is concerned, the only case I can think of where this might be important is where you have policy translation going on. Say the information originates in NATO, for example, as NATO SECRET, and moves to a UK domain, where it needs marking as UK SECRET (I simplify of course). The "most correct" label is still the NATO one, and the UK Equivalent Label is only there for systems that only understand the local policy. You can exchange "NATO" for "CERT-US" and "UK" for "FS-ISAC" if you prefer. But in this case you want to group the labels and mark the equivalent ones such that they can easily be ignored. I can live with being in the rough on referenced labels, though I would prefer an option to inline the data. I'm worried that "precedence" isn't thought through quite enough. I'm happy to write some text that covers my concerns. On 12 Jun 2016 11:31 p.m., "Wunder, John A." < jwunder@mitre.org > wrote: To explain a bit more, doing markings by reference was something that was requested by some US government folks who wanted to avoid representing duplicative markings over and over again. While things like TLP are very short and can easily be duplicated over and over, other marking statements (copyrights, government markings, and likely whatever the FIRST SIG creates) will be larger and more complicated and so being able to reference those from 1000 indicators rather than duplicate them seems to make sense. As Bret said, we added normative text to make sure we covered this case.   As for precedence, it’s a bit of a hard topic. In some cases (TLP) you really only have one marking that can apply…it doesn’t make sense for an object to have both TLP:GREEN and TLP:RED. In other cases, like terms of use, you have several that apply. In other cases, like more complicated structured markings, it’s possible for multiple to apply and override parts of the other. We didn’t want to address this in STIX so simply defined what it meant for markings to have precedence and will let the marking definitions themselves figure out what that means. Note that, as you said, it’s definitely true that markings of different types will not override each other. This is why we said that precedence rules only apply to markings of the same type.   When first designing data markings in 1.x and discussing them for 2.0 we had very good participation from people in government who mark things every day and that led us to the reference approach (among other things). We did discuss other approaches, in particular NIEM…I also did a quick search and it looks like you actually brought up XEP-0258 at the time. You can review here: https://lists.oasis-open.org/archives/cti-users/201511/msg00002.html . The conversation was a bit different than applying markings, it was about the markings that get applied themselves, and I think is what led to our following the FIRST SIG on Information Sharing.   Anyway, how would you like me to treat this comment? Should I assume it’s an objection to the motion for unanimous consent that I made on Friday? If so, as a community we need to decide whether we want to open a data markings discussion or just hold a ballot to accept what we have.   John   From: < cti-stix@lists.oasis-open.org > on behalf of "Jordan, Bret" < bret.jordan@bluecoat.com > Date: Sunday, June 12, 2016 at 5:14 PM To: Dave Cridland < dave.cridland@surevine.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Object Level Markings   Dave,   Great comments and questions.....   Let me try and fill in some of the gaps....  Yes, in STIX 2.0 we will have two types of relationships....  And as a general rule most everything will use a relationship in STIX 2.0.  Nested content in STIX 1.x proved to be a bad design in the wild.     1) Embedded references (like created_by_ref and object_markings_ref).  These references are "facts" that will be known to the TLO.  However, like you said, a consumer may not have the reference yet, or may not have access to the referenced object.  For data markings we say, that if you do not have the object_markings_ref object, and you can not get it via another TAXII call, than you MUST stop processing the TLO.  In the real-world, you will have out-of-band gates that prevent you from ever sharing threat intelligence with someone that does not have access to the same the data-markings that you have access to.     2) Relationship Objects.  These relationships are used for assertions or opinions about things.  So if you link an Observation to a Campaign, or an Incident to an IntrusionSet, you would use one of these external relationships to link it together.  This will allow you, in the future, to place a confidence score on your assertion that these two things are related.  It will also allow in the future for others to potentially down-vote your assertions.     Bret     From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on behalf of Dave Cridland < dave.cridland@surevine.com > Sent: Sunday, June 12, 2016 7:09 AM To: cti-stix@lists.oasis-open.org Subject: [cti-stix] Object Level Markings   Hi folks, I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me if I'm missing something, or retracing your steps, or going about things to wrong way. The current section 6.5 appears to discuss aspects of object level markings, and suggests these might cover both legal permissioning (such as Copyright), and MAC systems (such as security labelling). Mixing the two is interesting - I hadn't considered this but it makes sense. Also, the system operates by reference. This is going to be very difficult to manage, and is traditionally avoided in most cases. This is especially true if the referenced label data for the marking is not present within the same transmission, since automated tooling for MAC will become extremely complex (and complexity begets unhappy accreditors). Has the group considered prior art in this space? I'm thinking particularly of XMPP's XEP-0258, but others may also apply. I'm particularly keen to ensure that multipolicy systems will work effectively, since I see that as being very likely in the CTI world shortly. As for multiple orthogonal rules - I don't understand where precedence comes into this. Taking Copyright as an example, if one derives a work from an existing work, the copyright changes, and the license may also change - I don't see the benefit in including a list of previous copyright notices, and then having the systems decide which one applies. I would expect that every marking present would need to be adhered to (some might not be practical to adhere to programmatically, of course). But you can't share something, say, UK SECRET, no matter what the copyright notice says - and vice-versa, an unclassified document cannot be shared if the copyright license is not available. Happy to discuss this further, or or out of any particuar call. Dave.

Dave, Welcome! And good luck here You could be interested by https://lists.oasis-open.org/archives/cti-users/201604/msg00005.html Regards 2016-06-13 19:10 GMT+03:00 Dave Cridland <dave.cridland@surevine.com>: > Bret, > > There's no semantic difference between a labelling scheme that mandates > inline and a labelling scheme whose mandatory inline form is a reference to > external information. If you want a single method, then inlining is the one, > and the inline form can then optionally consist of just a reference. But if > it's all references, and the reference is to another object within the same > PDU, or transaction, then this is mostly a matter of personal taste and not > a hill for me to die on. > > Similarly, while I'd prefer the display marking to be in the JSON payload I > can live without it. > > But I do think there are serious problems with having labelling metadata > arrive in a different transaction than the TLO (and therefore potentially > not at all). If you're considering only originators and consumers in a > corporate setting, this might not seem like a major problem, but if you > consider border gateways and guard systems, especially within secure > environments, it can introduce an entirely new failure state. If the source > system fails before the gateway can ascertain the label of the data, then it > is unable to know if the data should be forwarded, rejected (with a logged > exception), or stored pending. From a security standpoint, I don't know what > happens if an attempt to deference a label reference fails. > > That's aside from considerations about cryptographic binding of label > metadata to the object - we can handwave over that to a degree if we assume > that we can carry both the TLO and the labelling object within the same > secure channel (TLS, for example), but otherwise there's a risk that a label > dereferenced by a later transaction would be different from the intention > when the object was transmitted, and this isn't something we can specify > around - we need cryptographic proof. > > Dave. > > We need to make sure we have "one-way" of doing things. If there are > multiple ways of doing the same thing, then we will have a fragile design. > Further, one of our original designs or hopes was that certain common data > markings might become well known thus reducing the need to re-transmit. > > > I think manual visual inspection of raw JSON is only valid during testing or > in simple environments. Inspecting the datamarking in reality is an > implementation issue, not a specification issue. Your tool should be able > to easily dereference the datamarkings and display them for you. > > > Bret > > > > > ________________________________ > From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on > behalf of Dave Cridland <dave.cridland@surevine.com> > Sent: Monday, June 13, 2016 2:20 AM > To: Wunder, John A. > Cc: cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Object Level Markings > > > Yes, I'm unclear why the US Gov wants to do labels by reference; I've only > ever seen that requirement from the US, and never anyone else. I suspect > it's due to the US having relative few permutations in the labelling scheme, > whereas the UK (for example) has thousands. > > My thought is that while it's certainly useful to move, for example, a full > copyright license to a reference, in the majority of cases a simple label or > statement can be presented inline without any problem - it'll likely be > shorter than the example identifiers given in many cases. > > The other issue is that by enforcing everything to be solely by reference, > the display marking is lost. I worry that this means we lose the ability to > spot issues by eyeball. > > More information: > > The display marking is the string that might be printed at the bottom of a > document, such as "SECRET//NOFORN", or "NATO SECRET". The label is the > machine readable form, and contains information such as what policy is used. > Labels come in a variety of formats, from the XML/JSON EDH form that the US > uses (quite verbose) to the very terse ESS, used in S/MIME for example. This > latter form is usually much smaller than a display marking; a typical US > label in ESS form is perhaps 20 bytes - smaller than your identifier. > > As far as precedence is concerned, the only case I can think of where this > might be important is where you have policy translation going on. Say the > information originates in NATO, for example, as NATO SECRET, and moves to a > UK domain, where it needs marking as UK SECRET (I simplify of course). The > "most correct" label is still the NATO one, and the UK Equivalent Label is > only there for systems that only understand the local policy. You can > exchange "NATO" for "CERT-US" and "UK" for "FS-ISAC" if you prefer. > > But in this case you want to group the labels and mark the equivalent ones > such that they can easily be ignored. > > I can live with being in the rough on referenced labels, though I would > prefer an option to inline the data. > > I'm worried that "precedence" isn't thought through quite enough. > > I'm happy to write some text that covers my concerns. > > On 12 Jun 2016 11:31 p.m., "Wunder, John A." <jwunder@mitre.org> wrote: >> >> To explain a bit more, doing markings by reference was something that was >> requested by some US government folks who wanted to avoid representing >> duplicative markings over and over again. While things like TLP are very >> short and can easily be duplicated over and over, other marking statements >> (copyrights, government markings, and likely whatever the FIRST SIG creates) >> will be larger and more complicated and so being able to reference those >> from 1000 indicators rather than duplicate them seems to make sense. As Bret >> said, we added normative text to make sure we covered this case. >> >> >> >> As for precedence, it’s a bit of a hard topic. In some cases (TLP) you >> really only have one marking that can apply…it doesn’t make sense for an >> object to have both TLP:GREEN and TLP:RED. In other cases, like terms of >> use, you have several that apply. In other cases, like more complicated >> structured markings, it’s possible for multiple to apply and override parts >> of the other. We didn’t want to address this in STIX so simply defined what >> it meant for markings to have precedence and will let the marking >> definitions themselves figure out what that means. Note that, as you said, >> it’s definitely true that markings of different types will not override each >> other. This is why we said that precedence rules only apply to markings of >> the same type. >> >> >> >> When first designing data markings in 1.x and discussing them for 2.0 we >> had very good participation from people in government who mark things every >> day and that led us to the reference approach (among other things). We did >> discuss other approaches, in particular NIEM…I also did a quick search and >> it looks like you actually brought up XEP-0258 at the time. You can review >> here: https://lists.oasis-open.org/archives/cti-users/201511/msg00002.html . >> The conversation was a bit different than applying markings, it was about >> the markings that get applied themselves, and I think is what led to our >> following the FIRST SIG on Information Sharing. >> >> >> >> Anyway, how would you like me to treat this comment? Should I assume it’s >> an objection to the motion for unanimous consent that I made on Friday? If >> so, as a community we need to decide whether we want to open a data markings >> discussion or just hold a ballot to accept what we have. >> >> >> >> John >> >> >> >> From: <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" >> <bret.jordan@bluecoat.com> >> Date: Sunday, June 12, 2016 at 5:14 PM >> To: Dave Cridland <dave.cridland@surevine.com>, >> "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> >> Subject: Re: [cti-stix] Object Level Markings >> >> >> >> Dave, >> >> >> >> Great comments and questions..... Let me try and fill in some of the >> gaps.... Yes, in STIX 2.0 we will have two types of relationships.... And >> as a general rule most everything will use a relationship in STIX 2.0. >> Nested content in STIX 1.x proved to be a bad design in the wild. >> >> >> >> 1) Embedded references (like created_by_ref and object_markings_ref). >> These references are "facts" that will be known to the TLO. However, like >> you said, a consumer may not have the reference yet, or may not have access >> to the referenced object. For data markings we say, that if you do not have >> the object_markings_ref object, and you can not get it via another TAXII >> call, than you MUST stop processing the TLO. In the real-world, you will >> have out-of-band gates that prevent you from ever sharing threat >> intelligence with someone that does not have access to the same the >> data-markings that you have access to. >> >> >> >> 2) Relationship Objects. These relationships are used for assertions or >> opinions about things. So if you link an Observation to a Campaign, or an >> Incident to an IntrusionSet, you would use one of these external >> relationships to link it together. This will allow you, in the future, to >> place a confidence score on your assertion that these two things are >> related. It will also allow in the future for others to potentially >> down-vote your assertions. >> >> >> >> Bret >> >> >> >> ________________________________ >> >> From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on >> behalf of Dave Cridland <dave.cridland@surevine.com> >> Sent: Sunday, June 12, 2016 7:09 AM >> To: cti-stix@lists.oasis-open.org >> Subject: [cti-stix] Object Level Markings >> >> >> >> Hi folks, >> >> I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me >> if I'm missing something, or retracing your steps, or going about things to >> wrong way. >> >> The current section 6.5 appears to discuss aspects of object level >> markings, and suggests these might cover both legal permissioning (such as >> Copyright), and MAC systems (such as security labelling). Mixing the two is >> interesting - I hadn't considered this but it makes sense. >> >> Also, the system operates by reference. This is going to be very difficult >> to manage, and is traditionally avoided in most cases. This is especially >> true if the referenced label data for the marking is not present within the >> same transmission, since automated tooling for MAC will become extremely >> complex (and complexity begets unhappy accreditors). >> >> Has the group considered prior art in this space? I'm thinking >> particularly of XMPP's XEP-0258, but others may also apply. I'm particularly >> keen to ensure that multipolicy systems will work effectively, since I see >> that as being very likely in the CTI world shortly. >> >> As for multiple orthogonal rules - I don't understand where precedence >> comes into this. Taking Copyright as an example, if one derives a work from >> an existing work, the copyright changes, and the license may also change - I >> don't see the benefit in including a list of previous copyright notices, and >> then having the systems decide which one applies. >> >> I would expect that every marking present would need to be adhered to >> (some might not be practical to adhere to programmatically, of course). But >> you can't share something, say, UK SECRET, no matter what the copyright >> notice says - and vice-versa, an unclassified document cannot be shared if >> the copyright license is not available. >> >> Happy to discuss this further, or or out of any particuar call. >> >> Dave.

Dave, We’ve had some discussions about how STIX could transit a guard/CDS…keep in mind that there are very few/no existing guards that can transit JSON anyway, or understand our granular markings approach, so this restriction for transiting a guard is just one among many. It’s almost certain that any time STIX needs to move across domains it would need to be transformed into a more restrictive, XML-based language anyway, where (if necessary) the markings can be kept locally. Even in the JSON version, you could do that by putting the marking-definition in the same bundle as the marked data anyway (I expect this will be very common). It sounds like we need to fail the motion for unanimous consent and talk about this on the next working call. The SC needs to discuss Dave’s concerns and decide whether to open the data markings topic for further discussion/rewrite or whether to just proceed with a ballot on the current approach. John On 6/13/16, 1:20 PM, "cti-stix@lists.oasis-open.org on behalf of Jerome Athias" <cti-stix@lists.oasis-open.org on behalf of athiasjerome@gmail.com> wrote: >Dave, > >Welcome! And good luck here >You could be interested by > https://lists.oasis-open.org/archives/cti-users/201604/msg00005.html > >Regards > > > >2016-06-13 19:10 GMT+03:00 Dave Cridland <dave.cridland@surevine.com>: >> Bret, >> >> There's no semantic difference between a labelling scheme that mandates >> inline and a labelling scheme whose mandatory inline form is a reference to >> external information. If you want a single method, then inlining is the one, >> and the inline form can then optionally consist of just a reference. But if >> it's all references, and the reference is to another object within the same >> PDU, or transaction, then this is mostly a matter of personal taste and not >> a hill for me to die on. >> >> Similarly, while I'd prefer the display marking to be in the JSON payload I >> can live without it. >> >> But I do think there are serious problems with having labelling metadata >> arrive in a different transaction than the TLO (and therefore potentially >> not at all). If you're considering only originators and consumers in a >> corporate setting, this might not seem like a major problem, but if you >> consider border gateways and guard systems, especially within secure >> environments, it can introduce an entirely new failure state. If the source >> system fails before the gateway can ascertain the label of the data, then it >> is unable to know if the data should be forwarded, rejected (with a logged >> exception), or stored pending. From a security standpoint, I don't know what >> happens if an attempt to deference a label reference fails. >> >> That's aside from considerations about cryptographic binding of label >> metadata to the object - we can handwave over that to a degree if we assume >> that we can carry both the TLO and the labelling object within the same >> secure channel (TLS, for example), but otherwise there's a risk that a label >> dereferenced by a later transaction would be different from the intention >> when the object was transmitted, and this isn't something we can specify >> around - we need cryptographic proof. >> >> Dave. >> >> We need to make sure we have "one-way" of doing things. If there are >> multiple ways of doing the same thing, then we will have a fragile design. >> Further, one of our original designs or hopes was that certain common data >> markings might become well known thus reducing the need to re-transmit. >> >> >> I think manual visual inspection of raw JSON is only valid during testing or >> in simple environments. Inspecting the datamarking in reality is an >> implementation issue, not a specification issue. Your tool should be able >> to easily dereference the datamarkings and display them for you. >> >> >> Bret >> >> >> >> >> ________________________________ >> From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on >> behalf of Dave Cridland <dave.cridland@surevine.com> >> Sent: Monday, June 13, 2016 2:20 AM >> To: Wunder, John A. >> Cc: cti-stix@lists.oasis-open.org >> Subject: Re: [cti-stix] Object Level Markings >> >> >> Yes, I'm unclear why the US Gov wants to do labels by reference; I've only >> ever seen that requirement from the US, and never anyone else. I suspect >> it's due to the US having relative few permutations in the labelling scheme, >> whereas the UK (for example) has thousands. >> >> My thought is that while it's certainly useful to move, for example, a full >> copyright license to a reference, in the majority of cases a simple label or >> statement can be presented inline without any problem - it'll likely be >> shorter than the example identifiers given in many cases. >> >> The other issue is that by enforcing everything to be solely by reference, >> the display marking is lost. I worry that this means we lose the ability to >> spot issues by eyeball. >> >> More information: >> >> The display marking is the string that might be printed at the bottom of a >> document, such as "SECRET//NOFORN", or "NATO SECRET". The label is the >> machine readable form, and contains information such as what policy is used. >> Labels come in a variety of formats, from the XML/JSON EDH form that the US >> uses (quite verbose) to the very terse ESS, used in S/MIME for example. This >> latter form is usually much smaller than a display marking; a typical US >> label in ESS form is perhaps 20 bytes - smaller than your identifier. >> >> As far as precedence is concerned, the only case I can think of where this >> might be important is where you have policy translation going on. Say the >> information originates in NATO, for example, as NATO SECRET, and moves to a >> UK domain, where it needs marking as UK SECRET (I simplify of course). The >> "most correct" label is still the NATO one, and the UK Equivalent Label is >> only there for systems that only understand the local policy. You can >> exchange "NATO" for "CERT-US" and "UK" for "FS-ISAC" if you prefer. >> >> But in this case you want to group the labels and mark the equivalent ones >> such that they can easily be ignored. >> >> I can live with being in the rough on referenced labels, though I would >> prefer an option to inline the data. >> >> I'm worried that "precedence" isn't thought through quite enough. >> >> I'm happy to write some text that covers my concerns. >> >> On 12 Jun 2016 11:31 p.m., "Wunder, John A." <jwunder@mitre.org> wrote: >>> >>> To explain a bit more, doing markings by reference was something that was >>> requested by some US government folks who wanted to avoid representing >>> duplicative markings over and over again. While things like TLP are very >>> short and can easily be duplicated over and over, other marking statements >>> (copyrights, government markings, and likely whatever the FIRST SIG creates) >>> will be larger and more complicated and so being able to reference those >>> from 1000 indicators rather than duplicate them seems to make sense. As Bret >>> said, we added normative text to make sure we covered this case. >>> >>> >>> >>> As for precedence, it’s a bit of a hard topic. In some cases (TLP) you >>> really only have one marking that can apply…it doesn’t make sense for an >>> object to have both TLP:GREEN and TLP:RED. In other cases, like terms of >>> use, you have several that apply. In other cases, like more complicated >>> structured markings, it’s possible for multiple to apply and override parts >>> of the other. We didn’t want to address this in STIX so simply defined what >>> it meant for markings to have precedence and will let the marking >>> definitions themselves figure out what that means. Note that, as you said, >>> it’s definitely true that markings of different types will not override each >>> other. This is why we said that precedence rules only apply to markings of >>> the same type. >>> >>> >>> >>> When first designing data markings in 1.x and discussing them for 2.0 we >>> had very good participation from people in government who mark things every >>> day and that led us to the reference approach (among other things). We did >>> discuss other approaches, in particular NIEM…I also did a quick search and >>> it looks like you actually brought up XEP-0258 at the time. You can review >>> here: https://lists.oasis-open.org/archives/cti-users/201511/msg00002.html . >>> The conversation was a bit different than applying markings, it was about >>> the markings that get applied themselves, and I think is what led to our >>> following the FIRST SIG on Information Sharing. >>> >>> >>> >>> Anyway, how would you like me to treat this comment? Should I assume it’s >>> an objection to the motion for unanimous consent that I made on Friday? If >>> so, as a community we need to decide whether we want to open a data markings >>> discussion or just hold a ballot to accept what we have. >>> >>> >>> >>> John >>> >>> >>> >>> From: <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret" >>> <bret.jordan@bluecoat.com> >>> Date: Sunday, June 12, 2016 at 5:14 PM >>> To: Dave Cridland <dave.cridland@surevine.com>, >>> "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> >>> Subject: Re: [cti-stix] Object Level Markings >>> >>> >>> >>> Dave, >>> >>> >>> >>> Great comments and questions..... Let me try and fill in some of the >>> gaps.... Yes, in STIX 2.0 we will have two types of relationships.... And >>> as a general rule most everything will use a relationship in STIX 2.0. >>> Nested content in STIX 1.x proved to be a bad design in the wild. >>> >>> >>> >>> 1) Embedded references (like created_by_ref and object_markings_ref). >>> These references are "facts" that will be known to the TLO. However, like >>> you said, a consumer may not have the reference yet, or may not have access >>> to the referenced object. For data markings we say, that if you do not have >>> the object_markings_ref object, and you can not get it via another TAXII >>> call, than you MUST stop processing the TLO. In the real-world, you will >>> have out-of-band gates that prevent you from ever sharing threat >>> intelligence with someone that does not have access to the same the >>> data-markings that you have access to. >>> >>> >>> >>> 2) Relationship Objects. These relationships are used for assertions or >>> opinions about things. So if you link an Observation to a Campaign, or an >>> Incident to an IntrusionSet, you would use one of these external >>> relationships to link it together. This will allow you, in the future, to >>> place a confidence score on your assertion that these two things are >>> related. It will also allow in the future for others to potentially >>> down-vote your assertions. >>> >>> >>> >>> Bret >>> >>> >>> >>> ________________________________ >>> >>> From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on >>> behalf of Dave Cridland <dave.cridland@surevine.com> >>> Sent: Sunday, June 12, 2016 7:09 AM >>> To: cti-stix@lists.oasis-open.org >>> Subject: [cti-stix] Object Level Markings >>> >>> >>> >>> Hi folks, >>> >>> I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me >>> if I'm missing something, or retracing your steps, or going about things to >>> wrong way. >>> >>> The current section 6.5 appears to discuss aspects of object level >>> markings, and suggests these might cover both legal permissioning (such as >>> Copyright), and MAC systems (such as security labelling). Mixing the two is >>> interesting - I hadn't considered this but it makes sense. >>> >>> Also, the system operates by reference. This is going to be very difficult >>> to manage, and is traditionally avoided in most cases. This is especially >>> true if the referenced label data for the marking is not present within the >>> same transmission, since automated tooling for MAC will become extremely >>> complex (and complexity begets unhappy accreditors). >>> >>> Has the group considered prior art in this space? I'm thinking >>> particularly of XMPP's XEP-0258, but others may also apply. I'm particularly >>> keen to ensure that multipolicy systems will work effectively, since I see >>> that as being very likely in the CTI world shortly. >>> >>> As for multiple orthogonal rules - I don't understand where precedence >>> comes into this. Taking Copyright as an example, if one derives a work from >>> an existing work, the copyright changes, and the license may also change - I >>> don't see the benefit in including a list of previous copyright notices, and >>> then having the systems decide which one applies. >>> >>> I would expect that every marking present would need to be adhered to >>> (some might not be practical to adhere to programmatically, of course). But >>> you can't share something, say, UK SECRET, no matter what the copyright >>> notice says - and vice-versa, an unclassified document cannot be shared if >>> the copyright license is not available. >>> >>> Happy to discuss this further, or or out of any particuar call. >>> >>> Dave. > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >

John, Funnily enough, my recent work with cross-domain guards has transformed XML into JSON for transit - but that point is somewhat moot. If we can mandate that the marking-definition is in the same bundle as the marked data, I can live with the rest. Dave. On 14 June 2016 at 00:02, Wunder, John A. < jwunder@mitre.org > wrote: Dave, We’ve had some discussions about how STIX could transit a guard/CDS…keep in mind that there are very few/no existing guards that can transit JSON anyway, or understand our granular markings approach, so this restriction for transiting a guard is just one among many. It’s almost certain that any time STIX needs to move across domains it would need to be transformed into a more restrictive, XML-based language anyway, where (if necessary) the markings can be kept locally. Even in the JSON version, you could do that by putting the marking-definition in the same bundle as the marked data anyway (I expect this will be very common). It sounds like we need to fail the motion for unanimous consent and talk about this on the next working call. The SC needs to discuss Dave’s concerns and decide whether to open the data markings topic for further discussion/rewrite or whether to just proceed with a ballot on the current approach. John On 6/13/16, 1:20 PM, " cti-stix@lists.oasis-open.org on behalf of Jerome Athias" < cti-stix@lists.oasis-open.org on behalf of athiasjerome@gmail.com > wrote: >Dave, > >Welcome! And good luck here >You could be interested by > https://lists.oasis-open.org/archives/cti-users/201604/msg00005.html > >Regards > > > >2016-06-13 19:10 GMT+03:00 Dave Cridland < dave.cridland@surevine.com >: >> Bret, >> >> There's no semantic difference between a labelling scheme that mandates >> inline and a labelling scheme whose mandatory inline form is a reference to >> external information. If you want a single method, then inlining is the one, >> and the inline form can then optionally consist of just a reference. But if >> it's all references, and the reference is to another object within the same >> PDU, or transaction, then this is mostly a matter of personal taste and not >> a hill for me to die on. >> >> Similarly, while I'd prefer the display marking to be in the JSON payload I >> can live without it. >> >> But I do think there are serious problems with having labelling metadata >> arrive in a different transaction than the TLO (and therefore potentially >> not at all). If you're considering only originators and consumers in a >> corporate setting, this might not seem like a major problem, but if you >> consider border gateways and guard systems, especially within secure >> environments, it can introduce an entirely new failure state. If the source >> system fails before the gateway can ascertain the label of the data, then it >> is unable to know if the data should be forwarded, rejected (with a logged >> exception), or stored pending. From a security standpoint, I don't know what >> happens if an attempt to deference a label reference fails. >> >> That's aside from considerations about cryptographic binding of label >> metadata to the object - we can handwave over that to a degree if we assume >> that we can carry both the TLO and the labelling object within the same >> secure channel (TLS, for example), but otherwise there's a risk that a label >> dereferenced by a later transaction would be different from the intention >> when the object was transmitted, and this isn't something we can specify >> around - we need cryptographic proof. >> >> Dave. >> >> We need to make sure we have "one-way" of doing things.  If there are >> multiple ways of doing the same thing, then we will have a fragile design. >> Further, one of our original designs or hopes was that certain common data >> markings might become well known thus reducing the need to re-transmit. >> >> >> I think manual visual inspection of raw JSON is only valid during testing or >> in simple environments.  Inspecting the datamarking in reality is an >> implementation issue, not a specification issue.  Your tool should be able >> to easily dereference the datamarkings and display them for you. >> >> >> Bret >> >> >> >> >> ________________________________ >> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on >> behalf of Dave Cridland < dave.cridland@surevine.com > >> Sent: Monday, June 13, 2016 2:20 AM >> To: Wunder, John A. >> Cc: cti-stix@lists.oasis-open.org >> Subject: Re: [cti-stix] Object Level Markings >> >> >> Yes, I'm unclear why the US Gov wants to do labels by reference; I've only >> ever seen that requirement from the US, and never anyone else. I suspect >> it's due to the US having relative few permutations in the labelling scheme, >> whereas the UK (for example) has thousands. >> >> My thought is that while it's certainly useful to move, for example, a full >> copyright license to a reference, in the majority of cases a simple label or >> statement can be presented inline without any problem - it'll likely be >> shorter than the example identifiers given in many cases. >> >> The other issue is that by enforcing everything to be solely by reference, >> the display marking is lost. I worry that this means we lose the ability to >> spot issues by eyeball. >> >> More information: >> >> The display marking is the string that might be printed at the bottom of a >> document, such as "SECRET//NOFORN", or "NATO SECRET". The label is the >> machine readable form, and contains information such as what policy is used. >> Labels come in a variety of formats, from the XML/JSON EDH form that the US >> uses (quite verbose) to the very terse ESS, used in S/MIME for example. This >> latter form is usually much smaller than a display marking; a typical US >> label in ESS form is perhaps 20 bytes - smaller than your identifier. >> >> As far as precedence is concerned, the only case I can think of where this >> might be important is where you have policy translation going on. Say the >> information originates in NATO, for example, as NATO SECRET, and moves to a >> UK domain, where it needs marking as UK SECRET (I simplify of course). The >> "most correct" label is still the NATO one, and the UK Equivalent Label is >> only there for systems that only understand the local policy. You can >> exchange "NATO" for "CERT-US" and "UK" for "FS-ISAC" if you prefer. >> >> But in this case you want to group the labels and mark the equivalent ones >> such that they can easily be ignored. >> >> I can live with being in the rough on referenced labels, though I would >> prefer an option to inline the data. >> >> I'm worried that "precedence" isn't thought through quite enough. >> >> I'm happy to write some text that covers my concerns. >> >> On 12 Jun 2016 11:31 p.m., "Wunder, John A." < jwunder@mitre.org > wrote: >>> >>> To explain a bit more, doing markings by reference was something that was >>> requested by some US government folks who wanted to avoid representing >>> duplicative markings over and over again. While things like TLP are very >>> short and can easily be duplicated over and over, other marking statements >>> (copyrights, government markings, and likely whatever the FIRST SIG creates) >>> will be larger and more complicated and so being able to reference those >>> from 1000 indicators rather than duplicate them seems to make sense. As Bret >>> said, we added normative text to make sure we covered this case. >>> >>> >>> >>> As for precedence, it’s a bit of a hard topic. In some cases (TLP) you >>> really only have one marking that can apply…it doesn’t make sense for an >>> object to have both TLP:GREEN and TLP:RED. In other cases, like terms of >>> use, you have several that apply. In other cases, like more complicated >>> structured markings, it’s possible for multiple to apply and override parts >>> of the other. We didn’t want to address this in STIX so simply defined what >>> it meant for markings to have precedence and will let the marking >>> definitions themselves figure out what that means. Note that, as you said, >>> it’s definitely true that markings of different types will not override each >>> other. This is why we said that precedence rules only apply to markings of >>> the same type. >>> >>> >>> >>> When first designing data markings in 1.x and discussing them for 2.0 we >>> had very good participation from people in government who mark things every >>> day and that led us to the reference approach (among other things). We did >>> discuss other approaches, in particular NIEM…I also did a quick search and >>> it looks like you actually brought up XEP-0258 at the time. You can review >>> here: https://lists.oasis-open.org/archives/cti-users/201511/msg00002.html . >>> The conversation was a bit different than applying markings, it was about >>> the markings that get applied themselves, and I think is what led to our >>> following the FIRST SIG on Information Sharing. >>> >>> >>> >>> Anyway, how would you like me to treat this comment? Should I assume it’s >>> an objection to the motion for unanimous consent that I made on Friday? If >>> so, as a community we need to decide whether we want to open a data markings >>> discussion or just hold a ballot to accept what we have. >>> >>> >>> >>> John >>> >>> >>> >>> From: < cti-stix@lists.oasis-open.org > on behalf of "Jordan, Bret" >>> < bret.jordan@bluecoat.com > >>> Date: Sunday, June 12, 2016 at 5:14 PM >>> To: Dave Cridland < dave.cridland@surevine.com >, >>> " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > >>> Subject: Re: [cti-stix] Object Level Markings >>> >>> >>> >>> Dave, >>> >>> >>> >>> Great comments and questions.....   Let me try and fill in some of the >>> gaps....  Yes, in STIX 2.0 we will have two types of relationships....  And >>> as a general rule most everything will use a relationship in STIX 2.0. >>> Nested content in STIX 1.x proved to be a bad design in the wild. >>> >>> >>> >>> 1) Embedded references (like created_by_ref and object_markings_ref). >>> These references are "facts" that will be known to the TLO.  However, like >>> you said, a consumer may not have the reference yet, or may not have access >>> to the referenced object.  For data markings we say, that if you do not have >>> the object_markings_ref object, and you can not get it via another TAXII >>> call, than you MUST stop processing the TLO.  In the real-world, you will >>> have out-of-band gates that prevent you from ever sharing threat >>> intelligence with someone that does not have access to the same the >>> data-markings that you have access to. >>> >>> >>> >>> 2) Relationship Objects.  These relationships are used for assertions or >>> opinions about things.  So if you link an Observation to a Campaign, or an >>> Incident to an IntrusionSet, you would use one of these external >>> relationships to link it together.  This will allow you, in the future, to >>> place a confidence score on your assertion that these two things are >>> related.  It will also allow in the future for others to potentially >>> down-vote your assertions. >>> >>> >>> >>> Bret >>> >>> >>> >>> ________________________________ >>> >>> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on >>> behalf of Dave Cridland < dave.cridland@surevine.com > >>> Sent: Sunday, June 12, 2016 7:09 AM >>> To: cti-stix@lists.oasis-open.org >>> Subject: [cti-stix] Object Level Markings >>> >>> >>> >>> Hi folks, >>> >>> I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me >>> if I'm missing something, or retracing your steps, or going about things to >>> wrong way. >>> >>> The current section 6.5 appears to discuss aspects of object level >>> markings, and suggests these might cover both legal permissioning (such as >>> Copyright), and MAC systems (such as security labelling). Mixing the two is >>> interesting - I hadn't considered this but it makes sense. >>> >>> Also, the system operates by reference. This is going to be very difficult >>> to manage, and is traditionally avoided in most cases. This is especially >>> true if the referenced label data for the marking is not present within the >>> same transmission, since automated tooling for MAC will become extremely >>> complex (and complexity begets unhappy accreditors). >>> >>> Has the group considered prior art in this space? I'm thinking >>> particularly of XMPP's XEP-0258, but others may also apply. I'm particularly >>> keen to ensure that multipolicy systems will work effectively, since I see >>> that as being very likely in the CTI world shortly. >>> >>> As for multiple orthogonal rules - I don't understand where precedence >>> comes into this. Taking Copyright as an example, if one derives a work from >>> an existing work, the copyright changes, and the license may also change - I >>> don't see the benefit in including a list of previous copyright notices, and >>> then having the systems decide which one applies. >>> >>> I would expect that every marking present would need to be adhered to >>> (some might not be practical to adhere to programmatically, of course). But >>> you can't share something, say, UK SECRET, no matter what the copyright >>> notice says - and vice-versa, an unclassified document cannot be shared if >>> the copyright license is not available. >>> >>> Happy to discuss this further, or or out of any particuar call. >>> >>> Dave. > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > -- Dave Cridland phone   +448454681066 email   dave.cridland@surevine.com skype   dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us.

>> But I do think there are serious problems with having labelling metadata >> arrive in a different transaction than the TLO (and therefore potentially >> not at all). If you're considering only originators and consumers in a >> corporate setting, this might not seem like a major problem, but if you >> consider border gateways and guard systems, especially within secure >> environments, it can introduce an entirely new failure state. If the source >> system fails before the gateway can ascertain the label of the data, then it >> is unable to know if the data should be forwarded, rejected (with a logged >> exception), or stored pending. From a security standpoint, I don't know what >> happens if an attempt to deference a label reference fails. I am afraid I do not understand at all why we would be concerned with "label de-referencing" in STIX. As a result - I don't really understand this message thread. Can someone expand on the use cases in finer detail? What is behind this "de-referenced label", that a recipient would be concerned with? Is it a ruleset that software is expected to enforce? Is it a plain english document? What is it and who is consuming it, and to what end? IE - I label a piece of content " NATO SECRET ", great. But the actual definition of " NATO SECRET " and what that means and what rules need to be applied, how any system (including guard systems) may or may not behave when it receives that, does not actually need to be sent in order for the recipient to enforce it. The idea that we will send a giant sequence of rule states that NATO SECRET must follow to the recipient does not make any sense to me whatsoever - how are you going to even know if they are followed? You won't... so why bother sending them... if you are sending someone NATO SECRET information you have to de-facto assume that the recipient knows how to handle that marking. - Jason Keirstead STSM, 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 Dave Cridland ---06/14/2016 09:31:55 AM---John, Funnily enough, my recent work with cross-domain guards has transformed XML From: Dave Cridland <dave.cridland@surevine.com> To: "Wunder, John A." <jwunder@mitre.org> Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date: 06/14/2016 09:31 AM Subject: Re: [cti-stix] Object Level Markings Sent by: <cti-stix@lists.oasis-open.org> John, Funnily enough, my recent work with cross-domain guards has transformed XML into JSON for transit - but that point is somewhat moot. If we can mandate that the marking-definition is in the same bundle as the marked data, I can live with the rest. Dave. On 14 June 2016 at 00:02, Wunder, John A. < jwunder@mitre.org > wrote: Dave, We’ve had some discussions about how STIX could transit a guard/CDS…keep in mind that there are very few/no existing guards that can transit JSON anyway, or understand our granular markings approach, so this restriction for transiting a guard is just one among many. It’s almost certain that any time STIX needs to move across domains it would need to be transformed into a more restrictive, XML-based language anyway, where (if necessary) the markings can be kept locally. Even in the JSON version, you could do that by putting the marking-definition in the same bundle as the marked data anyway (I expect this will be very common). It sounds like we need to fail the motion for unanimous consent and talk about this on the next working call. The SC needs to discuss Dave’s concerns and decide whether to open the data markings topic for further discussion/rewrite or whether to just proceed with a ballot on the current approach. John On 6/13/16, 1:20 PM, " cti-stix@lists.oasis-open.org on behalf of Jerome Athias" < cti-stix@lists.oasis-open.org on behalf of athiasjerome@gmail.com > wrote: >Dave, > >Welcome! And good luck here >You could be interested by > https://lists.oasis-open.org/archives/cti-users/201604/msg00005.html > >Regards > > > >2016-06-13 19:10 GMT+03:00 Dave Cridland < dave.cridland@surevine.com >: >> Bret, >> >> There's no semantic difference between a labelling scheme that mandates >> inline and a labelling scheme whose mandatory inline form is a reference to >> external information. If you want a single method, then inlining is the one, >> and the inline form can then optionally consist of just a reference. But if >> it's all references, and the reference is to another object within the same >> PDU, or transaction, then this is mostly a matter of personal taste and not >> a hill for me to die on. >> >> Similarly, while I'd prefer the display marking to be in the JSON payload I >> can live without it. >> >> But I do think there are serious problems with having labelling metadata >> arrive in a different transaction than the TLO (and therefore potentially >> not at all). If you're considering only originators and consumers in a >> corporate setting, this might not seem like a major problem, but if you >> consider border gateways and guard systems, especially within secure >> environments, it can introduce an entirely new failure state. If the source >> system fails before the gateway can ascertain the label of the data, then it >> is unable to know if the data should be forwarded, rejected (with a logged >> exception), or stored pending. From a security standpoint, I don't know what >> happens if an attempt to deference a label reference fails. >> >> That's aside from considerations about cryptographic binding of label >> metadata to the object - we can handwave over that to a degree if we assume >> that we can carry both the TLO and the labelling object within the same >> secure channel (TLS, for example), but otherwise there's a risk that a label >> dereferenced by a later transaction would be different from the intention >> when the object was transmitted, and this isn't something we can specify >> around - we need cryptographic proof. >> >> Dave. >> >> We need to make sure we have "one-way" of doing things.  If there are >> multiple ways of doing the same thing, then we will have a fragile design. >> Further, one of our original designs or hopes was that certain common data >> markings might become well known thus reducing the need to re-transmit. >> >> >> I think manual visual inspection of raw JSON is only valid during testing or >> in simple environments.  Inspecting the datamarking in reality is an >> implementation issue, not a specification issue.  Your tool should be able >> to easily dereference the datamarkings and display them for you. >> >> >> Bret >> >> >> >> >> ________________________________ >> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on >> behalf of Dave Cridland < dave.cridland@surevine.com > >> Sent: Monday, June 13, 2016 2:20 AM >> To: Wunder, John A. >> Cc: cti-stix@lists.oasis-open.org >> Subject: Re: [cti-stix] Object Level Markings >> >> >> Yes, I'm unclear why the US Gov wants to do labels by reference; I've only >> ever seen that requirement from the US, and never anyone else. I suspect >> it's due to the US having relative few permutations in the labelling scheme, >> whereas the UK (for example) has thousands. >> >> My thought is that while it's certainly useful to move, for example, a full >> copyright license to a reference, in the majority of cases a simple label or >> statement can be presented inline without any problem - it'll likely be >> shorter than the example identifiers given in many cases. >> >> The other issue is that by enforcing everything to be solely by reference, >> the display marking is lost. I worry that this means we lose the ability to >> spot issues by eyeball. >> >> More information: >> >> The display marking is the string that might be printed at the bottom of a >> document, such as "SECRET//NOFORN", or "NATO SECRET". The label is the >> machine readable form, and contains information such as what policy is used. >> Labels come in a variety of formats, from the XML/JSON EDH form that the US >> uses (quite verbose) to the very terse ESS, used in S/MIME for example. This >> latter form is usually much smaller than a display marking; a typical US >> label in ESS form is perhaps 20 bytes - smaller than your identifier. >> >> As far as precedence is concerned, the only case I can think of where this >> might be important is where you have policy translation going on. Say the >> information originates in NATO, for example, as NATO SECRET, and moves to a >> UK domain, where it needs marking as UK SECRET (I simplify of course). The >> "most correct" label is still the NATO one, and the UK Equivalent Label is >> only there for systems that only understand the local policy. You can >> exchange "NATO" for "CERT-US" and "UK" for "FS-ISAC" if you prefer. >> >> But in this case you want to group the labels and mark the equivalent ones >> such that they can easily be ignored. >> >> I can live with being in the rough on referenced labels, though I would >> prefer an option to inline the data. >> >> I'm worried that "precedence" isn't thought through quite enough. >> >> I'm happy to write some text that covers my concerns. >> >> On 12 Jun 2016 11:31 p.m., "Wunder, John A." < jwunder@mitre.org > wrote: >>> >>> To explain a bit more, doing markings by reference was something that was >>> requested by some US government folks who wanted to avoid representing >>> duplicative markings over and over again. While things like TLP are very >>> short and can easily be duplicated over and over, other marking statements >>> (copyrights, government markings, and likely whatever the FIRST SIG creates) >>> will be larger and more complicated and so being able to reference those >>> from 1000 indicators rather than duplicate them seems to make sense. As Bret >>> said, we added normative text to make sure we covered this case. >>> >>> >>> >>> As for precedence, it’s a bit of a hard topic. In some cases (TLP) you >>> really only have one marking that can apply…it doesn’t make sense for an >>> object to have both TLP:GREEN and TLP:RED. In other cases, like terms of >>> use, you have several that apply. In other cases, like more complicated >>> structured markings, it’s possible for multiple to apply and override parts >>> of the other. We didn’t want to address this in STIX so simply defined what >>> it meant for markings to have precedence and will let the marking >>> definitions themselves figure out what that means. Note that, as you said, >>> it’s definitely true that markings of different types will not override each >>> other. This is why we said that precedence rules only apply to markings of >>> the same type. >>> >>> >>> >>> When first designing data markings in 1.x and discussing them for 2.0 we >>> had very good participation from people in government who mark things every >>> day and that led us to the reference approach (among other things). We did >>> discuss other approaches, in particular NIEM…I also did a quick search and >>> it looks like you actually brought up XEP-0258 at the time. You can review >>> here: https://lists.oasis-open.org/archives/cti-users/201511/msg00002.html . >>> The conversation was a bit different than applying markings, it was about >>> the markings that get applied themselves, and I think is what led to our >>> following the FIRST SIG on Information Sharing. >>> >>> >>> >>> Anyway, how would you like me to treat this comment? Should I assume it’s >>> an objection to the motion for unanimous consent that I made on Friday? If >>> so, as a community we need to decide whether we want to open a data markings >>> discussion or just hold a ballot to accept what we have. >>> >>> >>> >>> John >>> >>> >>> >>> From: < cti-stix@lists.oasis-open.org > on behalf of "Jordan, Bret" >>> < bret.jordan@bluecoat.com > >>> Date: Sunday, June 12, 2016 at 5:14 PM >>> To: Dave Cridland < dave.cridland@surevine.com >, >>> " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > >>> Subject: Re: [cti-stix] Object Level Markings >>> >>> >>> >>> Dave, >>> >>> >>> >>> Great comments and questions.....   Let me try and fill in some of the >>> gaps....  Yes, in STIX 2.0 we will have two types of relationships....  And >>> as a general rule most everything will use a relationship in STIX 2.0. >>> Nested content in STIX 1.x proved to be a bad design in the wild. >>> >>> >>> >>> 1) Embedded references (like created_by_ref and object_markings_ref). >>> These references are "facts" that will be known to the TLO.  However, like >>> you said, a consumer may not have the reference yet, or may not have access >>> to the referenced object.  For data markings we say, that if you do not have >>> the object_markings_ref object, and you can not get it via another TAXII >>> call, than you MUST stop processing the TLO.  In the real-world, you will >>> have out-of-band gates that prevent you from ever sharing threat >>> intelligence with someone that does not have access to the same the >>> data-markings that you have access to. >>> >>> >>> >>> 2) Relationship Objects.  These relationships are used for assertions or >>> opinions about things.  So if you link an Observation to a Campaign, or an >>> Incident to an IntrusionSet, you would use one of these external >>> relationships to link it together.  This will allow you, in the future, to >>> place a confidence score on your assertion that these two things are >>> related.  It will also allow in the future for others to potentially >>> down-vote your assertions. >>> >>> >>> >>> Bret >>> >>> >>> >>> ________________________________ >>> >>> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on >>> behalf of Dave Cridland < dave.cridland@surevine.com > >>> Sent: Sunday, June 12, 2016 7:09 AM >>> To: cti-stix@lists.oasis-open.org >>> Subject: [cti-stix] Object Level Markings >>> >>> >>> >>> Hi folks, >>> >>> I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me >>> if I'm missing something, or retracing your steps, or going about things to >>> wrong way. >>> >>> The current section 6.5 appears to discuss aspects of object level >>> markings, and suggests these might cover both legal permissioning (such as >>> Copyright), and MAC systems (such as security labelling). Mixing the two is >>> interesting - I hadn't considered this but it makes sense. >>> >>> Also, the system operates by reference. This is going to be very difficult >>> to manage, and is traditionally avoided in most cases. This is especially >>> true if the referenced label data for the marking is not present within the >>> same transmission, since automated tooling for MAC will become extremely >>> complex (and complexity begets unhappy accreditors). >>> >>> Has the group considered prior art in this space? I'm thinking >>> particularly of XMPP's XEP-0258, but others may also apply. I'm particularly >>> keen to ensure that multipolicy systems will work effectively, since I see >>> that as being very likely in the CTI world shortly. >>> >>> As for multiple orthogonal rules - I don't understand where precedence >>> comes into this. Taking Copyright as an example, if one derives a work from >>> an existing work, the copyright changes, and the license may also change - I >>> don't see the benefit in including a list of previous copyright notices, and >>> then having the systems decide which one applies. >>> >>> I would expect that every marking present would need to be adhered to >>> (some might not be practical to adhere to programmatically, of course). But >>> you can't share something, say, UK SECRET, no matter what the copyright >>> notice says - and vice-versa, an unclassified document cannot be shared if >>> the copyright license is not available. >>> >>> Happy to discuss this further, or or out of any particuar call. >>> >>> Dave. > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > -- Dave Cridland phone  +448454681066 email   dave.cridland@surevine.com skype  dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us.

Jason, Yes, if we were sending that kind of information it would be insane. There's three items of information associated with the access control decision: * The Label, which in your example was "NATO SECRET". In NATO's preferred syntax, that's actually a shortish bit of XML, usually around half a kilobyte. * The Clearance, which a guard would typically have as a constant value, and an endpoint would handle via LDAP lookups, etc. * The Policy, which actually defines the rules, and again, for NATO, would be XML - but much larger. NATO's policy is 86k, for instance. The part I'm suggesting needs to be kept with the data is only the first of these, the label. An example label, in NATO's ADatP-4774 format, is here: https://github.com/surevine/spiffing/blob/stanag-4774/test-data/nato-4774-17-1.nato That repository also has (MIT-licensed) code that'll produce a display marking from it (in this case "NATO UNCLASSIFIED Releasable to ISAF, KFOR, RESOLUTE SUPPORT"), which it does from the policy information file, which is similar to that available here in Open XML SPIF format: https://github.com/surevine/spiffing/blob/stanag-4774/test-data/nato-4774-policy.xml We won't be sending around the policy - we expect anything that needs that to have it already. Similarly, clearances make no sense to send around at all - they'd be selected and evaluated locally in every case. But typical specifications for this require that the label metadata is "bound" with the data, for example in X.841 §6.1.3, or ADatP-4778. I'm proposing that in order to side-step the need for cryptographic binding at the object level, we must at minimum keep the label metadata within the same bundle, and rely on the TLS channel to provide hop-by-hop integrity, and claiming we're doing X.841§6.1.3.1. That's really the minimum I think I can get past an accreditor. Does this help clarify a little? Dave. On 14 June 2016 at 16:55, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: >> But I do think there are serious problems with having labelling metadata >> arrive in a different transaction than the TLO (and therefore potentially >> not at all). If you're considering only originators and consumers in a >> corporate setting, this might not seem like a major problem, but if you >> consider border gateways and guard systems, especially within secure >> environments, it can introduce an entirely new failure state. If the source >> system fails before the gateway can ascertain the label of the data, then it >> is unable to know if the data should be forwarded, rejected (with a logged >> exception), or stored pending. From a security standpoint, I don't know what >> happens if an attempt to deference a label reference fails. I am afraid I do not understand at all why we would be concerned with "label de-referencing" in STIX. As a result - I don't really understand this message thread. Can someone expand on the use cases in finer detail? What is behind this "de-referenced label", that a recipient would be concerned with? Is it a ruleset that software is expected to enforce? Is it a plain english document? What is it and who is consuming it, and to what end? IE - I label a piece of content " NATO SECRET ", great. But the actual definition of " NATO SECRET " and what that means and what rules need to be applied, how any system (including guard systems) may or may not behave when it receives that, does not actually need to be sent in order for the recipient to enforce it. The idea that we will send a giant sequence of rule states that NATO SECRET must follow to the recipient does not make any sense to me whatsoever - how are you going to even know if they are followed? You won't... so why bother sending them... if you are sending someone NATO SECRET information you have to de-facto assume that the recipient knows how to handle that marking. - Jason Keirstead STSM, 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 Dave Cridland ---06/14/2016 09:31:55 AM---John, Funnily enough, my recent work with cross-domain guards has transformed XML From: Dave Cridland < dave.cridland@surevine.com > To: "Wunder, John A." < jwunder@mitre.org > Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Date: 06/14/2016 09:31 AM Subject: Re: [cti-stix] Object Level Markings Sent by: < cti-stix@lists.oasis-open.org > John, Funnily enough, my recent work with cross-domain guards has transformed XML into JSON for transit - but that point is somewhat moot. If we can mandate that the marking-definition is in the same bundle as the marked data, I can live with the rest. Dave. On 14 June 2016 at 00:02, Wunder, John A. < jwunder@mitre.org > wrote: Dave, We’ve had some discussions about how STIX could transit a guard/CDS…keep in mind that there are very few/no existing guards that can transit JSON anyway, or understand our granular markings approach, so this restriction for transiting a guard is just one among many. It’s almost certain that any time STIX needs to move across domains it would need to be transformed into a more restrictive, XML-based language anyway, where (if necessary) the markings can be kept locally. Even in the JSON version, you could do that by putting the marking-definition in the same bundle as the marked data anyway (I expect this will be very common). It sounds like we need to fail the motion for unanimous consent and talk about this on the next working call. The SC needs to discuss Dave’s concerns and decide whether to open the data markings topic for further discussion/rewrite or whether to just proceed with a ballot on the current approach. John On 6/13/16, 1:20 PM, " cti-stix@lists.oasis-open.org on behalf of Jerome Athias" < cti-stix@lists.oasis-open.org on behalf of athiasjerome@gmail.com > wrote: >Dave, > >Welcome! And good luck here >You could be interested by > https://lists.oasis-open.org/archives/cti-users/201604/msg00005.html > >Regards > > > >2016-06-13 19:10 GMT+03:00 Dave Cridland < dave.cridland@surevine.com >: >> Bret, >> >> There's no semantic difference between a labelling scheme that mandates >> inline and a labelling scheme whose mandatory inline form is a reference to >> external information. If you want a single method, then inlining is the one, >> and the inline form can then optionally consist of just a reference. But if >> it's all references, and the reference is to another object within the same >> PDU, or transaction, then this is mostly a matter of personal taste and not >> a hill for me to die on. >> >> Similarly, while I'd prefer the display marking to be in the JSON payload I >> can live without it. >> >> But I do think there are serious problems with having labelling metadata >> arrive in a different transaction than the TLO (and therefore potentially >> not at all). If you're considering only originators and consumers in a >> corporate setting, this might not seem like a major problem, but if you >> consider border gateways and guard systems, especially within secure >> environments, it can introduce an entirely new failure state. If the source >> system fails before the gateway can ascertain the label of the data, then it >> is unable to know if the data should be forwarded, rejected (with a logged >> exception), or stored pending. From a security standpoint, I don't know what >> happens if an attempt to deference a label reference fails. >> >> That's aside from considerations about cryptographic binding of label >> metadata to the object - we can handwave over that to a degree if we assume >> that we can carry both the TLO and the labelling object within the same >> secure channel (TLS, for example), but otherwise there's a risk that a label >> dereferenced by a later transaction would be different from the intention >> when the object was transmitted, and this isn't something we can specify >> around - we need cryptographic proof. >> >> Dave. >> >> We need to make sure we have "one-way" of doing things.  If there are >> multiple ways of doing the same thing, then we will have a fragile design. >> Further, one of our original designs or hopes was that certain common data >> markings might become well known thus reducing the need to re-transmit. >> >> >> I think manual visual inspection of raw JSON is only valid during testing or >> in simple environments.  Inspecting the datamarking in reality is an >> implementation issue, not a specification issue.  Your tool should be able >> to easily dereference the datamarkings and display them for you. >> >> >> Bret >> >> >> >> >> ________________________________ >> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on >> behalf of Dave Cridland < dave.cridland@surevine.com > >> Sent: Monday, June 13, 2016 2:20 AM >> To: Wunder, John A. >> Cc: cti-stix@lists.oasis-open.org >> Subject: Re: [cti-stix] Object Level Markings >> >> >> Yes, I'm unclear why the US Gov wants to do labels by reference; I've only >> ever seen that requirement from the US, and never anyone else. I suspect >> it's due to the US having relative few permutations in the labelling scheme, >> whereas the UK (for example) has thousands. >> >> My thought is that while it's certainly useful to move, for example, a full >> copyright license to a reference, in the majority of cases a simple label or >> statement can be presented inline without any problem - it'll likely be >> shorter than the example identifiers given in many cases. >> >> The other issue is that by enforcing everything to be solely by reference, >> the display marking is lost. I worry that this means we lose the ability to >> spot issues by eyeball. >> >> More information: >> >> The display marking is the string that might be printed at the bottom of a >> document, such as "SECRET//NOFORN", or "NATO SECRET". The label is the >> machine readable form, and contains information such as what policy is used. >> Labels come in a variety of formats, from the XML/JSON EDH form that the US >> uses (quite verbose) to the very terse ESS, used in S/MIME for example. This >> latter form is usually much smaller than a display marking; a typical US >> label in ESS form is perhaps 20 bytes - smaller than your identifier. >> >> As far as precedence is concerned, the only case I can think of where this >> might be important is where you have policy translation going on. Say the >> information originates in NATO, for example, as NATO SECRET, and moves to a >> UK domain, where it needs marking as UK SECRET (I simplify of course). The >> "most correct" label is still the NATO one, and the UK Equivalent Label is >> only there for systems that only understand the local policy. You can >> exchange "NATO" for "CERT-US" and "UK" for "FS-ISAC" if you prefer. >> >> But in this case you want to group the labels and mark the equivalent ones >> such that they can easily be ignored. >> >> I can live with being in the rough on referenced labels, though I would >> prefer an option to inline the data. >> >> I'm worried that "precedence" isn't thought through quite enough. >> >> I'm happy to write some text that covers my concerns. >> >> On 12 Jun 2016 11:31 p.m., "Wunder, John A." < jwunder@mitre.org > wrote: >>> >>> To explain a bit more, doing markings by reference was something that was >>> requested by some US government folks who wanted to avoid representing >>> duplicative markings over and over again. While things like TLP are very >>> short and can easily be duplicated over and over, other marking statements >>> (copyrights, government markings, and likely whatever the FIRST SIG creates) >>> will be larger and more complicated and so being able to reference those >>> from 1000 indicators rather than duplicate them seems to make sense. As Bret >>> said, we added normative text to make sure we covered this case. >>> >>> >>> >>> As for precedence, it’s a bit of a hard topic. In some cases (TLP) you >>> really only have one marking that can apply…it doesn’t make sense for an >>> object to have both TLP:GREEN and TLP:RED. In other cases, like terms of >>> use, you have several that apply. In other cases, like more complicated >>> structured markings, it’s possible for multiple to apply and override parts >>> of the other. We didn’t want to address this in STIX so simply defined what >>> it meant for markings to have precedence and will let the marking >>> definitions themselves figure out what that means. Note that, as you said, >>> it’s definitely true that markings of different types will not override each >>> other. This is why we said that precedence rules only apply to markings of >>> the same type. >>> >>> >>> >>> When first designing data markings in 1.x and discussing them for 2.0 we >>> had very good participation from people in government who mark things every >>> day and that led us to the reference approach (among other things). We did >>> discuss other approaches, in particular NIEM…I also did a quick search and >>> it looks like you actually brought up XEP-0258 at the time. You can review >>> here: https://lists.oasis-open.org/archives/cti-users/201511/msg00002.html . >>> The conversation was a bit different than applying markings, it was about >>> the markings that get applied themselves, and I think is what led to our >>> following the FIRST SIG on Information Sharing. >>> >>> >>> >>> Anyway, how would you like me to treat this comment? Should I assume it’s >>> an objection to the motion for unanimous consent that I made on Friday? If >>> so, as a community we need to decide whether we want to open a data markings >>> discussion or just hold a ballot to accept what we have. >>> >>> >>> >>> John >>> >>> >>> >>> From: < cti-stix@lists.oasis-open.org > on behalf of "Jordan, Bret" >>> < bret.jordan@bluecoat.com > >>> Date: Sunday, June 12, 2016 at 5:14 PM >>> To: Dave Cridland < dave.cridland@surevine.com >, >>> " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > >>> Subject: Re: [cti-stix] Object Level Markings >>> >>> >>> >>> Dave, >>> >>> >>> >>> Great comments and questions.....   Let me try and fill in some of the >>> gaps....  Yes, in STIX 2.0 we will have two types of relationships....  And >>> as a general rule most everything will use a relationship in STIX 2.0. >>> Nested content in STIX 1.x proved to be a bad design in the wild. >>> >>> >>> >>> 1) Embedded references (like created_by_ref and object_markings_ref). >>> These references are "facts" that will be known to the TLO.  However, like >>> you said, a consumer may not have the reference yet, or may not have access >>> to the referenced object.  For data markings we say, that if you do not have >>> the object_markings_ref object, and you can not get it via another TAXII >>> call, than you MUST stop processing the TLO.  In the real-world, you will >>> have out-of-band gates that prevent you from ever sharing threat >>> intelligence with someone that does not have access to the same the >>> data-markings that you have access to. >>> >>> >>> >>> 2) Relationship Objects.  These relationships are used for assertions or >>> opinions about things.  So if you link an Observation to a Campaign, or an >>> Incident to an IntrusionSet, you would use one of these external >>> relationships to link it together.  This will allow you, in the future, to >>> place a confidence score on your assertion that these two things are >>> related.  It will also allow in the future for others to potentially >>> down-vote your assertions. >>> >>> >>> >>> Bret >>> >>> >>> >>> ________________________________ >>> >>> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on >>> behalf of Dave Cridland < dave.cridland@surevine.com > >>> Sent: Sunday, June 12, 2016 7:09 AM >>> To: cti-stix@lists.oasis-open.org >>> Subject: [cti-stix] Object Level Markings >>> >>> >>> >>> Hi folks, >>> >>> I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me >>> if I'm missing something, or retracing your steps, or going about things to >>> wrong way. >>> >>> The current section 6.5 appears to discuss aspects of object level >>> markings, and suggests these might cover both legal permissioning (such as >>> Copyright), and MAC systems (such as security labelling). Mixing the two is >>> interesting - I hadn't considered this but it makes sense. >>> >>> Also, the system operates by reference. This is going to be very difficult >>> to manage, and is traditionally avoided in most cases. This is especially >>> true if the referenced label data for the marking is not present within the >>> same transmission, since automated tooling for MAC will become extremely >>> complex (and complexity begets unhappy accreditors). >>> >>> Has the group considered prior art in this space? I'm thinking >>> particularly of XMPP's XEP-0258, but others may also apply. I'm particularly >>> keen to ensure that multipolicy systems will work effectively, since I see >>> that as being very likely in the CTI world shortly. >>> >>> As for multiple orthogonal rules - I don't understand where precedence >>> comes into this. Taking Copyright as an example, if one derives a work from >>> an existing work, the copyright changes, and the license may also change - I >>> don't see the benefit in including a list of previous copyright notices, and >>> then having the systems decide which one applies. >>> >>> I would expect that every marking present would need to be adhered to >>> (some might not be practical to adhere to programmatically, of course). But >>> you can't share something, say, UK SECRET, no matter what the copyright >>> notice says - and vice-versa, an unclassified document cannot be shared if >>> the copyright license is not available. >>> >>> Happy to discuss this further, or or out of any particuar call. >>> >>> Dave. > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > -- Dave Cridland phone   +448454681066 email   dave.cridland@surevine.com skype  dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us. -- Dave Cridland phone   +448454681066 email   dave.cridland@surevine.com skype   dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us.

Yes thanks Dave, this clarifies a lot. - Jason Keirstead STSM, 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 Dave Cridland ---06/14/2016 01:51:41 PM---Jason, Yes, if we were sending that kind of information it would be insane. From: Dave Cridland <dave.cridland@surevine.com> To: Jason Keirstead/CanEast/IBM@IBMCA Cc: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date: 06/14/2016 01:51 PM Subject: Re: [cti-stix] Object Level Markings Sent by: <cti-stix@lists.oasis-open.org> Jason, Yes, if we were sending that kind of information it would be insane. There's three items of information associated with the access control decision: * The Label, which in your example was "NATO SECRET". In NATO's preferred syntax, that's actually a shortish bit of XML, usually around half a kilobyte. * The Clearance, which a guard would typically have as a constant value, and an endpoint would handle via LDAP lookups, etc. * The Policy, which actually defines the rules, and again, for NATO, would be XML - but much larger. NATO's policy is 86k, for instance. The part I'm suggesting needs to be kept with the data is only the first of these, the label. An example label, in NATO's ADatP-4774 format, is here: https://github.com/surevine/spiffing/blob/stanag-4774/test-data/nato-4774-17-1.nato That repository also has (MIT-licensed) code that'll produce a display marking from it (in this case "NATO UNCLASSIFIED Releasable to ISAF, KFOR, RESOLUTE SUPPORT"), which it does from the policy information file, which is similar to that available here in Open XML SPIF format: https://github.com/surevine/spiffing/blob/stanag-4774/test-data/nato-4774-policy.xml We won't be sending around the policy - we expect anything that needs that to have it already. Similarly, clearances make no sense to send around at all - they'd be selected and evaluated locally in every case. But typical specifications for this require that the label metadata is "bound" with the data, for example in X.841 §6.1.3, or ADatP-4778. I'm proposing that in order to side-step the need for cryptographic binding at the object level, we must at minimum keep the label metadata within the same bundle, and rely on the TLS channel to provide hop-by-hop integrity, and claiming we're doing X.841§6.1.3.1. That's really the minimum I think I can get past an accreditor. Does this help clarify a little? Dave. On 14 June 2016 at 16:55, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: >> But I do think there are serious problems with having labelling metadata >> arrive in a different transaction than the TLO (and therefore potentially >> not at all). If you're considering only originators and consumers in a >> corporate setting, this might not seem like a major problem, but if you >> consider border gateways and guard systems, especially within secure >> environments, it can introduce an entirely new failure state. If the source >> system fails before the gateway can ascertain the label of the data, then it >> is unable to know if the data should be forwarded, rejected (with a logged >> exception), or stored pending. From a security standpoint, I don't know what >> happens if an attempt to deference a label reference fails. I am afraid I do not understand at all why we would be concerned with "label de-referencing" in STIX. As a result - I don't really understand this message thread. Can someone expand on the use cases in finer detail? What is behind this "de-referenced label", that a recipient would be concerned with? Is it a ruleset that software is expected to enforce? Is it a plain english document? What is it and who is consuming it, and to what end? IE - I label a piece of content " NATO SECRET ", great. But the actual definition of " NATO SECRET " and what that means and what rules need to be applied, how any system (including guard systems) may or may not behave when it receives that, does not actually need to be sent in order for the recipient to enforce it. The idea that we will send a giant sequence of rule states that NATO SECRET must follow to the recipient does not make any sense to me whatsoever - how are you going to even know if they are followed? You won't... so why bother sending them... if you are sending someone NATO SECRET information you have to de-facto assume that the recipient knows how to handle that marking. - Jason Keirstead STSM, 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 Dave Cridland ---06/14/2016 09:31:55 AM---John, Funnily enough, my recent work with cross-domain guards has transformed XML From: Dave Cridland < dave.cridland@surevine.com > To: "Wunder, John A." < jwunder@mitre.org > Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Date: 06/14/2016 09:31 AM Subject: Re: [cti-stix] Object Level Markings Sent by: < cti-stix@lists.oasis-open.org > John, Funnily enough, my recent work with cross-domain guards has transformed XML into JSON for transit - but that point is somewhat moot. If we can mandate that the marking-definition is in the same bundle as the marked data, I can live with the rest. Dave. On 14 June 2016 at 00:02, Wunder, John A. < jwunder@mitre.org > wrote: Dave, We’ve had some discussions about how STIX could transit a guard/CDS…keep in mind that there are very few/no existing guards that can transit JSON anyway, or understand our granular markings approach, so this restriction for transiting a guard is just one among many. It’s almost certain that any time STIX needs to move across domains it would need to be transformed into a more restrictive, XML-based language anyway, where (if necessary) the markings can be kept locally. Even in the JSON version, you could do that by putting the marking-definition in the same bundle as the marked data anyway (I expect this will be very common). It sounds like we need to fail the motion for unanimous consent and talk about this on the next working call. The SC needs to discuss Dave’s concerns and decide whether to open the data markings topic for further discussion/rewrite or whether to just proceed with a ballot on the current approach. John On 6/13/16, 1:20 PM, " cti-stix@lists.oasis-open.org on behalf of Jerome Athias" < cti-stix@lists.oasis-open.org on behalf of athiasjerome@gmail.com > wrote: >Dave, > >Welcome! And good luck here >You could be interested by > https://lists.oasis-open.org/archives/cti-users/201604/msg00005.html > >Regards > > > >2016-06-13 19:10 GMT+03:00 Dave Cridland < dave.cridland@surevine.com >: >> Bret, >> >> There's no semantic difference between a labelling scheme that mandates >> inline and a labelling scheme whose mandatory inline form is a reference to >> external information. If you want a single method, then inlining is the one, >> and the inline form can then optionally consist of just a reference. But if >> it's all references, and the reference is to another object within the same >> PDU, or transaction, then this is mostly a matter of personal taste and not >> a hill for me to die on. >> >> Similarly, while I'd prefer the display marking to be in the JSON payload I >> can live without it. >> >> But I do think there are serious problems with having labelling metadata >> arrive in a different transaction than the TLO (and therefore potentially >> not at all). If you're considering only originators and consumers in a >> corporate setting, this might not seem like a major problem, but if you >> consider border gateways and guard systems, especially within secure >> environments, it can introduce an entirely new failure state. If the source >> system fails before the gateway can ascertain the label of the data, then it >> is unable to know if the data should be forwarded, rejected (with a logged >> exception), or stored pending. From a security standpoint, I don't know what >> happens if an attempt to deference a label reference fails. >> >> That's aside from considerations about cryptographic binding of label >> metadata to the object - we can handwave over that to a degree if we assume >> that we can carry both the TLO and the labelling object within the same >> secure channel (TLS, for example), but otherwise there's a risk that a label >> dereferenced by a later transaction would be different from the intention >> when the object was transmitted, and this isn't something we can specify >> around - we need cryptographic proof. >> >> Dave. >> >> We need to make sure we have "one-way" of doing things.  If there are >> multiple ways of doing the same thing, then we will have a fragile design. >> Further, one of our original designs or hopes was that certain common data >> markings might become well known thus reducing the need to re-transmit. >> >> >> I think manual visual inspection of raw JSON is only valid during testing or >> in simple environments.  Inspecting the datamarking in reality is an >> implementation issue, not a specification issue.  Your tool should be able >> to easily dereference the datamarkings and display them for you. >> >> >> Bret >> >> >> >> >> ________________________________ >> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on >> behalf of Dave Cridland < dave.cridland@surevine.com > >> Sent: Monday, June 13, 2016 2:20 AM >> To: Wunder, John A. >> Cc: cti-stix@lists.oasis-open.org >> Subject: Re: [cti-stix] Object Level Markings >> >> >> Yes, I'm unclear why the US Gov wants to do labels by reference; I've only >> ever seen that requirement from the US, and never anyone else. I suspect >> it's due to the US having relative few permutations in the labelling scheme, >> whereas the UK (for example) has thousands. >> >> My thought is that while it's certainly useful to move, for example, a full >> copyright license to a reference, in the majority of cases a simple label or >> statement can be presented inline without any problem - it'll likely be >> shorter than the example identifiers given in many cases. >> >> The other issue is that by enforcing everything to be solely by reference, >> the display marking is lost. I worry that this means we lose the ability to >> spot issues by eyeball. >> >> More information: >> >> The display marking is the string that might be printed at the bottom of a >> document, such as "SECRET//NOFORN", or "NATO SECRET". The label is the >> machine readable form, and contains information such as what policy is used. >> Labels come in a variety of formats, from the XML/JSON EDH form that the US >> uses (quite verbose) to the very terse ESS, used in S/MIME for example. This >> latter form is usually much smaller than a display marking; a typical US >> label in ESS form is perhaps 20 bytes - smaller than your identifier. >> >> As far as precedence is concerned, the only case I can think of where this >> might be important is where you have policy translation going on. Say the >> information originates in NATO, for example, as NATO SECRET, and moves to a >> UK domain, where it needs marking as UK SECRET (I simplify of course). The >> "most correct" label is still the NATO one, and the UK Equivalent Label is >> only there for systems that only understand the local policy. You can >> exchange "NATO" for "CERT-US" and "UK" for "FS-ISAC" if you prefer. >> >> But in this case you want to group the labels and mark the equivalent ones >> such that they can easily be ignored. >> >> I can live with being in the rough on referenced labels, though I would >> prefer an option to inline the data. >> >> I'm worried that "precedence" isn't thought through quite enough. >> >> I'm happy to write some text that covers my concerns. >> >> On 12 Jun 2016 11:31 p.m., "Wunder, John A." < jwunder@mitre.org > wrote: >>> >>> To explain a bit more, doing markings by reference was something that was >>> requested by some US government folks who wanted to avoid representing >>> duplicative markings over and over again. While things like TLP are very >>> short and can easily be duplicated over and over, other marking statements >>> (copyrights, government markings, and likely whatever the FIRST SIG creates) >>> will be larger and more complicated and so being able to reference those >>> from 1000 indicators rather than duplicate them seems to make sense. As Bret >>> said, we added normative text to make sure we covered this case. >>> >>> >>> >>> As for precedence, it’s a bit of a hard topic. In some cases (TLP) you >>> really only have one marking that can apply…it doesn’t make sense for an >>> object to have both TLP:GREEN and TLP:RED. In other cases, like terms of >>> use, you have several that apply. In other cases, like more complicated >>> structured markings, it’s possible for multiple to apply and override parts >>> of the other. We didn’t want to address this in STIX so simply defined what >>> it meant for markings to have precedence and will let the marking >>> definitions themselves figure out what that means. Note that, as you said, >>> it’s definitely true that markings of different types will not override each >>> other. This is why we said that precedence rules only apply to markings of >>> the same type. >>> >>> >>> >>> When first designing data markings in 1.x and discussing them for 2.0 we >>> had very good participation from people in government who mark things every >>> day and that led us to the reference approach (among other things). We did >>> discuss other approaches, in particular NIEM…I also did a quick search and >>> it looks like you actually brought up XEP-0258 at the time. You can review >>> here: https://lists.oasis-open.org/archives/cti-users/201511/msg00002.html . >>> The conversation was a bit different than applying markings, it was about >>> the markings that get applied themselves, and I think is what led to our >>> following the FIRST SIG on Information Sharing. >>> >>> >>> >>> Anyway, how would you like me to treat this comment? Should I assume it’s >>> an objection to the motion for unanimous consent that I made on Friday? If >>> so, as a community we need to decide whether we want to open a data markings >>> discussion or just hold a ballot to accept what we have. >>> >>> >>> >>> John >>> >>> >>> >>> From: < cti-stix@lists.oasis-open.org > on behalf of "Jordan, Bret" >>> < bret.jordan@bluecoat.com > >>> Date: Sunday, June 12, 2016 at 5:14 PM >>> To: Dave Cridland < dave.cridland@surevine.com >, >>> " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > >>> Subject: Re: [cti-stix] Object Level Markings >>> >>> >>> >>> Dave, >>> >>> >>> >>> Great comments and questions.....   Let me try and fill in some of the >>> gaps....  Yes, in STIX 2.0 we will have two types of relationships....  And >>> as a general rule most everything will use a relationship in STIX 2.0. >>> Nested content in STIX 1.x proved to be a bad design in the wild. >>> >>> >>> >>> 1) Embedded references (like created_by_ref and object_markings_ref). >>> These references are "facts" that will be known to the TLO.  However, like >>> you said, a consumer may not have the reference yet, or may not have access >>> to the referenced object.  For data markings we say, that if you do not have >>> the object_markings_ref object, and you can not get it via another TAXII >>> call, than you MUST stop processing the TLO.  In the real-world, you will >>> have out-of-band gates that prevent you from ever sharing threat >>> intelligence with someone that does not have access to the same the >>> data-markings that you have access to. >>> >>> >>> >>> 2) Relationship Objects.  These relationships are used for assertions or >>> opinions about things.  So if you link an Observation to a Campaign, or an >>> Incident to an IntrusionSet, you would use one of these external >>> relationships to link it together.  This will allow you, in the future, to >>> place a confidence score on your assertion that these two things are >>> related.  It will also allow in the future for others to potentially >>> down-vote your assertions. >>> >>> >>> >>> Bret >>> >>> >>> >>> ________________________________ >>> >>> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on >>> behalf of Dave Cridland < dave.cridland@surevine.com > >>> Sent: Sunday, June 12, 2016 7:09 AM >>> To: cti-stix@lists.oasis-open.org >>> Subject: [cti-stix] Object Level Markings >>> >>> >>> >>> Hi folks, >>> >>> I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me >>> if I'm missing something, or retracing your steps, or going about things to >>> wrong way. >>> >>> The current section 6.5 appears to discuss aspects of object level >>> markings, and suggests these might cover both legal permissioning (such as >>> Copyright), and MAC systems (such as security labelling). Mixing the two is >>> interesting - I hadn't considered this but it makes sense. >>> >>> Also, the system operates by reference. This is going to be very difficult >>> to manage, and is traditionally avoided in most cases. This is especially >>> true if the referenced label data for the marking is not present within the >>> same transmission, since automated tooling for MAC will become extremely >>> complex (and complexity begets unhappy accreditors). >>> >>> Has the group considered prior art in this space? I'm thinking >>> particularly of XMPP's XEP-0258, but others may also apply. I'm particularly >>> keen to ensure that multipolicy systems will work effectively, since I see >>> that as being very likely in the CTI world shortly. >>> >>> As for multiple orthogonal rules - I don't understand where precedence >>> comes into this. Taking Copyright as an example, if one derives a work from >>> an existing work, the copyright changes, and the license may also change - I >>> don't see the benefit in including a list of previous copyright notices, and >>> then having the systems decide which one applies. >>> >>> I would expect that every marking present would need to be adhered to >>> (some might not be practical to adhere to programmatically, of course). But >>> you can't share something, say, UK SECRET, no matter what the copyright >>> notice says - and vice-versa, an unclassified document cannot be shared if >>> the copyright license is not available. >>> >>> Happy to discuss this further, or or out of any particuar call. >>> >>> Dave. > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > -- Dave Cridland phone   +448454681066 email   dave.cridland@surevine.com skype  dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us. -- Dave Cridland phone  +448454681066 email   dave.cridland@surevine.com skype  dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us.

Dave, A few things....  In most situations, IMHO, content will be delivered in atomic units.  The STIX Bundle will probably not be used in most TAXII sessions.  You will request content and you will be delivered those objects one at a time.. You will then parse those objects and discover reference that you will then need to dereference on the TAXII server...  AKA TAXII 2.0 will be a RESTful design.   Now with that said, we may add an HTTP header flag that would allow you to tell the TAXII server to automatically de-reference all of the content and send it all to you.  But the TAXII server may not honor that.  So there is no way to guarantee that you will get all of the content in the same JSON object.  Stepping back a bit, it sounds like you are asking for a simple summary string in addition to the marking-definition reference... Is that correct?   Meaning you would have something like: {  "type": "indicator",  "id": "indicator--089a6ecb-cc15-43cc-9494-767639779235",  ...  "object_marking_refs": ["marking-definition--089a6ecb-cc15-43cc-9494-767639779123"], "object_marking_notes": "NATO Secret"  ... } So the main definition and details would still be in the marking-definition, but you would have a simple helper string value?  Or am I misunderstanding what you are asking for? Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Dave Cridland <dave.cridland@surevine.com> Sent: Tuesday, June 14, 2016 10:51 AM To: Jason Keirstead Cc: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Object Level Markings   Jason, Yes, if we were sending that kind of information it would be insane. There's three items of information associated with the access control decision: * The Label, which in your example was "NATO SECRET". In NATO's preferred syntax, that's actually a shortish bit of XML, usually around half a kilobyte. * The Clearance, which a guard would typically have as a constant value, and an endpoint would handle via LDAP lookups, etc. * The Policy, which actually defines the rules, and again, for NATO, would be XML - but much larger. NATO's policy is 86k, for instance. The part I'm suggesting needs to be kept with the data is only the first of these, the label. An example label, in NATO's ADatP-4774 format, is here: https://github.com/surevine/spiffing/blob/stanag-4774/test-data/nato-4774-17-1.nato surevine/spiffing github.com spiffing - Jolly good library for SPIF/Label/Clearance handling That repository also has (MIT-licensed) code that'll produce a display marking from it (in this case "NATO UNCLASSIFIED Releasable to ISAF, KFOR, RESOLUTE SUPPORT"), which it does from the policy information file, which is similar to that available here in Open XML SPIF format: https://github.com/surevine/spiffing/blob/stanag-4774/test-data/nato-4774-policy.xml We won't be sending around the policy - we expect anything that needs that to have it already. Similarly, clearances make no sense to send around at all - they'd be selected and evaluated locally in every case. But typical specifications for this require that the label metadata is "bound" with the data, for example in X.841 §6.1.3, or ADatP-4778. I'm proposing that in order to side-step the need for cryptographic binding at the object level, we must at minimum keep the label metadata within the same bundle, and rely on the TLS channel to provide hop-by-hop integrity, and claiming we're doing X.841§6.1.3.1. That's really the minimum I think I can get past an accreditor. Does this help clarify a little? Dave. On 14 June 2016 at 16:55, Jason Keirstead < Jason.Keirstead@ca.ibm.com > wrote: >> But I do think there are serious problems with having labelling metadata >> arrive in a different transaction than the TLO (and therefore potentially >> not at all). If you're considering only originators and consumers in a >> corporate setting, this might not seem like a major problem, but if you >> consider border gateways and guard systems, especially within secure >> environments, it can introduce an entirely new failure state. If the source >> system fails before the gateway can ascertain the label of the data, then it >> is unable to know if the data should be forwarded, rejected (with a logged >> exception), or stored pending. From a security standpoint, I don't know what >> happens if an attempt to deference a label reference fails. I am afraid I do not understand at all why we would be concerned with "label de-referencing" in STIX. As a result - I don't really understand this message thread. Can someone expand on the use cases in finer detail? What is behind this "de-referenced label", that a recipient would be concerned with? Is it a ruleset that software is expected to enforce? Is it a plain english document? What is it and who is consuming it, and to what end? IE - I label a piece of content " NATO SECRET ", great. But the actual definition of " NATO SECRET " and what that means and what rules need to be applied, how any system (including guard systems) may or may not behave when it receives that, does not actually need to be sent in order for the recipient to enforce it. The idea that we will send a giant sequence of rule states that NATO SECRET must follow to the recipient does not make any sense to me whatsoever - how are you going to even know if they are followed? You won't... so why bother sending them... if you are sending someone NATO SECRET information you have to de-facto assume that the recipient knows how to handle that marking. - Jason Keirstead STSM, 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 Dave Cridland ---06/14/2016 09:31:55 AM---John, Funnily enough, my recent work with cross-domain guards has transformed XML From: Dave Cridland < dave.cridland@surevine.com > To: "Wunder, John A." < jwunder@mitre.org > Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Date: 06/14/2016 09:31 AM Subject: Re: [cti-stix] Object Level Markings Sent by: < cti-stix@lists.oasis-open.org > John, Funnily enough, my recent work with cross-domain guards has transformed XML into JSON for transit - but that point is somewhat moot. If we can mandate that the marking-definition is in the same bundle as the marked data, I can live with the rest. Dave. On 14 June 2016 at 00:02, Wunder, John A. < jwunder@mitre.org > wrote: Dave, We’ve had some discussions about how STIX could transit a guard/CDS…keep in mind that there are very few/no existing guards that can transit JSON anyway, or understand our granular markings approach, so this restriction for transiting a guard is just one among many. It’s almost certain that any time STIX needs to move across domains it would need to be transformed into a more restrictive, XML-based language anyway, where (if necessary) the markings can be kept locally. Even in the JSON version, you could do that by putting the marking-definition in the same bundle as the marked data anyway (I expect this will be very common). It sounds like we need to fail the motion for unanimous consent and talk about this on the next working call. The SC needs to discuss Dave’s concerns and decide whether to open the data markings topic for further discussion/rewrite or whether to just proceed with a ballot on the current approach. John On 6/13/16, 1:20 PM, " cti-stix@lists.oasis-open.org on behalf of Jerome Athias" < cti-stix@lists.oasis-open.org on behalf of athiasjerome@gmail.com > wrote: >Dave, > >Welcome! And good luck here >You could be interested by > https://lists.oasis-open.org/archives/cti-users/201604/msg00005.html > >Regards > > > >2016-06-13 19:10 GMT+03:00 Dave Cridland < dave.cridland@surevine.com >: >> Bret, >> >> There's no semantic difference between a labelling scheme that mandates >> inline and a labelling scheme whose mandatory inline form is a reference to >> external information. If you want a single method, then inlining is the one, >> and the inline form can then optionally consist of just a reference. But if >> it's all references, and the reference is to another object within the same >> PDU, or transaction, then this is mostly a matter of personal taste and not >> a hill for me to die on. >> >> Similarly, while I'd prefer the display marking to be in the JSON payload I >> can live without it. >> >> But I do think there are serious problems with having labelling metadata >> arrive in a different transaction than the TLO (and therefore potentially >> not at all). If you're considering only originators and consumers in a >> corporate setting, this might not seem like a major problem, but if you >> consider border gateways and guard systems, especially within secure >> environments, it can introduce an entirely new failure state. If the source >> system fails before the gateway can ascertain the label of the data, then it >> is unable to know if the data should be forwarded, rejected (with a logged >> exception), or stored pending. From a security standpoint, I don't know what >> happens if an attempt to deference a label reference fails. >> >> That's aside from considerations about cryptographic binding of label >> metadata to the object - we can handwave over that to a degree if we assume >> that we can carry both the TLO and the labelling object within the same >> secure channel (TLS, for example), but otherwise there's a risk that a label >> dereferenced by a later transaction would be different from the intention >> when the object was transmitted, and this isn't something we can specify >> around - we need cryptographic proof. >> >> Dave. >> >> We need to make sure we have "one-way" of doing things.  If there are >> multiple ways of doing the same thing, then we will have a fragile design. >> Further, one of our original designs or hopes was that certain common data >> markings might become well known thus reducing the need to re-transmit. >> >> >> I think manual visual inspection of raw JSON is only valid during testing or >> in simple environments.  Inspecting the datamarking in reality is an >> implementation issue, not a specification issue.  Your tool should be able >> to easily dereference the datamarkings and display them for you. >> >> >> Bret >> >> >> >> >> ________________________________ >> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on >> behalf of Dave Cridland < dave.cridland@surevine.com > >> Sent: Monday, June 13, 2016 2:20 AM >> To: Wunder, John A. >> Cc: cti-stix@lists.oasis-open.org >> Subject: Re: [cti-stix] Object Level Markings >> >> >> Yes, I'm unclear why the US Gov wants to do labels by reference; I've only >> ever seen that requirement from the US, and never anyone else. I suspect >> it's due to the US having relative few permutations in the labelling scheme, >> whereas the UK (for example) has thousands. >> >> My thought is that while it's certainly useful to move, for example, a full >> copyright license to a reference, in the majority of cases a simple label or >> statement can be presented inline without any problem - it'll likely be >> shorter than the example identifiers given in many cases. >> >> The other issue is that by enforcing everything to be solely by reference, >> the display marking is lost. I worry that this means we lose the ability to >> spot issues by eyeball. >> >> More information: >> >> The display marking is the string that might be printed at the bottom of a >> document, such as "SECRET//NOFORN", or "NATO SECRET". The label is the >> machine readable form, and contains information such as what policy is used. >> Labels come in a variety of formats, from the XML/JSON EDH form that the US >> uses (quite verbose) to the very terse ESS, used in S/MIME for example. This >> latter form is usually much smaller than a display marking; a typical US >> label in ESS form is perhaps 20 bytes - smaller than your identifier. >> >> As far as precedence is concerned, the only case I can think of where this >> might be important is where you have policy translation going on. Say the >> information originates in NATO, for example, as NATO SECRET, and moves to a >> UK domain, where it needs marking as UK SECRET (I simplify of course). The >> "most correct" label is still the NATO one, and the UK Equivalent Label is >> only there for systems that only understand the local policy. You can >> exchange "NATO" for "CERT-US" and "UK" for "FS-ISAC" if you prefer. >> >> But in this case you want to group the labels and mark the equivalent ones >> such that they can easily be ignored. >> >> I can live with being in the rough on referenced labels, though I would >> prefer an option to inline the data. >> >> I'm worried that "precedence" isn't thought through quite enough. >> >> I'm happy to write some text that covers my concerns. >> >> On 12 Jun 2016 11:31 p.m., "Wunder, John A." < jwunder@mitre.org > wrote: >>> >>> To explain a bit more, doing markings by reference was something that was >>> requested by some US government folks who wanted to avoid representing >>> duplicative markings over and over again. While things like TLP are very >>> short and can easily be duplicated over and over, other marking statements >>> (copyrights, government markings, and likely whatever the FIRST SIG creates) >>> will be larger and more complicated and so being able to reference those >>> from 1000 indicators rather than duplicate them seems to make sense. As Bret >>> said, we added normative text to make sure we covered this case. >>> >>> >>> >>> As for precedence, it’s a bit of a hard topic. In some cases (TLP) you >>> really only have one marking that can apply…it doesn’t make sense for an >>> object to have both TLP:GREEN and TLP:RED. In other cases, like terms of >>> use, you have several that apply. In other cases, like more complicated >>> structured markings, it’s possible for multiple to apply and override parts >>> of the other. We didn’t want to address this in STIX so simply defined what >>> it meant for markings to have precedence and will let the marking >>> definitions themselves figure out what that means. Note that, as you said, >>> it’s definitely true that markings of different types will not override each >>> other. This is why we said that precedence rules only apply to markings of >>> the same type. >>> >>> >>> >>> When first designing data markings in 1.x and discussing them for 2.0 we >>> had very good participation from people in government who mark things every >>> day and that led us to the reference approach (among other things). We did >>> discuss other approaches, in particular NIEM…I also did a quick search and >>> it looks like you actually brought up XEP-0258 at the time. You can review >>> here: https://lists.oasis-open.org/archives/cti-users/201511/msg00002.html . >>> The conversation was a bit different than applying markings, it was about >>> the markings that get applied themselves, and I think is what led to our >>> following the FIRST SIG on Information Sharing. >>> >>> >>> >>> Anyway, how would you like me to treat this comment? Should I assume it’s >>> an objection to the motion for unanimous consent that I made on Friday? If >>> so, as a community we need to decide whether we want to open a data markings >>> discussion or just hold a ballot to accept what we have. >>> >>> >>> >>> John >>> >>> >>> >>> From: < cti-stix@lists.oasis-open.org > on behalf of "Jordan, Bret" >>> < bret.jordan@bluecoat.com > >>> Date: Sunday, June 12, 2016 at 5:14 PM >>> To: Dave Cridland < dave.cridland@surevine.com >, >>> " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > >>> Subject: Re: [cti-stix] Object Level Markings >>> >>> >>> >>> Dave, >>> >>> >>> >>> Great comments and questions.....   Let me try and fill in some of the >>> gaps....  Yes, in STIX 2.0 we will have two types of relationships....  And >>> as a general rule most everything will use a relationship in STIX 2.0. >>> Nested content in STIX 1.x proved to be a bad design in the wild. >>> >>> >>> >>> 1) Embedded references (like created_by_ref and object_markings_ref). >>> These references are "facts" that will be known to the TLO.  However, like >>> you said, a consumer may not have the reference yet, or may not have access >>> to the referenced object.  For data markings we say, that if you do not have >>> the object_markings_ref object, and you can not get it via another TAXII >>> call, than you MUST stop processing the TLO.  In the real-world, you will >>> have out-of-band gates that prevent you from ever sharing threat >>> intelligence with someone that does not have access to the same the >>> data-markings that you have access to. >>> >>> >>> >>> 2) Relationship Objects.  These relationships are used for assertions or >>> opinions about things.  So if you link an Observation to a Campaign, or an >>> Incident to an IntrusionSet, you would use one of these external >>> relationships to link it together.  This will allow you, in the future, to >>> place a confidence score on your assertion that these two things are >>> related.  It will also allow in the future for others to potentially >>> down-vote your assertions. >>> >>> >>> >>> Bret >>> >>> >>> >>> ________________________________ >>> >>> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on >>> behalf of Dave Cridland < dave.cridland@surevine.com > >>> Sent: Sunday, June 12, 2016 7:09 AM >>> To: cti-stix@lists.oasis-open.org >>> Subject: [cti-stix] Object Level Markings >>> >>> >>> >>> Hi folks, >>> >>> I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me >>> if I'm missing something, or retracing your steps, or going about things to >>> wrong way. >>> >>> The current section 6.5 appears to discuss aspects of object level >>> markings, and suggests these might cover both legal permissioning (such as >>> Copyright), and MAC systems (such as security labelling). Mixing the two is >>> interesting - I hadn't considered this but it makes sense. >>> >>> Also, the system operates by reference. This is going to be very difficult >>> to manage, and is traditionally avoided in most cases. This is especially >>> true if the referenced label data for the marking is not present within the >>> same transmission, since automated tooling for MAC will become extremely >>> complex (and complexity begets unhappy accreditors). >>> >>> Has the group considered prior art in this space? I'm thinking >>> particularly of XMPP's XEP-0258, but others may also apply. I'm particularly >>> keen to ensure that multipolicy systems will work effectively, since I see >>> that as being very likely in the CTI world shortly. >>> >>> As for multiple orthogonal rules - I don't understand where precedence >>> comes into this. Taking Copyright as an example, if one derives a work from >>> an existing work, the copyright changes, and the license may also change - I >>> don't see the benefit in including a list of previous copyright notices, and >>> then having the systems decide which one applies. >>> >>> I would expect that every marking present would need to be adhered to >>> (some might not be practical to adhere to programmatically, of course). But >>> you can't share something, say, UK SECRET, no matter what the copyright >>> notice says - and vice-versa, an unclassified document cannot be shared if >>> the copyright license is not available. >>> >>> Happy to discuss this further, or or out of any particuar call. >>> >>> Dave. > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > -- Dave Cridland phone   +448454681066 email   dave.cridland@surevine.com skype  dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us. -- Dave Cridland phone   +448454681066 email   dave.cridland@surevine.com skype   dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us.

When you say “we”…is that something you think we should mandate in the specification, or is it something that we can leave as-is in the specification and you can make a rule for your sharing
community when you need to transit a guard?
 
As Bret said, I don’t think having them mandated in the same bundle is doable for the specification given our current approach. We would need to work through another option. But, it’s definitely
something you could do in your own usage as you define the interface for what goes across the guard (which will almost certainly need to be a restriction of STIX anyway).
 
John
 

From:
Dave Cridland <dave.cridland@surevine.com>
Date: Tuesday, June 14, 2016 at 8:31 AM
To: "Wunder, John A." <jwunder@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Object Level Markings


 




John,

 


Funnily enough, my recent work with cross-domain guards has transformed XML into JSON for transit - but that point is somewhat moot.


 


If we can mandate that the marking-definition is in the same bundle as the marked data, I can live with the rest.


 


Dave.



 

On 14 June 2016 at 00:02, Wunder, John A. < jwunder@mitre.org > wrote:

Dave,

We’ve had some discussions about how STIX could transit a guard/CDS…keep in mind that there are very few/no existing guards that can transit JSON anyway, or understand our granular markings approach, so this restriction for transiting a guard is just one among
many. It’s almost certain that any time STIX needs to move across domains it would need to be transformed into a more restrictive, XML-based language anyway, where (if necessary) the markings can be kept locally.

Even in the JSON version, you could do that by putting the marking-definition in the same bundle as the marked data anyway (I expect this will be very common).

It sounds like we need to fail the motion for unanimous consent and talk about this on the next working call. The SC needs to discuss Dave’s concerns and decide whether to open the data markings topic for further discussion/rewrite or whether to just proceed
with a ballot on the current approach.

John



On 6/13/16, 1:20 PM, " cti-stix@lists.oasis-open.org on behalf of Jerome Athias" < cti-stix@lists.oasis-open.org on behalf of
athiasjerome@gmail.com > wrote:

>Dave,
>
>Welcome! And good luck here
>You could be interested by
> https://lists.oasis-open.org/archives/cti-users/201604/msg00005.html
>
>Regards
>
>
>
>2016-06-13 19:10 GMT+03:00 Dave Cridland < dave.cridland@surevine.com >:
>> Bret,
>>
>> There's no semantic difference between a labelling scheme that mandates
>> inline and a labelling scheme whose mandatory inline form is a reference to
>> external information. If you want a single method, then inlining is the one,
>> and the inline form can then optionally consist of just a reference. But if
>> it's all references, and the reference is to another object within the same
>> PDU, or transaction, then this is mostly a matter of personal taste and not
>> a hill for me to die on.
>>
>> Similarly, while I'd prefer the display marking to be in the JSON payload I
>> can live without it.
>>
>> But I do think there are serious problems with having labelling metadata
>> arrive in a different transaction than the TLO (and therefore potentially
>> not at all). If you're considering only originators and consumers in a
>> corporate setting, this might not seem like a major problem, but if you
>> consider border gateways and guard systems, especially within secure
>> environments, it can introduce an entirely new failure state. If the source
>> system fails before the gateway can ascertain the label of the data, then it
>> is unable to know if the data should be forwarded, rejected (with a logged
>> exception), or stored pending. From a security standpoint, I don't know what
>> happens if an attempt to deference a label reference fails.
>>
>> That's aside from considerations about cryptographic binding of label
>> metadata to the object - we can handwave over that to a degree if we assume
>> that we can carry both the TLO and the labelling object within the same
>> secure channel (TLS, for example), but otherwise there's a risk that a label
>> dereferenced by a later transaction would be different from the intention
>> when the object was transmitted, and this isn't something we can specify
>> around - we need cryptographic proof.
>>
>> Dave.
>>
>> We need to make sure we have "one-way" of doing things.  If there are
>> multiple ways of doing the same thing, then we will have a fragile design.
>> Further, one of our original designs or hopes was that certain common data
>> markings might become well known thus reducing the need to re-transmit.
>>
>>
>> I think manual visual inspection of raw JSON is only valid during testing or
>> in simple environments.  Inspecting the datamarking in reality is an
>> implementation issue, not a specification issue.  Your tool should be able
>> to easily dereference the datamarkings and display them for you.
>>
>>
>> Bret
>>
>>
>>
>>
>> ________________________________
>> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on
>> behalf of Dave Cridland < dave.cridland@surevine.com >
>> Sent: Monday, June 13, 2016 2:20 AM
>> To: Wunder, John A.
>> Cc: cti-stix@lists.oasis-open.org
>> Subject: Re: [cti-stix] Object Level Markings
>>
>>
>> Yes, I'm unclear why the US Gov wants to do labels by reference; I've only
>> ever seen that requirement from the US, and never anyone else. I suspect
>> it's due to the US having relative few permutations in the labelling scheme,
>> whereas the UK (for example) has thousands.
>>
>> My thought is that while it's certainly useful to move, for example, a full
>> copyright license to a reference, in the majority of cases a simple label or
>> statement can be presented inline without any problem - it'll likely be
>> shorter than the example identifiers given in many cases.
>>
>> The other issue is that by enforcing everything to be solely by reference,
>> the display marking is lost. I worry that this means we lose the ability to
>> spot issues by eyeball.
>>
>> More information:
>>
>> The display marking is the string that might be printed at the bottom of a
>> document, such as "SECRET//NOFORN", or "NATO SECRET". The label is the
>> machine readable form, and contains information such as what policy is used.
>> Labels come in a variety of formats, from the XML/JSON EDH form that the US
>> uses (quite verbose) to the very terse ESS, used in S/MIME for example. This
>> latter form is usually much smaller than a display marking; a typical US
>> label in ESS form is perhaps 20 bytes - smaller than your identifier.
>>
>> As far as precedence is concerned, the only case I can think of where this
>> might be important is where you have policy translation going on. Say the
>> information originates in NATO, for example, as NATO SECRET, and moves to a
>> UK domain, where it needs marking as UK SECRET (I simplify of course). The
>> "most correct" label is still the NATO one, and the UK Equivalent Label is
>> only there for systems that only understand the local policy. You can
>> exchange "NATO" for "CERT-US" and "UK" for "FS-ISAC" if you prefer.
>>
>> But in this case you want to group the labels and mark the equivalent ones
>> such that they can easily be ignored.
>>
>> I can live with being in the rough on referenced labels, though I would
>> prefer an option to inline the data.
>>
>> I'm worried that "precedence" isn't thought through quite enough.
>>
>> I'm happy to write some text that covers my concerns.
>>
>> On 12 Jun 2016 11:31 p.m., "Wunder, John A." < jwunder@mitre.org > wrote:
>>>
>>> To explain a bit more, doing markings by reference was something that was
>>> requested by some US government folks who wanted to avoid representing
>>> duplicative markings over and over again. While things like TLP are very
>>> short and can easily be duplicated over and over, other marking statements
>>> (copyrights, government markings, and likely whatever the FIRST SIG creates)
>>> will be larger and more complicated and so being able to reference those
>>> from 1000 indicators rather than duplicate them seems to make sense. As Bret
>>> said, we added normative text to make sure we covered this case.
>>>
>>>
>>>
>>> As for precedence, it’s a bit of a hard topic. In some cases (TLP) you
>>> really only have one marking that can apply…it doesn’t make sense for an
>>> object to have both TLP:GREEN and TLP:RED. In other cases, like terms of
>>> use, you have several that apply. In other cases, like more complicated
>>> structured markings, it’s possible for multiple to apply and override parts
>>> of the other. We didn’t want to address this in STIX so simply defined what
>>> it meant for markings to have precedence and will let the marking
>>> definitions themselves figure out what that means. Note that, as you said,
>>> it’s definitely true that markings of different types will not override each
>>> other. This is why we said that precedence rules only apply to markings of
>>> the same type.
>>>
>>>
>>>
>>> When first designing data markings in 1.x and discussing them for 2.0 we
>>> had very good participation from people in government who mark things every
>>> day and that led us to the reference approach (among other things). We did
>>> discuss other approaches, in particular NIEM…I also did a quick search and
>>> it looks like you actually brought up XEP-0258 at the time. You can review
>>> here:
https://lists.oasis-open.org/archives/cti-users/201511/msg00002.html .
>>> The conversation was a bit different than applying markings, it was about
>>> the markings that get applied themselves, and I think is what led to our
>>> following the FIRST SIG on Information Sharing.
>>>
>>>
>>>
>>> Anyway, how would you like me to treat this comment? Should I assume it’s
>>> an objection to the motion for unanimous consent that I made on Friday? If
>>> so, as a community we need to decide whether we want to open a data markings
>>> discussion or just hold a ballot to accept what we have.
>>>
>>>
>>>
>>> John
>>>
>>>
>>>
>>> From: < cti-stix@lists.oasis-open.org > on behalf of "Jordan, Bret"
>>> < bret.jordan@bluecoat.com >
>>> Date: Sunday, June 12, 2016 at 5:14 PM
>>> To: Dave Cridland < dave.cridland@surevine.com >,
>>> " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
>>> Subject: Re: [cti-stix] Object Level Markings
>>>
>>>
>>>
>>> Dave,
>>>
>>>
>>>
>>> Great comments and questions.....   Let me try and fill in some of the
>>> gaps....  Yes, in STIX 2.0 we will have two types of relationships....  And
>>> as a general rule most everything will use a relationship in STIX 2.0.
>>> Nested content in STIX 1.x proved to be a bad design in the wild.
>>>
>>>
>>>
>>> 1) Embedded references (like created_by_ref and object_markings_ref).
>>> These references are "facts" that will be known to the TLO.  However, like
>>> you said, a consumer may not have the reference yet, or may not have access
>>> to the referenced object.  For data markings we say, that if you do not have
>>> the object_markings_ref object, and you can not get it via another TAXII
>>> call, than you MUST stop processing the TLO.  In the real-world, you will
>>> have out-of-band gates that prevent you from ever sharing threat
>>> intelligence with someone that does not have access to the same the
>>> data-markings that you have access to.
>>>
>>>
>>>
>>> 2) Relationship Objects.  These relationships are used for assertions or
>>> opinions about things.  So if you link an Observation to a Campaign, or an
>>> Incident to an IntrusionSet, you would use one of these external
>>> relationships to link it together.  This will allow you, in the future, to
>>> place a confidence score on your assertion that these two things are
>>> related.  It will also allow in the future for others to potentially
>>> down-vote your assertions.
>>>
>>>
>>>
>>> Bret
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on
>>> behalf of Dave Cridland < dave.cridland@surevine.com >
>>> Sent: Sunday, June 12, 2016 7:09 AM
>>> To: cti-stix@lists.oasis-open.org
>>> Subject: [cti-stix] Object Level Markings
>>>
>>>
>>>
>>> Hi folks,
>>>
>>> I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me
>>> if I'm missing something, or retracing your steps, or going about things to
>>> wrong way.
>>>
>>> The current section 6.5 appears to discuss aspects of object level
>>> markings, and suggests these might cover both legal permissioning (such as
>>> Copyright), and MAC systems (such as security labelling). Mixing the two is
>>> interesting - I hadn't considered this but it makes sense.
>>>
>>> Also, the system operates by reference. This is going to be very difficult
>>> to manage, and is traditionally avoided in most cases. This is especially
>>> true if the referenced label data for the marking is not present within the
>>> same transmission, since automated tooling for MAC will become extremely
>>> complex (and complexity begets unhappy accreditors).
>>>
>>> Has the group considered prior art in this space? I'm thinking
>>> particularly of XMPP's XEP-0258, but others may also apply. I'm particularly
>>> keen to ensure that multipolicy systems will work effectively, since I see
>>> that as being very likely in the CTI world shortly.
>>>
>>> As for multiple orthogonal rules - I don't understand where precedence
>>> comes into this. Taking Copyright as an example, if one derives a work from
>>> an existing work, the copyright changes, and the license may also change - I
>>> don't see the benefit in including a list of previous copyright notices, and
>>> then having the systems decide which one applies.
>>>
>>> I would expect that every marking present would need to be adhered to
>>> (some might not be practical to adhere to programmatically, of course). But
>>> you can't share something, say, UK SECRET, no matter what the copyright
>>> notice says - and vice-versa, an unclassified document cannot be shared if
>>> the copyright license is not available.
>>>
>>> Happy to discuss this further, or or out of any particuar call.
>>>
>>> Dave.
>


>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>






 

--


Dave Cridland


phone  +448454681066


email   dave.cridland@surevine.com


skype  dave.cridland.surevine



Participate Collaborate Innovate


Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND


If you think you have received this message in error, please notify us.

Looking at the 80/20 rule, is this something that is critical for most of the user population? Or something that affects a smaller percentage? Is it something for which there can be a specific workaround for the affected community only? I personally are fine with the current way we do things, and I would be interested to see a ballot on this topic to see how much this affects the general population, rather than a specific subset. Cheers Terry MacDonald On 15/06/2016 10:39, "Wunder, John A." < jwunder@mitre.org > wrote: When you say “we”…is that something you think we should mandate in the specification, or is it something that we can leave as-is in the specification and you can make a rule for your sharing community when you need to transit a guard?   As Bret said, I don’t think having them mandated in the same bundle is doable for the specification given our current approach. We would need to work through another option. But, it’s definitely something you could do in your own usage as you define the interface for what goes across the guard (which will almost certainly need to be a restriction of STIX anyway).   John   From: Dave Cridland < dave.cridland@surevine.com > Date: Tuesday, June 14, 2016 at 8:31 AM To: "Wunder, John A." < jwunder@mitre.org > Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Object Level Markings   John,   Funnily enough, my recent work with cross-domain guards has transformed XML into JSON for transit - but that point is somewhat moot.   If we can mandate that the marking-definition is in the same bundle as the marked data, I can live with the rest.   Dave.   On 14 June 2016 at 00:02, Wunder, John A. < jwunder@mitre.org > wrote: Dave, We’ve had some discussions about how STIX could transit a guard/CDS…keep in mind that there are very few/no existing guards that can transit JSON anyway, or understand our granular markings approach, so this restriction for transiting a guard is just one among many. It’s almost certain that any time STIX needs to move across domains it would need to be transformed into a more restrictive, XML-based language anyway, where (if necessary) the markings can be kept locally. Even in the JSON version, you could do that by putting the marking-definition in the same bundle as the marked data anyway (I expect this will be very common). It sounds like we need to fail the motion for unanimous consent and talk about this on the next working call. The SC needs to discuss Dave’s concerns and decide whether to open the data markings topic for further discussion/rewrite or whether to just proceed with a ballot on the current approach. John On 6/13/16, 1:20 PM, " cti-stix@lists.oasis-open.org on behalf of Jerome Athias" < cti-stix@lists.oasis-open.org on behalf of athiasjerome@gmail.com > wrote: >Dave, > >Welcome! And good luck here >You could be interested by > https://lists.oasis-open.org/archives/cti-users/201604/msg00005.html > >Regards > > > >2016-06-13 19:10 GMT+03:00 Dave Cridland < dave.cridland@surevine.com >: >> Bret, >> >> There's no semantic difference between a labelling scheme that mandates >> inline and a labelling scheme whose mandatory inline form is a reference to >> external information. If you want a single method, then inlining is the one, >> and the inline form can then optionally consist of just a reference. But if >> it's all references, and the reference is to another object within the same >> PDU, or transaction, then this is mostly a matter of personal taste and not >> a hill for me to die on. >> >> Similarly, while I'd prefer the display marking to be in the JSON payload I >> can live without it. >> >> But I do think there are serious problems with having labelling metadata >> arrive in a different transaction than the TLO (and therefore potentially >> not at all). If you're considering only originators and consumers in a >> corporate setting, this might not seem like a major problem, but if you >> consider border gateways and guard systems, especially within secure >> environments, it can introduce an entirely new failure state. If the source >> system fails before the gateway can ascertain the label of the data, then it >> is unable to know if the data should be forwarded, rejected (with a logged >> exception), or stored pending. From a security standpoint, I don't know what >> happens if an attempt to deference a label reference fails. >> >> That's aside from considerations about cryptographic binding of label >> metadata to the object - we can handwave over that to a degree if we assume >> that we can carry both the TLO and the labelling object within the same >> secure channel (TLS, for example), but otherwise there's a risk that a label >> dereferenced by a later transaction would be different from the intention >> when the object was transmitted, and this isn't something we can specify >> around - we need cryptographic proof. >> >> Dave. >> >> We need to make sure we have "one-way" of doing things.  If there are >> multiple ways of doing the same thing, then we will have a fragile design. >> Further, one of our original designs or hopes was that certain common data >> markings might become well known thus reducing the need to re-transmit. >> >> >> I think manual visual inspection of raw JSON is only valid during testing or >> in simple environments.  Inspecting the datamarking in reality is an >> implementation issue, not a specification issue.  Your tool should be able >> to easily dereference the datamarkings and display them for you. >> >> >> Bret >> >> >> >> >> ________________________________ >> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on >> behalf of Dave Cridland < dave.cridland@surevine.com > >> Sent: Monday, June 13, 2016 2:20 AM >> To: Wunder, John A. >> Cc: cti-stix@lists.oasis-open.org >> Subject: Re: [cti-stix] Object Level Markings >> >> >> Yes, I'm unclear why the US Gov wants to do labels by reference; I've only >> ever seen that requirement from the US, and never anyone else. I suspect >> it's due to the US having relative few permutations in the labelling scheme, >> whereas the UK (for example) has thousands. >> >> My thought is that while it's certainly useful to move, for example, a full >> copyright license to a reference, in the majority of cases a simple label or >> statement can be presented inline without any problem - it'll likely be >> shorter than the example identifiers given in many cases. >> >> The other issue is that by enforcing everything to be solely by reference, >> the display marking is lost. I worry that this means we lose the ability to >> spot issues by eyeball. >> >> More information: >> >> The display marking is the string that might be printed at the bottom of a >> document, such as "SECRET//NOFORN", or "NATO SECRET". The label is the >> machine readable form, and contains information such as what policy is used. >> Labels come in a variety of formats, from the XML/JSON EDH form that the US >> uses (quite verbose) to the very terse ESS, used in S/MIME for example. This >> latter form is usually much smaller than a display marking; a typical US >> label in ESS form is perhaps 20 bytes - smaller than your identifier. >> >> As far as precedence is concerned, the only case I can think of where this >> might be important is where you have policy translation going on. Say the >> information originates in NATO, for example, as NATO SECRET, and moves to a >> UK domain, where it needs marking as UK SECRET (I simplify of course). The >> "most correct" label is still the NATO one, and the UK Equivalent Label is >> only there for systems that only understand the local policy. You can >> exchange "NATO" for "CERT-US" and "UK" for "FS-ISAC" if you prefer. >> >> But in this case you want to group the labels and mark the equivalent ones >> such that they can easily be ignored. >> >> I can live with being in the rough on referenced labels, though I would >> prefer an option to inline the data. >> >> I'm worried that "precedence" isn't thought through quite enough. >> >> I'm happy to write some text that covers my concerns. >> >> On 12 Jun 2016 11:31 p.m., "Wunder, John A." < jwunder@mitre.org > wrote: >>> >>> To explain a bit more, doing markings by reference was something that was >>> requested by some US government folks who wanted to avoid representing >>> duplicative markings over and over again. While things like TLP are very >>> short and can easily be duplicated over and over, other marking statements >>> (copyrights, government markings, and likely whatever the FIRST SIG creates) >>> will be larger and more complicated and so being able to reference those >>> from 1000 indicators rather than duplicate them seems to make sense. As Bret >>> said, we added normative text to make sure we covered this case. >>> >>> >>> >>> As for precedence, it’s a bit of a hard topic. In some cases (TLP) you >>> really only have one marking that can apply…it doesn’t make sense for an >>> object to have both TLP:GREEN and TLP:RED. In other cases, like terms of >>> use, you have several that apply. In other cases, like more complicated >>> structured markings, it’s possible for multiple to apply and override parts >>> of the other. We didn’t want to address this in STIX so simply defined what >>> it meant for markings to have precedence and will let the marking >>> definitions themselves figure out what that means. Note that, as you said, >>> it’s definitely true that markings of different types will not override each >>> other. This is why we said that precedence rules only apply to markings of >>> the same type. >>> >>> >>> >>> When first designing data markings in 1.x and discussing them for 2.0 we >>> had very good participation from people in government who mark things every >>> day and that led us to the reference approach (among other things). We did >>> discuss other approaches, in particular NIEM…I also did a quick search and >>> it looks like you actually brought up XEP-0258 at the time. You can review >>> here: https://lists.oasis-open.org/archives/cti-users/201511/msg00002.html . >>> The conversation was a bit different than applying markings, it was about >>> the markings that get applied themselves, and I think is what led to our >>> following the FIRST SIG on Information Sharing. >>> >>> >>> >>> Anyway, how would you like me to treat this comment? Should I assume it’s >>> an objection to the motion for unanimous consent that I made on Friday? If >>> so, as a community we need to decide whether we want to open a data markings >>> discussion or just hold a ballot to accept what we have. >>> >>> >>> >>> John >>> >>> >>> >>> From: < cti-stix@lists.oasis-open.org > on behalf of "Jordan, Bret" >>> < bret.jordan@bluecoat.com > >>> Date: Sunday, June 12, 2016 at 5:14 PM >>> To: Dave Cridland < dave.cridland@surevine.com >, >>> " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > >>> Subject: Re: [cti-stix] Object Level Markings >>> >>> >>> >>> Dave, >>> >>> >>> >>> Great comments and questions.....   Let me try and fill in some of the >>> gaps....  Yes, in STIX 2.0 we will have two types of relationships....  And >>> as a general rule most everything will use a relationship in STIX 2.0. >>> Nested content in STIX 1.x proved to be a bad design in the wild. >>> >>> >>> >>> 1) Embedded references (like created_by_ref and object_markings_ref). >>> These references are "facts" that will be known to the TLO.  However, like >>> you said, a consumer may not have the reference yet, or may not have access >>> to the referenced object.  For data markings we say, that if you do not have >>> the object_markings_ref object, and you can not get it via another TAXII >>> call, than you MUST stop processing the TLO.  In the real-world, you will >>> have out-of-band gates that prevent you from ever sharing threat >>> intelligence with someone that does not have access to the same the >>> data-markings that you have access to. >>> >>> >>> >>> 2) Relationship Objects.  These relationships are used for assertions or >>> opinions about things.  So if you link an Observation to a Campaign, or an >>> Incident to an IntrusionSet, you would use one of these external >>> relationships to link it together.  This will allow you, in the future, to >>> place a confidence score on your assertion that these two things are >>> related.  It will also allow in the future for others to potentially >>> down-vote your assertions. >>> >>> >>> >>> Bret >>> >>> >>> >>> ________________________________ >>> >>> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on >>> behalf of Dave Cridland < dave.cridland@surevine.com > >>> Sent: Sunday, June 12, 2016 7:09 AM >>> To: cti-stix@lists.oasis-open.org >>> Subject: [cti-stix] Object Level Markings >>> >>> >>> >>> Hi folks, >>> >>> I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me >>> if I'm missing something, or retracing your steps, or going about things to >>> wrong way. >>> >>> The current section 6.5 appears to discuss aspects of object level >>> markings, and suggests these might cover both legal permissioning (such as >>> Copyright), and MAC systems (such as security labelling). Mixing the two is >>> interesting - I hadn't considered this but it makes sense. >>> >>> Also, the system operates by reference. This is going to be very difficult >>> to manage, and is traditionally avoided in most cases. This is especially >>> true if the referenced label data for the marking is not present within the >>> same transmission, since automated tooling for MAC will become extremely >>> complex (and complexity begets unhappy accreditors). >>> >>> Has the group considered prior art in this space? I'm thinking >>> particularly of XMPP's XEP-0258, but others may also apply. I'm particularly >>> keen to ensure that multipolicy systems will work effectively, since I see >>> that as being very likely in the CTI world shortly. >>> >>> As for multiple orthogonal rules - I don't understand where precedence >>> comes into this. Taking Copyright as an example, if one derives a work from >>> an existing work, the copyright changes, and the license may also change - I >>> don't see the benefit in including a list of previous copyright notices, and >>> then having the systems decide which one applies. >>> >>> I would expect that every marking present would need to be adhered to >>> (some might not be practical to adhere to programmatically, of course). But >>> you can't share something, say, UK SECRET, no matter what the copyright >>> notice says - and vice-versa, an unclassified document cannot be shared if >>> the copyright license is not available. >>> >>> Happy to discuss this further, or or out of any particuar call. >>> >>> Dave. > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >   -- Dave Cridland phone   +448454681066 email   dave.cridland@surevine.com skype  dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us.

Directly affected would be the military and intelligence communities. Those include some national and transnational CERTS, of course. They're affected because they do things correctly, of course... The workaround would be to run adapters on ether side of a guard, which is unfortunate, since it means two protocol breaks instead of one. Other protocols used in secure environments, like XMPP, don't need this, and my approach would be to use those instead of TAXII if we can't solve the issue here. On 15 Jun 2016 22:47, "Terry MacDonald" < terry.macdonald@cosive.com > wrote: Looking at the 80/20 rule, is this something that is critical for most of the user population? Or something that affects a smaller percentage? Is it something for which there can be a specific workaround for the affected community only? I personally are fine with the current way we do things, and I would be interested to see a ballot on this topic to see how much this affects the general population, rather than a specific subset. Cheers Terry MacDonald On 15/06/2016 10:39, "Wunder, John A." < jwunder@mitre.org > wrote: When you say “we”…is that something you think we should mandate in the specification, or is it something that we can leave as-is in the specification and you can make a rule for your sharing community when you need to transit a guard?   As Bret said, I don’t think having them mandated in the same bundle is doable for the specification given our current approach. We would need to work through another option. But, it’s definitely something you could do in your own usage as you define the interface for what goes across the guard (which will almost certainly need to be a restriction of STIX anyway).   John   From: Dave Cridland < dave.cridland@surevine.com > Date: Tuesday, June 14, 2016 at 8:31 AM To: "Wunder, John A." < jwunder@mitre.org > Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Object Level Markings   John,   Funnily enough, my recent work with cross-domain guards has transformed XML into JSON for transit - but that point is somewhat moot.   If we can mandate that the marking-definition is in the same bundle as the marked data, I can live with the rest.   Dave.   On 14 June 2016 at 00:02, Wunder, John A. < jwunder@mitre.org > wrote: Dave, We’ve had some discussions about how STIX could transit a guard/CDS…keep in mind that there are very few/no existing guards that can transit JSON anyway, or understand our granular markings approach, so this restriction for transiting a guard is just one among many. It’s almost certain that any time STIX needs to move across domains it would need to be transformed into a more restrictive, XML-based language anyway, where (if necessary) the markings can be kept locally. Even in the JSON version, you could do that by putting the marking-definition in the same bundle as the marked data anyway (I expect this will be very common). It sounds like we need to fail the motion for unanimous consent and talk about this on the next working call. The SC needs to discuss Dave’s concerns and decide whether to open the data markings topic for further discussion/rewrite or whether to just proceed with a ballot on the current approach. John On 6/13/16, 1:20 PM, " cti-stix@lists.oasis-open.org on behalf of Jerome Athias" < cti-stix@lists.oasis-open.org on behalf of athiasjerome@gmail.com > wrote: >Dave, > >Welcome! And good luck here >You could be interested by > https://lists.oasis-open.org/archives/cti-users/201604/msg00005.html > >Regards > > > >2016-06-13 19:10 GMT+03:00 Dave Cridland < dave.cridland@surevine.com >: >> Bret, >> >> There's no semantic difference between a labelling scheme that mandates >> inline and a labelling scheme whose mandatory inline form is a reference to >> external information. If you want a single method, then inlining is the one, >> and the inline form can then optionally consist of just a reference. But if >> it's all references, and the reference is to another object within the same >> PDU, or transaction, then this is mostly a matter of personal taste and not >> a hill for me to die on. >> >> Similarly, while I'd prefer the display marking to be in the JSON payload I >> can live without it. >> >> But I do think there are serious problems with having labelling metadata >> arrive in a different transaction than the TLO (and therefore potentially >> not at all). If you're considering only originators and consumers in a >> corporate setting, this might not seem like a major problem, but if you >> consider border gateways and guard systems, especially within secure >> environments, it can introduce an entirely new failure state. If the source >> system fails before the gateway can ascertain the label of the data, then it >> is unable to know if the data should be forwarded, rejected (with a logged >> exception), or stored pending. From a security standpoint, I don't know what >> happens if an attempt to deference a label reference fails. >> >> That's aside from considerations about cryptographic binding of label >> metadata to the object - we can handwave over that to a degree if we assume >> that we can carry both the TLO and the labelling object within the same >> secure channel (TLS, for example), but otherwise there's a risk that a label >> dereferenced by a later transaction would be different from the intention >> when the object was transmitted, and this isn't something we can specify >> around - we need cryptographic proof. >> >> Dave. >> >> We need to make sure we have "one-way" of doing things.  If there are >> multiple ways of doing the same thing, then we will have a fragile design. >> Further, one of our original designs or hopes was that certain common data >> markings might become well known thus reducing the need to re-transmit. >> >> >> I think manual visual inspection of raw JSON is only valid during testing or >> in simple environments.  Inspecting the datamarking in reality is an >> implementation issue, not a specification issue.  Your tool should be able >> to easily dereference the datamarkings and display them for you. >> >> >> Bret >> >> >> >> >> ________________________________ >> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on >> behalf of Dave Cridland < dave.cridland@surevine.com > >> Sent: Monday, June 13, 2016 2:20 AM >> To: Wunder, John A. >> Cc: cti-stix@lists.oasis-open.org >> Subject: Re: [cti-stix] Object Level Markings >> >> >> Yes, I'm unclear why the US Gov wants to do labels by reference; I've only >> ever seen that requirement from the US, and never anyone else. I suspect >> it's due to the US having relative few permutations in the labelling scheme, >> whereas the UK (for example) has thousands. >> >> My thought is that while it's certainly useful to move, for example, a full >> copyright license to a reference, in the majority of cases a simple label or >> statement can be presented inline without any problem - it'll likely be >> shorter than the example identifiers given in many cases. >> >> The other issue is that by enforcing everything to be solely by reference, >> the display marking is lost. I worry that this means we lose the ability to >> spot issues by eyeball. >> >> More information: >> >> The display marking is the string that might be printed at the bottom of a >> document, such as "SECRET//NOFORN", or "NATO SECRET". The label is the >> machine readable form, and contains information such as what policy is used. >> Labels come in a variety of formats, from the XML/JSON EDH form that the US >> uses (quite verbose) to the very terse ESS, used in S/MIME for example. This >> latter form is usually much smaller than a display marking; a typical US >> label in ESS form is perhaps 20 bytes - smaller than your identifier. >> >> As far as precedence is concerned, the only case I can think of where this >> might be important is where you have policy translation going on. Say the >> information originates in NATO, for example, as NATO SECRET, and moves to a >> UK domain, where it needs marking as UK SECRET (I simplify of course). The >> "most correct" label is still the NATO one, and the UK Equivalent Label is >> only there for systems that only understand the local policy. You can >> exchange "NATO" for "CERT-US" and "UK" for "FS-ISAC" if you prefer. >> >> But in this case you want to group the labels and mark the equivalent ones >> such that they can easily be ignored. >> >> I can live with being in the rough on referenced labels, though I would >> prefer an option to inline the data. >> >> I'm worried that "precedence" isn't thought through quite enough. >> >> I'm happy to write some text that covers my concerns. >> >> On 12 Jun 2016 11:31 p.m., "Wunder, John A." < jwunder@mitre.org > wrote: >>> >>> To explain a bit more, doing markings by reference was something that was >>> requested by some US government folks who wanted to avoid representing >>> duplicative markings over and over again. While things like TLP are very >>> short and can easily be duplicated over and over, other marking statements >>> (copyrights, government markings, and likely whatever the FIRST SIG creates) >>> will be larger and more complicated and so being able to reference those >>> from 1000 indicators rather than duplicate them seems to make sense. As Bret >>> said, we added normative text to make sure we covered this case. >>> >>> >>> >>> As for precedence, it’s a bit of a hard topic. In some cases (TLP) you >>> really only have one marking that can apply…it doesn’t make sense for an >>> object to have both TLP:GREEN and TLP:RED. In other cases, like terms of >>> use, you have several that apply. In other cases, like more complicated >>> structured markings, it’s possible for multiple to apply and override parts >>> of the other. We didn’t want to address this in STIX so simply defined what >>> it meant for markings to have precedence and will let the marking >>> definitions themselves figure out what that means. Note that, as you said, >>> it’s definitely true that markings of different types will not override each >>> other. This is why we said that precedence rules only apply to markings of >>> the same type. >>> >>> >>> >>> When first designing data markings in 1.x and discussing them for 2.0 we >>> had very good participation from people in government who mark things every >>> day and that led us to the reference approach (among other things). We did >>> discuss other approaches, in particular NIEM…I also did a quick search and >>> it looks like you actually brought up XEP-0258 at the time. You can review >>> here: https://lists.oasis-open.org/archives/cti-users/201511/msg00002.html . >>> The conversation was a bit different than applying markings, it was about >>> the markings that get applied themselves, and I think is what led to our >>> following the FIRST SIG on Information Sharing. >>> >>> >>> >>> Anyway, how would you like me to treat this comment? Should I assume it’s >>> an objection to the motion for unanimous consent that I made on Friday? If >>> so, as a community we need to decide whether we want to open a data markings >>> discussion or just hold a ballot to accept what we have. >>> >>> >>> >>> John >>> >>> >>> >>> From: < cti-stix@lists.oasis-open.org > on behalf of "Jordan, Bret" >>> < bret.jordan@bluecoat.com > >>> Date: Sunday, June 12, 2016 at 5:14 PM >>> To: Dave Cridland < dave.cridland@surevine.com >, >>> " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > >>> Subject: Re: [cti-stix] Object Level Markings >>> >>> >>> >>> Dave, >>> >>> >>> >>> Great comments and questions.....   Let me try and fill in some of the >>> gaps....  Yes, in STIX 2.0 we will have two types of relationships....  And >>> as a general rule most everything will use a relationship in STIX 2.0. >>> Nested content in STIX 1.x proved to be a bad design in the wild. >>> >>> >>> >>> 1) Embedded references (like created_by_ref and object_markings_ref). >>> These references are "facts" that will be known to the TLO.  However, like >>> you said, a consumer may not have the reference yet, or may not have access >>> to the referenced object.  For data markings we say, that if you do not have >>> the object_markings_ref object, and you can not get it via another TAXII >>> call, than you MUST stop processing the TLO.  In the real-world, you will >>> have out-of-band gates that prevent you from ever sharing threat >>> intelligence with someone that does not have access to the same the >>> data-markings that you have access to. >>> >>> >>> >>> 2) Relationship Objects.  These relationships are used for assertions or >>> opinions about things.  So if you link an Observation to a Campaign, or an >>> Incident to an IntrusionSet, you would use one of these external >>> relationships to link it together.  This will allow you, in the future, to >>> place a confidence score on your assertion that these two things are >>> related.  It will also allow in the future for others to potentially >>> down-vote your assertions. >>> >>> >>> >>> Bret >>> >>> >>> >>> ________________________________ >>> >>> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on >>> behalf of Dave Cridland < dave.cridland@surevine.com > >>> Sent: Sunday, June 12, 2016 7:09 AM >>> To: cti-stix@lists.oasis-open.org >>> Subject: [cti-stix] Object Level Markings >>> >>> >>> >>> Hi folks, >>> >>> I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me >>> if I'm missing something, or retracing your steps, or going about things to >>> wrong way. >>> >>> The current section 6.5 appears to discuss aspects of object level >>> markings, and suggests these might cover both legal permissioning (such as >>> Copyright), and MAC systems (such as security labelling). Mixing the two is >>> interesting - I hadn't considered this but it makes sense. >>> >>> Also, the system operates by reference. This is going to be very difficult >>> to manage, and is traditionally avoided in most cases. This is especially >>> true if the referenced label data for the marking is not present within the >>> same transmission, since automated tooling for MAC will become extremely >>> complex (and complexity begets unhappy accreditors). >>> >>> Has the group considered prior art in this space? I'm thinking >>> particularly of XMPP's XEP-0258, but others may also apply. I'm particularly >>> keen to ensure that multipolicy systems will work effectively, since I see >>> that as being very likely in the CTI world shortly. >>> >>> As for multiple orthogonal rules - I don't understand where precedence >>> comes into this. Taking Copyright as an example, if one derives a work from >>> an existing work, the copyright changes, and the license may also change - I >>> don't see the benefit in including a list of previous copyright notices, and >>> then having the systems decide which one applies. >>> >>> I would expect that every marking present would need to be adhered to >>> (some might not be practical to adhere to programmatically, of course). But >>> you can't share something, say, UK SECRET, no matter what the copyright >>> notice says - and vice-versa, an unclassified document cannot be shared if >>> the copyright license is not available. >>> >>> Happy to discuss this further, or or out of any particuar call. >>> >>> Dave. > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >   -- Dave Cridland phone   +448454681066 email   dave.cridland@surevine.com skype  dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us.

If this is so, then how come we've not had this issue raised before when I know that we have people from national CERTs and intelligence agencies on this list? It just seems to me that we are revisiting something that was discussed at length, explicitly designed to be 'by reference' to enable scalability, that covered all the issues that people had previously, where one person is mentioning this as an issue for a subset of the community. For that reason I would like to see how many people believe that it is an issue. If it is a sizeable percentage, then we should revisit it - otherwise we leave it the way it is, and it is up to the specific sharing communities to extend STIX using custom fields . I motion that we have a ballot that asks if the data marking section is acceptable just the way it is. Cheers Terry MacDonald   Chief Product Officer M:   +61-407-203-026 E:   terry.macdonald@cosive.com W:   www.cosive.com On Thu, Jun 16, 2016 at 8:50 AM, Dave Cridland < dave.cridland@surevine.com > wrote: Directly affected would be the military and intelligence communities. Those include some national and transnational CERTS, of course. They're affected because they do things correctly, of course... The workaround would be to run adapters on ether side of a guard, which is unfortunate, since it means two protocol breaks instead of one. Other protocols used in secure environments, like XMPP, don't need this, and my approach would be to use those instead of TAXII if we can't solve the issue here. On 15 Jun 2016 22:47, "Terry MacDonald" < terry.macdonald@cosive.com > wrote: Looking at the 80/20 rule, is this something that is critical for most of the user population? Or something that affects a smaller percentage? Is it something for which there can be a specific workaround for the affected community only? I personally are fine with the current way we do things, and I would be interested to see a ballot on this topic to see how much this affects the general population, rather than a specific subset. Cheers Terry MacDonald On 15/06/2016 10:39, "Wunder, John A." < jwunder@mitre.org > wrote: When you say “we”…is that something you think we should mandate in the specification, or is it something that we can leave as-is in the specification and you can make a rule for your sharing community when you need to transit a guard?   As Bret said, I don’t think having them mandated in the same bundle is doable for the specification given our current approach. We would need to work through another option. But, it’s definitely something you could do in your own usage as you define the interface for what goes across the guard (which will almost certainly need to be a restriction of STIX anyway).   John   From: Dave Cridland < dave.cridland@surevine.com > Date: Tuesday, June 14, 2016 at 8:31 AM To: "Wunder, John A." < jwunder@mitre.org > Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Object Level Markings   John,   Funnily enough, my recent work with cross-domain guards has transformed XML into JSON for transit - but that point is somewhat moot.   If we can mandate that the marking-definition is in the same bundle as the marked data, I can live with the rest.   Dave.   On 14 June 2016 at 00:02, Wunder, John A. < jwunder@mitre.org > wrote: Dave, We’ve had some discussions about how STIX could transit a guard/CDS…keep in mind that there are very few/no existing guards that can transit JSON anyway, or understand our granular markings approach, so this restriction for transiting a guard is just one among many. It’s almost certain that any time STIX needs to move across domains it would need to be transformed into a more restrictive, XML-based language anyway, where (if necessary) the markings can be kept locally. Even in the JSON version, you could do that by putting the marking-definition in the same bundle as the marked data anyway (I expect this will be very common). It sounds like we need to fail the motion for unanimous consent and talk about this on the next working call. The SC needs to discuss Dave’s concerns and decide whether to open the data markings topic for further discussion/rewrite or whether to just proceed with a ballot on the current approach. John On 6/13/16, 1:20 PM, " cti-stix@lists.oasis-open.org on behalf of Jerome Athias" < cti-stix@lists.oasis-open.org on behalf of athiasjerome@gmail.com > wrote: >Dave, > >Welcome! And good luck here >You could be interested by > https://lists.oasis-open.org/archives/cti-users/201604/msg00005.html > >Regards > > > >2016-06-13 19:10 GMT+03:00 Dave Cridland < dave.cridland@surevine.com >: >> Bret, >> >> There's no semantic difference between a labelling scheme that mandates >> inline and a labelling scheme whose mandatory inline form is a reference to >> external information. If you want a single method, then inlining is the one, >> and the inline form can then optionally consist of just a reference. But if >> it's all references, and the reference is to another object within the same >> PDU, or transaction, then this is mostly a matter of personal taste and not >> a hill for me to die on. >> >> Similarly, while I'd prefer the display marking to be in the JSON payload I >> can live without it. >> >> But I do think there are serious problems with having labelling metadata >> arrive in a different transaction than the TLO (and therefore potentially >> not at all). If you're considering only originators and consumers in a >> corporate setting, this might not seem like a major problem, but if you >> consider border gateways and guard systems, especially within secure >> environments, it can introduce an entirely new failure state. If the source >> system fails before the gateway can ascertain the label of the data, then it >> is unable to know if the data should be forwarded, rejected (with a logged >> exception), or stored pending. From a security standpoint, I don't know what >> happens if an attempt to deference a label reference fails. >> >> That's aside from considerations about cryptographic binding of label >> metadata to the object - we can handwave over that to a degree if we assume >> that we can carry both the TLO and the labelling object within the same >> secure channel (TLS, for example), but otherwise there's a risk that a label >> dereferenced by a later transaction would be different from the intention >> when the object was transmitted, and this isn't something we can specify >> around - we need cryptographic proof. >> >> Dave. >> >> We need to make sure we have "one-way" of doing things.  If there are >> multiple ways of doing the same thing, then we will have a fragile design. >> Further, one of our original designs or hopes was that certain common data >> markings might become well known thus reducing the need to re-transmit. >> >> >> I think manual visual inspection of raw JSON is only valid during testing or >> in simple environments.  Inspecting the datamarking in reality is an >> implementation issue, not a specification issue.  Your tool should be able >> to easily dereference the datamarkings and display them for you. >> >> >> Bret >> >> >> >> >> ________________________________ >> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on >> behalf of Dave Cridland < dave.cridland@surevine.com > >> Sent: Monday, June 13, 2016 2:20 AM >> To: Wunder, John A. >> Cc: cti-stix@lists.oasis-open.org >> Subject: Re: [cti-stix] Object Level Markings >> >> >> Yes, I'm unclear why the US Gov wants to do labels by reference; I've only >> ever seen that requirement from the US, and never anyone else. I suspect >> it's due to the US having relative few permutations in the labelling scheme, >> whereas the UK (for example) has thousands. >> >> My thought is that while it's certainly useful to move, for example, a full >> copyright license to a reference, in the majority of cases a simple label or >> statement can be presented inline without any problem - it'll likely be >> shorter than the example identifiers given in many cases. >> >> The other issue is that by enforcing everything to be solely by reference, >> the display marking is lost. I worry that this means we lose the ability to >> spot issues by eyeball. >> >> More information: >> >> The display marking is the string that might be printed at the bottom of a >> document, such as "SECRET//NOFORN", or "NATO SECRET". The label is the >> machine readable form, and contains information such as what policy is used. >> Labels come in a variety of formats, from the XML/JSON EDH form that the US >> uses (quite verbose) to the very terse ESS, used in S/MIME for example. This >> latter form is usually much smaller than a display marking; a typical US >> label in ESS form is perhaps 20 bytes - smaller than your identifier. >> >> As far as precedence is concerned, the only case I can think of where this >> might be important is where you have policy translation going on. Say the >> information originates in NATO, for example, as NATO SECRET, and moves to a >> UK domain, where it needs marking as UK SECRET (I simplify of course). The >> "most correct" label is still the NATO one, and the UK Equivalent Label is >> only there for systems that only understand the local policy. You can >> exchange "NATO" for "CERT-US" and "UK" for "FS-ISAC" if you prefer. >> >> But in this case you want to group the labels and mark the equivalent ones >> such that they can easily be ignored. >> >> I can live with being in the rough on referenced labels, though I would >> prefer an option to inline the data. >> >> I'm worried that "precedence" isn't thought through quite enough. >> >> I'm happy to write some text that covers my concerns. >> >> On 12 Jun 2016 11:31 p.m., "Wunder, John A." < jwunder@mitre.org > wrote: >>> >>> To explain a bit more, doing markings by reference was something that was >>> requested by some US government folks who wanted to avoid representing >>> duplicative markings over and over again. While things like TLP are very >>> short and can easily be duplicated over and over, other marking statements >>> (copyrights, government markings, and likely whatever the FIRST SIG creates) >>> will be larger and more complicated and so being able to reference those >>> from 1000 indicators rather than duplicate them seems to make sense. As Bret >>> said, we added normative text to make sure we covered this case. >>> >>> >>> >>> As for precedence, it’s a bit of a hard topic. In some cases (TLP) you >>> really only have one marking that can apply…it doesn’t make sense for an >>> object to have both TLP:GREEN and TLP:RED. In other cases, like terms of >>> use, you have several that apply. In other cases, like more complicated >>> structured markings, it’s possible for multiple to apply and override parts >>> of the other. We didn’t want to address this in STIX so simply defined what >>> it meant for markings to have precedence and will let the marking >>> definitions themselves figure out what that means. Note that, as you said, >>> it’s definitely true that markings of different types will not override each >>> other. This is why we said that precedence rules only apply to markings of >>> the same type. >>> >>> >>> >>> When first designing data markings in 1.x and discussing them for 2.0 we >>> had very good participation from people in government who mark things every >>> day and that led us to the reference approach (among other things). We did >>> discuss other approaches, in particular NIEM…I also did a quick search and >>> it looks like you actually brought up XEP-0258 at the time. You can review >>> here: https://lists.oasis-open.org/archives/cti-users/201511/msg00002.html . >>> The conversation was a bit different than applying markings, it was about >>> the markings that get applied themselves, and I think is what led to our >>> following the FIRST SIG on Information Sharing. >>> >>> >>> >>> Anyway, how would you like me to treat this comment? Should I assume it’s >>> an objection to the motion for unanimous consent that I made on Friday? If >>> so, as a community we need to decide whether we want to open a data markings >>> discussion or just hold a ballot to accept what we have. >>> >>> >>> >>> John >>> >>> >>> >>> From: < cti-stix@lists.oasis-open.org > on behalf of "Jordan, Bret" >>> < bret.jordan@bluecoat.com > >>> Date: Sunday, June 12, 2016 at 5:14 PM >>> To: Dave Cridland < dave.cridland@surevine.com >, >>> " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > >>> Subject: Re: [cti-stix] Object Level Markings >>> >>> >>> >>> Dave, >>> >>> >>> >>> Great comments and questions.....   Let me try and fill in some of the >>> gaps....  Yes, in STIX 2.0 we will have two types of relationships....  And >>> as a general rule most everything will use a relationship in STIX 2.0. >>> Nested content in STIX 1.x proved to be a bad design in the wild. >>> >>> >>> >>> 1) Embedded references (like created_by_ref and object_markings_ref). >>> These references are "facts" that will be known to the TLO.  However, like >>> you said, a consumer may not have the reference yet, or may not have access >>> to the referenced object.  For data markings we say, that if you do not have >>> the object_markings_ref object, and you can not get it via another TAXII >>> call, than you MUST stop processing the TLO.  In the real-world, you will >>> have out-of-band gates that prevent you from ever sharing threat >>> intelligence with someone that does not have access to the same the >>> data-markings that you have access to. >>> >>> >>> >>> 2) Relationship Objects.  These relationships are used for assertions or >>> opinions about things.  So if you link an Observation to a Campaign, or an >>> Incident to an IntrusionSet, you would use one of these external >>> relationships to link it together.  This will allow you, in the future, to >>> place a confidence score on your assertion that these two things are >>> related.  It will also allow in the future for others to potentially >>> down-vote your assertions. >>> >>> >>> >>> Bret >>> >>> >>> >>> ________________________________ >>> >>> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on >>> behalf of Dave Cridland < dave.cridland@surevine.com > >>> Sent: Sunday, June 12, 2016 7:09 AM >>> To: cti-stix@lists.oasis-open.org >>> Subject: [cti-stix] Object Level Markings >>> >>> >>> >>> Hi folks, >>> >>> I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me >>> if I'm missing something, or retracing your steps, or going about things to >>> wrong way. >>> >>> The current section 6.5 appears to discuss aspects of object level >>> markings, and suggests these might cover both legal permissioning (such as >>> Copyright), and MAC systems (such as security labelling). Mixing the two is >>> interesting - I hadn't considered this but it makes sense. >>> >>> Also, the system operates by reference. This is going to be very difficult >>> to manage, and is traditionally avoided in most cases. This is especially >>> true if the referenced label data for the marking is not present within the >>> same transmission, since automated tooling for MAC will become extremely >>> complex (and complexity begets unhappy accreditors). >>> >>> Has the group considered prior art in this space? I'm thinking >>> particularly of XMPP's XEP-0258, but others may also apply. I'm particularly >>> keen to ensure that multipolicy systems will work effectively, since I see >>> that as being very likely in the CTI world shortly. >>> >>> As for multiple orthogonal rules - I don't understand where precedence >>> comes into this. Taking Copyright as an example, if one derives a work from >>> an existing work, the copyright changes, and the license may also change - I >>> don't see the benefit in including a list of previous copyright notices, and >>> then having the systems decide which one applies. >>> >>> I would expect that every marking present would need to be adhered to >>> (some might not be practical to adhere to programmatically, of course). But >>> you can't share something, say, UK SECRET, no matter what the copyright >>> notice says - and vice-versa, an unclassified document cannot be shared if >>> the copyright license is not available. >>> >>> Happy to discuss this further, or or out of any particuar call. >>> >>> Dave. > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >   -- Dave Cridland phone   +448454681066 email   dave.cridland@surevine.com skype  dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us.

I second the motion to open a ballot on data markings. Bret From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@cosive.com> Sent: Wednesday, June 15, 2016 5:57 PM To: Dave Cridland Cc: cti-stix@lists.oasis-open.org; Wunder, John A. Subject: Re: [cti-stix] Object Level Markings   If this is so, then how come we've not had this issue raised before when I know that we have people from national CERTs and intelligence agencies on this list? It just seems to me that we are revisiting something that was discussed at length, explicitly designed to be 'by reference' to enable scalability, that covered all the issues that people had previously, where one person is mentioning this as an issue for a subset of the community. For that reason I would like to see how many people believe that it is an issue. If it is a sizeable percentage, then we should revisit it - otherwise we leave it the way it is, and it is up to the specific sharing communities to extend STIX using custom fields . I motion that we have a ballot that asks if the data marking section is acceptable just the way it is. Cheers Terry MacDonald   Chief Product Officer M:   +61-407-203-026 E:   terry.macdonald@cosive.com W:   www.cosive.com On Thu, Jun 16, 2016 at 8:50 AM, Dave Cridland < dave.cridland@surevine.com > wrote: Directly affected would be the military and intelligence communities. Those include some national and transnational CERTS, of course. They're affected because they do things correctly, of course... The workaround would be to run adapters on ether side of a guard, which is unfortunate, since it means two protocol breaks instead of one. Other protocols used in secure environments, like XMPP, don't need this, and my approach would be to use those instead of TAXII if we can't solve the issue here. On 15 Jun 2016 22:47, "Terry MacDonald" < terry.macdonald@cosive.com > wrote: Looking at the 80/20 rule, is this something that is critical for most of the user population? Or something that affects a smaller percentage? Is it something for which there can be a specific workaround for the affected community only? I personally are fine with the current way we do things, and I would be interested to see a ballot on this topic to see how much this affects the general population, rather than a specific subset. Cheers Terry MacDonald On 15/06/2016 10:39, "Wunder, John A." < jwunder@mitre.org > wrote: When you say “we”…is that something you think we should mandate in the specification, or is it something that we can leave as-is in the specification and you can make a rule for your sharing community when you need to transit a guard?   As Bret said, I don’t think having them mandated in the same bundle is doable for the specification given our current approach. We would need to work through another option. But, it’s definitely something you could do in your own usage as you define the interface for what goes across the guard (which will almost certainly need to be a restriction of STIX anyway).   John   From: Dave Cridland < dave.cridland@surevine.com > Date: Tuesday, June 14, 2016 at 8:31 AM To: "Wunder, John A." < jwunder@mitre.org > Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Object Level Markings   John,   Funnily enough, my recent work with cross-domain guards has transformed XML into JSON for transit - but that point is somewhat moot.   If we can mandate that the marking-definition is in the same bundle as the marked data, I can live with the rest.   Dave.   On 14 June 2016 at 00:02, Wunder, John A. < jwunder@mitre.org > wrote: Dave, We’ve had some discussions about how STIX could transit a guard/CDS…keep in mind that there are very few/no existing guards that can transit JSON anyway, or understand our granular markings approach, so this restriction for transiting a guard is just one among many. It’s almost certain that any time STIX needs to move across domains it would need to be transformed into a more restrictive, XML-based language anyway, where (if necessary) the markings can be kept locally. Even in the JSON version, you could do that by putting the marking-definition in the same bundle as the marked data anyway (I expect this will be very common). It sounds like we need to fail the motion for unanimous consent and talk about this on the next working call. The SC needs to discuss Dave’s concerns and decide whether to open the data markings topic for further discussion/rewrite or whether to just proceed with a ballot on the current approach. John On 6/13/16, 1:20 PM, " cti-stix@lists.oasis-open.org on behalf of Jerome Athias" < cti-stix@lists.oasis-open.org on behalf of athiasjerome@gmail.com > wrote: >Dave, > >Welcome! And good luck here >You could be interested by > https://lists.oasis-open.org/archives/cti-users/201604/msg00005.html > >Regards > > > >2016-06-13 19:10 GMT+03:00 Dave Cridland < dave.cridland@surevine.com >: >> Bret, >> >> There's no semantic difference between a labelling scheme that mandates >> inline and a labelling scheme whose mandatory inline form is a reference to >> external information. If you want a single method, then inlining is the one, >> and the inline form can then optionally consist of just a reference. But if >> it's all references, and the reference is to another object within the same >> PDU, or transaction, then this is mostly a matter of personal taste and not >> a hill for me to die on. >> >> Similarly, while I'd prefer the display marking to be in the JSON payload I >> can live without it. >> >> But I do think there are serious problems with having labelling metadata >> arrive in a different transaction than the TLO (and therefore potentially >> not at all). If you're considering only originators and consumers in a >> corporate setting, this might not seem like a major problem, but if you >> consider border gateways and guard systems, especially within secure >> environments, it can introduce an entirely new failure state. If the source >> system fails before the gateway can ascertain the label of the data, then it >> is unable to know if the data should be forwarded, rejected (with a logged >> exception), or stored pending. From a security standpoint, I don't know what >> happens if an attempt to deference a label reference fails. >> >> That's aside from considerations about cryptographic binding of label >> metadata to the object - we can handwave over that to a degree if we assume >> that we can carry both the TLO and the labelling object within the same >> secure channel (TLS, for example), but otherwise there's a risk that a label >> dereferenced by a later transaction would be different from the intention >> when the object was transmitted, and this isn't something we can specify >> around - we need cryptographic proof. >> >> Dave. >> >> We need to make sure we have "one-way" of doing things.  If there are >> multiple ways of doing the same thing, then we will have a fragile design. >> Further, one of our original designs or hopes was that certain common data >> markings might become well known thus reducing the need to re-transmit. >> >> >> I think manual visual inspection of raw JSON is only valid during testing or >> in simple environments.  Inspecting the datamarking in reality is an >> implementation issue, not a specification issue.  Your tool should be able >> to easily dereference the datamarkings and display them for you. >> >> >> Bret >> >> >> >> >> ________________________________ >> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on >> behalf of Dave Cridland < dave.cridland@surevine.com > >> Sent: Monday, June 13, 2016 2:20 AM >> To: Wunder, John A. >> Cc: cti-stix@lists.oasis-open.org >> Subject: Re: [cti-stix] Object Level Markings >> >> >> Yes, I'm unclear why the US Gov wants to do labels by reference; I've only >> ever seen that requirement from the US, and never anyone else. I suspect >> it's due to the US having relative few permutations in the labelling scheme, >> whereas the UK (for example) has thousands. >> >> My thought is that while it's certainly useful to move, for example, a full >> copyright license to a reference, in the majority of cases a simple label or >> statement can be presented inline without any problem - it'll likely be >> shorter than the example identifiers given in many cases. >> >> The other issue is that by enforcing everything to be solely by reference, >> the display marking is lost. I worry that this means we lose the ability to >> spot issues by eyeball. >> >> More information: >> >> The display marking is the string that might be printed at the bottom of a >> document, such as "SECRET//NOFORN", or "NATO SECRET". The label is the >> machine readable form, and contains information such as what policy is used. >> Labels come in a variety of formats, from the XML/JSON EDH form that the US >> uses (quite verbose) to the very terse ESS, used in S/MIME for example. This >> latter form is usually much smaller than a display marking; a typical US >> label in ESS form is perhaps 20 bytes - smaller than your identifier. >> >> As far as precedence is concerned, the only case I can think of where this >> might be important is where you have policy translation going on. Say the >> information originates in NATO, for example, as NATO SECRET, and moves to a >> UK domain, where it needs marking as UK SECRET (I simplify of course). The >> "most correct" label is still the NATO one, and the UK Equivalent Label is >> only there for systems that only understand the local policy. You can >> exchange "NATO" for "CERT-US" and "UK" for "FS-ISAC" if you prefer. >> >> But in this case you want to group the labels and mark the equivalent ones >> such that they can easily be ignored. >> >> I can live with being in the rough on referenced labels, though I would >> prefer an option to inline the data. >> >> I'm worried that "precedence" isn't thought through quite enough. >> >> I'm happy to write some text that covers my concerns. >> >> On 12 Jun 2016 11:31 p.m., "Wunder, John A." < jwunder@mitre.org > wrote: >>> >>> To explain a bit more, doing markings by reference was something that was >>> requested by some US government folks who wanted to avoid representing >>> duplicative markings over and over again. While things like TLP are very >>> short and can easily be duplicated over and over, other marking statements >>> (copyrights, government markings, and likely whatever the FIRST SIG creates) >>> will be larger and more complicated and so being able to reference those >>> from 1000 indicators rather than duplicate them seems to make sense. As Bret >>> said, we added normative text to make sure we covered this case. >>> >>> >>> >>> As for precedence, it’s a bit of a hard topic. In some cases (TLP) you >>> really only have one marking that can apply…it doesn’t make sense for an >>> object to have both TLP:GREEN and TLP:RED. In other cases, like terms of >>> use, you have several that apply. In other cases, like more complicated >>> structured markings, it’s possible for multiple to apply and override parts >>> of the other. We didn’t want to address this in STIX so simply defined what >>> it meant for markings to have precedence and will let the marking >>> definitions themselves figure out what that means. Note that, as you said, >>> it’s definitely true that markings of different types will not override each >>> other. This is why we said that precedence rules only apply to markings of >>> the same type. >>> >>> >>> >>> When first designing data markings in 1.x and discussing them for 2.0 we >>> had very good participation from people in government who mark things every >>> day and that led us to the reference approach (among other things). We did >>> discuss other approaches, in particular NIEM…I also did a quick search and >>> it looks like you actually brought up XEP-0258 at the time. You can review >>> here: https://lists.oasis-open.org/archives/cti-users/201511/msg00002.html . >>> The conversation was a bit different than applying markings, it was about >>> the markings that get applied themselves, and I think is what led to our >>> following the FIRST SIG on Information Sharing. >>> >>> >>> >>> Anyway, how would you like me to treat this comment? Should I assume it’s >>> an objection to the motion for unanimous consent that I made on Friday? If >>> so, as a community we need to decide whether we want to open a data markings >>> discussion or just hold a ballot to accept what we have. >>> >>> >>> >>> John >>> >>> >>> >>> From: < cti-stix@lists.oasis-open.org > on behalf of "Jordan, Bret" >>> < bret.jordan@bluecoat.com > >>> Date: Sunday, June 12, 2016 at 5:14 PM >>> To: Dave Cridland < dave.cridland@surevine.com >, >>> " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > >>> Subject: Re: [cti-stix] Object Level Markings >>> >>> >>> >>> Dave, >>> >>> >>> >>> Great comments and questions.....   Let me try and fill in some of the >>> gaps....  Yes, in STIX 2.0 we will have two types of relationships....  And >>> as a general rule most everything will use a relationship in STIX 2.0. >>> Nested content in STIX 1.x proved to be a bad design in the wild. >>> >>> >>> >>> 1) Embedded references (like created_by_ref and object_markings_ref). >>> These references are "facts" that will be known to the TLO.  However, like >>> you said, a consumer may not have the reference yet, or may not have access >>> to the referenced object.  For data markings we say, that if you do not have >>> the object_markings_ref object, and you can not get it via another TAXII >>> call, than you MUST stop processing the TLO.  In the real-world, you will >>> have out-of-band gates that prevent you from ever sharing threat >>> intelligence with someone that does not have access to the same the >>> data-markings that you have access to. >>> >>> >>> >>> 2) Relationship Objects.  These relationships are used for assertions or >>> opinions about things.  So if you link an Observation to a Campaign, or an >>> Incident to an IntrusionSet, you would use one of these external >>> relationships to link it together.  This will allow you, in the future, to >>> place a confidence score on your assertion that these two things are >>> related.  It will also allow in the future for others to potentially >>> down-vote your assertions. >>> >>> >>> >>> Bret >>> >>> >>> >>> ________________________________ >>> >>> From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on >>> behalf of Dave Cridland < dave.cridland@surevine.com > >>> Sent: Sunday, June 12, 2016 7:09 AM >>> To: cti-stix@lists.oasis-open.org >>> Subject: [cti-stix] Object Level Markings >>> >>> >>> >>> Hi folks, >>> >>> I'm a newcomer to this TC (and indeed OASIS), so you'll have to forgive me >>> if I'm missing something, or retracing your steps, or going about things to >>> wrong way. >>> >>> The current section 6.5 appears to discuss aspects of object level >>> markings, and suggests these might cover both legal permissioning (such as >>> Copyright), and MAC systems (such as security labelling). Mixing the two is >>> interesting - I hadn't considered this but it makes sense. >>> >>> Also, the system operates by reference. This is going to be very difficult >>> to manage, and is traditionally avoided in most cases. This is especially >>> true if the referenced label data for the marking is not present within the >>> same transmission, since automated tooling for MAC will become extremely >>> complex (and complexity begets unhappy accreditors). >>> >>> Has the group considered prior art in this space? I'm thinking >>> particularly of XMPP's XEP-0258, but others may also apply. I'm particularly >>> keen to ensure that multipolicy systems will work effectively, since I see >>> that as being very likely in the CTI world shortly. >>> >>> As for multiple orthogonal rules - I don't understand where precedence >>> comes into this. Taking Copyright as an example, if one derives a work from >>> an existing work, the copyright changes, and the license may also change - I >>> don't see the benefit in including a list of previous copyright notices, and >>> then having the systems decide which one applies. >>> >>> I would expect that every marking present would need to be adhered to >>> (some might not be practical to adhere to programmatically, of course). But >>> you can't share something, say, UK SECRET, no matter what the copyright >>> notice says - and vice-versa, an unclassified document cannot be shared if >>> the copyright license is not available. >>> >>> Happy to discuss this further, or or out of any particuar call. >>> >>> Dave. > >--------------------------------------------------------------------- >To unsubscribe from this mail list, you must leave the OASIS TC that >generates this mail.  Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >   -- Dave Cridland phone   +448454681066 email   dave.cridland@surevine.com skype  dave.cridland.surevine Participate Collaborate Innovate Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND If you think you have received this message in error, please notify us.