CTI STIX Subcommittee

I fully support this option as would be expected.
Kudos to John for such a great writeup explaining the idea.


sean








From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Thursday, December 3, 2015 at 3:11 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Applying data markings





All,


I developed this proposal to handle the application of data markings in STIX 2.0:  https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings
themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.


I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about feedback.
If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).


John

This does look like a good approach for message level markings.

Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements”
have been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation
of any categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance”
document augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and
categorizations. I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking.
-Cory
 


From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Barnum, Sean D.
Sent: Monday, December 07, 2015 9:49 AM
To: Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings


 


I fully support this option as would be expected.


Kudos to John for such a great writeup explaining the idea.


 


sean



 


From:
" cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of John Wunder
< jwunder@mitre.org >
Date: Thursday, December 3, 2015 at 3:11 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Applying data markings


 



All,


 


I developed this proposal to handle the application of data markings in STIX 2.0:  https://github.com/johnwunder/data-markings .
Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.


 


I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings
for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).


 


John

All,


I updated the proposal based on the comments from last week:  https://github.com/johnwunder/data-markings .


A few comments (on the comments…):


- Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back.


- Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that
if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s
earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2).


- Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach
with all the implementation complexity that it brings (as Bryan Worrell can tell you).


- That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath.


To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):


1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (
2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?
3. Should we keep markings at the package level or move all markings to the individual top-level objects?


My answers:


1. Not sure to be honest. Leaning towards not MTI.
2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway.
3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which
means other gov’t may as well.


John



On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote:






This does look like a good approach for message level markings.

Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange
agreements” have been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation
of any categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance”
document augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and
categorizations. I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking.
-Cory
 


From:
cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Barnum, Sean D.
Sent: Monday, December 07, 2015 9:49 AM
To: Wunder, John A.;
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings


 


I fully support this option as would be expected.


Kudos to John for such a great writeup explaining the idea.


 


sean



 


From:
" cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf
of John Wunder < jwunder@mitre.org >
Date: Thursday, December 3, 2015 at 3:11 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Applying data markings


 



All,


 


I developed this proposal to handle the application of data markings in STIX 2.0:  https://github.com/johnwunder/data-markings .
Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.


 


I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings
for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).


 


John

Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (
[sean]I have no dog in the hunt either way though I would think that the “simple” inter-device messaging use cases that Jason frequently describes would likely be hampered by making L1 MTI.


2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?


[sean]Go with it as-is. The current community members stating it as a need are fine with the current approach.


3. Should we keep markings at the package level or move all markings to the individual top-level objects?



[sean] Keep markings at the package level








sean









From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Monday, December 7, 2015 at 3:42 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings





All,


I updated the proposal based on the comments from last week:  https://github.com/johnwunder/data-markings .


A few comments (on the comments…):


- Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back.


- Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that
if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s
earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2).


- Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach
with all the implementation complexity that it brings (as Bryan Worrell can tell you).


- That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath.


To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):


1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (
2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?
3. Should we keep markings at the package level or move all markings to the individual top-level objects?


My answers:


1. Not sure to be honest. Leaning towards not MTI.
2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway.
3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which
means other gov’t may as well.


John



On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote:






This does look like a good approach for message level markings.

Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such
“exchange agreements” have been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit
representation of any categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings
in the “instance” document augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic”
restrictions and categorizations. I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking.
-Cory
 


From: cti-stix@lists.oasis-open.org
[ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Barnum, Sean D.
Sent: Monday, December 07, 2015 9:49 AM
To: Wunder, John A.;
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings


 


I fully support this option as would be expected.


Kudos to John for such a great writeup explaining the idea.


 


sean



 


From:
" cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf
of John Wunder < jwunder@mitre.org >
Date: Thursday, December 3, 2015 at 3:11 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Applying data markings


 



All,


 


I developed this proposal to handle the application of data markings in STIX 2.0:  https://github.com/johnwunder/data-markings .
Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.


 


I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings
for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).


 


John

1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? ( I would probably shy away from making L1 an MTI for now.  We can always make it an MTI later if need be. 2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)? I think we should go with it as is.  Once we get some code written we may find or someone may find that we need to do things differently.  But I played with it a bit over the weekend and I do not see anything majorly wrong.   3. Should we keep markings at the package level or move all markings to the individual top-level objects? Keep them at the package level.   Another thing I would like to ask of the community is...... Can we create the top 10-20 data markings that people will use and publish them as a standalone document on GitHub, maybe with a version or something.  This way people can just reference them.  My guess is that the vast majority of people will use simple L1 markings, and they will probably all be roughly the same.  So it would be nice if there was a common list.  I would NOT want this part of the OASIS standard release process though, as that would take too much time to add new values or make changes. Can this address everyone's needs, NO.  Will it accommodate unique and issues, NO.  Can it accommodate the 80%, I believe so.  Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Dec 7, 2015, at 13:42, Wunder, John A. < jwunder@mitre.org > wrote: All, I updated the proposal based on the comments from last week:  https://github.com/johnwunder/data-markings . A few comments (on the comments…): - Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back. - Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2). - Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you). - That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath. To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”): 1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? ( 2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)? 3. Should we keep markings at the package level or move all markings to the individual top-level objects? My answers: 1. Not sure to be honest. Leaning towards not MTI. 2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway. 3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which means other gov’t may as well. John On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote: This does look like a good approach for message level markings. Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking. -Cory   From:   cti-stix@lists.oasis-open.org   [ mailto:cti-stix@lists.oasis-open.org ]   On Behalf Of   Barnum, Sean D. Sent:   Monday, December 07, 2015 9:49 AM To:   Wunder, John A.;   cti-stix@lists.oasis-open.org Subject:   Re: [cti-stix] Applying data markings   I fully support this option as would be expected. Kudos to John for such a great writeup explaining the idea.   sean   From:   cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org > Date:   Thursday, December 3, 2015 at 3:11 PM To:   cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject:   [cti-stix] Applying data markings   All,   I developed this proposal to handle the application of data markings in STIX 2.0:  https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.   I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).   John Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and
document mark that object as TLP White. 



If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning
rules or the ID hash.




I am not going to put up a huge fight here, but it just seems so obvious to me.




Aharon










From: < cti-stix@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Monday, December 7, 2015 at 3:42 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings





All,


I updated the proposal based on the comments from last week:  https://github.com/johnwunder/data-markings .


A few comments (on the comments…):


- Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back.


- Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that
if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s
earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2).


- Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach
with all the implementation complexity that it brings (as Bryan Worrell can tell you).


- That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath.


To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):


1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (
2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?
3. Should we keep markings at the package level or move all markings to the individual top-level objects?


My answers:


1. Not sure to be honest. Leaning towards not MTI.
2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway.
3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which
means other gov’t may as well.


John



On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote:






This does look like a good approach for message level markings.

Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such
“exchange agreements” have been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit
representation of any categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings
in the “instance” document augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic”
restrictions and categorizations. I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking.
-Cory
 


From: cti-stix@lists.oasis-open.org
[ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Barnum, Sean D.
Sent: Monday, December 07, 2015 9:49 AM
To: Wunder, John A.;
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings


 


I fully support this option as would be expected.


Kudos to John for such a great writeup explaining the idea.


 


sean



 


From:
" cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf
of John Wunder < jwunder@mitre.org >
Date: Thursday, December 3, 2015 at 3:11 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Applying data markings


 



All,


 


I developed this proposal to handle the application of data markings in STIX 2.0:  https://github.com/johnwunder/data-markings .
Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.


 


I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings
for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).


 


John

Since the object defaults to the marking, if any, on the Package level, then the Package level marking goes to the document.
 
Default marking could be a messy matter either way. What if 60% of the Package is one way and 50% is another and both MUST do conveyed in the same Package?
Package level marking will remove the work for 50% but the other 50% will have to implement overwriting object-level marking (still L1).
 
I see your concern with Package vs Object. I think Package level makes it easier for the transfer layer (only mentioned once, if all the same) and adds some
work on the processing level.
 
Revision/ID rules will need to be revisited to take reassigning marking into play, especially if you plan on granting any assurance on handling immutability.
BUT THAT’S ANOTHER THREAD!
 
-Marlon
 


From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Aharon Chernin
Sent: Monday, December 07, 2015 4:27 PM
To: Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings


 



I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within
the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. 


 


If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that
object without breaking the revisioning rules or the ID hash.


 


I am not going to put up a huge fight here, but it just seems so obvious to me.


 


Aharon




 


From:
< cti-stix@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Monday, December 7, 2015 at 3:42 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings


 




All,


 


I updated the proposal based on the comments from last week:  https://github.com/johnwunder/data-markings .


 


A few comments (on the comments…):


 


- Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very
confusing so I switched it back.


 


- Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED
in a single statement (not duplicated across each indicator). OTOH it also means that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re
changing the object itself if you add them to the object, and in any case per Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for
L2).


 


- Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath
instead of XPath, but fundamentally it’s still a controlled structure based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you).


 


- That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding
XPath.


 


To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):


 


1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (


2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?


3. Should we keep markings at the package level or move all markings to the individual top-level objects?


 


My answers:


 


1. Not sure to be honest. Leaning towards not MTI.


2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway.


3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities
in USG require package-level markings to represent “highest-classification”, which means other gov’t may as well.


 


John

 



On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote:

 


This does look like a good approach for message level markings.

Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements”
have been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation
of any categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance”
document augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and
categorizations. I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking.
-Cory
 


From: cti-stix@lists.oasis-open.org
[ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Barnum, Sean D.
Sent: Monday, December 07, 2015 9:49 AM
To: Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings


 


I fully support this option as would be expected.


Kudos to John for such a great writeup explaining the idea.


 


sean



 


From:
" cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of John Wunder
< jwunder@mitre.org >
Date: Thursday, December 3, 2015 at 3:11 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Applying data markings


 



All,


 


I developed this proposal to handle the application of data markings in STIX 2.0:  https://github.com/johnwunder/data-markings .
Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.


 


I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings
for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).


 


John







 

It seems like markings, at least L1 markings, could be treated as labels on data.  So you send me a STIX package with a L1 marking at the package level.  Inside there are 3 indicators.  I consume the indicators, apply a label to each one with the L1 marking.  I then throw away the package.   If I in turn send two those indicators back out, and I use an object level L1 marking to convey what was in the package level before, how is this not the same.    It seems like it is 6 of one and half a dozen of another.   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Dec 7, 2015, at 14:39, Taylor, Marlon < Marlon.Taylor@hq.dhs.gov > wrote: Since the object defaults to the marking, if any, on the Package level, then the Package level marking goes to the document.   Default marking could be a messy matter either way. What if 60% of the Package is one way and 50% is another and both MUST do conveyed in the same Package? Package level marking will remove the work for 50% but the other 50% will have to implement overwriting object-level marking (still L1).   I see your concern with Package vs Object. I think Package level makes it easier for the transfer layer (only mentioned once, if all the same) and adds some work on the processing level.   Revision/ID rules will need to be revisited to take reassigning marking into play, especially if you plan on granting any assurance on handling immutability. BUT THAT’S ANOTHER THREAD!     -Marlon   From:   cti-stix@lists.oasis-open.org   [ mailto:cti-stix@lists.oasis-open.org ]   On Behalf Of   Aharon Chernin Sent:   Monday, December 07, 2015 4:27 PM To:   Wunder, John A.;   cti-stix@lists.oasis-open.org Subject:   Re: [cti-stix] Applying data markings   I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White.    If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning rules or the ID hash.   I am not going to put up a huge fight here, but it just seems so obvious to me.   Aharon   From:   < cti-stix@lists.oasis-open.org > on behalf of Wunder, John A. < jwunder@mitre.org > Date:   Monday, December 7, 2015 at 3:42 PM To:   cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject:   Re: [cti-stix] Applying data markings   All,   I updated the proposal based on the comments from last week:  https://github.com/johnwunder/data-markings .   A few comments (on the comments…):   - Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back.   - Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2).   - Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you).   - That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath.   To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):   1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? ( 2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)? 3. Should we keep markings at the package level or move all markings to the individual top-level objects?   My answers:   1. Not sure to be honest. Leaning towards not MTI. 2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway. 3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which means other gov’t may as well.   John   On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote:   This does look like a good approach for message level markings. Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking. -Cory   From: cti-stix@lists.oasis-open.org   [ mailto:cti-stix@lists.oasis-open.org ]   On Behalf Of   Barnum, Sean D. Sent:   Monday, December 07, 2015 9:49 AM To:   Wunder, John A.;   cti-stix@lists.oasis-open.org Subject:   Re: [cti-stix] Applying data markings   I fully support this option as would be expected. Kudos to John for such a great writeup explaining the idea.   sean   From:   cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org > Date:   Thursday, December 3, 2015 at 3:11 PM To:   cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject:   [cti-stix] Applying data markings   All,   I developed this proposal to handle the application of data markings in STIX 2.0:  https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.   I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).   John Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

?3 Points:


(1)
First off, let me begin by saying I think that John Wunder's Level 1 and Level 2 markings "hit the mark."

(2)

I'd like to foot-stomp a broad need for Level 2 markings.   See use cases below.

(3)  I think we are touching on the
fact that  that sharing (brokering) between diffe rent sharing commu nities
wi l l require processing (including re-marking/translation/config mgmt ) that needs to
be ironed out (in a n oth er topic).   See use cases below.
============================================

T wo use cases that are basically identical:



Use Case 1: Governments useing STIX to communicate classified information amongst each other.  Lets assume that they have a sharing environment that supports Unclassified and Secret sharing.  Let's also assume they want to ensure that the information gets
as broadly disseminated as allowable.  Example: information that is unclassified can be shared broadly.  Let's posit a use case where the observable itself is unclassified but the description of how the analyst arrived at that observable is Secret.   The field
level (Level 2) marking is used for description.  The default (Level 1) marking is Unclassified.   If we had brokering software that was going to broker this to some Unclassified sharing community, then the brokering software would need to remove the Secret
information and Level 2 Secret marking before sharing with the Unclassified sharing community.  The broker bears responsibility for doing this kind of processing and re-marking.


Use Case 2: Basically the same example but applicable to  the private sector.  A company uses STIX to communicate internally and some of the fields, objects, etc are Proprietary.   That Company has brokering software that automatically processes internal
STIX documents, removes proprietary information, and re-marks the information for automated sharing with peers.   




============================================




I suggest we have broad need for Level 2 marking for automated brokering between sharing communities.  I also suggest that packag e level marking is
a convenience that we'd want  to keep, recognizing that certain sharing communities will never need object marking and/or Level 2 marking but would appreciate the simplicity of package marking.   In
many cases,  a  broker will need to process and re-mark between communities   (and
keep track of revisioning - which like Marlon says is another topic.) ?




Pam Smith

JHU/APL





From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Jordan, Bret <bret.jordan@bluecoat.com>
Sent: Monday, December 7, 2015 7:44 PM
To: Taylor, Marlon
Cc: Aharon Chernin; Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings
 

It seems like markings, at least L1 markings, could be treated as "labels" on data.  So you send me a STIX package with a L1 marking at the package level.  Inside there are 3 indicators.  I consume the indicators, apply a label to each one with the L1
marking.  I then throw away the package.  


If I in turn send two those indicators back out, and I use an object level L1 marking to convey what was in the package level before, how is this not the same.   


It seems like it is 6 of one and half a dozen of another.  










Thanks,


Bret











Bret Jordan CISSP

Director of Security Architecture and Standards Office of the CTO

Blue Coat Systems

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 











On Dec 7, 2015, at 14:39, Taylor, Marlon < Marlon.Taylor@hq.dhs.gov > wrote:




Since the object defaults to the marking, if any, on the Package level, then the Package level marking goes to the document.

 

Default marking could be a messy matter either way. What if 60% of the Package is one way and 50% is another and both MUST do conveyed in the same Package? Package level
marking will remove the work for 50% but the other 50% will have to implement overwriting object-level marking (still L1).

 

I see your concern with Package vs Object. I think Package level makes it easier for the transfer layer (only mentioned once, if all the same) and adds some work on
the processing level.

 

Revision/ID rules will need to be revisited to take reassigning marking into play, especially if you plan on granting any assurance on handling immutability. BUT THAT’S
ANOTHER THREAD!  

 

-Marlon

 



From:   cti-stix@lists.oasis-open.org   [ mailto:cti-stix@lists.oasis-open.org ]   On
Behalf Of   Aharon Chernin
Sent:   Monday, December 07, 2015 4:27 PM
To:   Wunder, John A.;   cti-stix@lists.oasis-open.org
Subject:   Re: [cti-stix] Applying data markings



 




I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that
it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. 



 



If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object
without breaking the revisioning rules or the ID hash.



 



I am not going to put up a huge fight here, but it just seems so obvious to me.



 



Aharon





 



From:   < cti-stix@lists.oasis-open.org >
on behalf of "Wunder, John A." < jwunder@mitre.org >
Date:   Monday, December 7, 2015 at 3:42 PM
To:   " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject:   Re: [cti-stix] Applying data markings



 





All,



 



I updated the proposal based on the comments from last week:  https://github.com/johnwunder/data-markings .



 



A few comments (on the comments…):



 



- Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched
it back.



 



- Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not
duplicated across each indicator). OTOH it also means that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself
if you add them to the object, and in any case per Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2).



 



- Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but
fundamentally it’s still a controlled structure based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you).



 



- That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath.



 



To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):



 



1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (



2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?



3. Should we keep markings at the package level or move all markings to the individual top-level objects?



 



My answers:



 



1. Not sure to be honest. Leaning towards not MTI.



2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway.



3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level
markings to represent “highest-classification”, which means other gov’t may as well.



 



John


 




On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote:


 



This does look like a good approach for message level markings.

Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have
been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any
categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document
augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations.
I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking.

-Cory

 



From: cti-stix@lists.oasis-open.org   [ mailto:cti-stix@lists.oasis-open.org ]   On
Behalf Of   Barnum, Sean D.
Sent:   Monday, December 07, 2015 9:49 AM
To:   Wunder, John A.;   cti-stix@lists.oasis-open.org
Subject:   Re: [cti-stix] Applying data markings



 



I fully support this option as would be expected.



Kudos to John for such a great writeup explaining the idea.



 



sean




 



From:   " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date:   Thursday, December 3, 2015 at 3:11 PM
To:   " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject:   [cti-stix] Applying data markings



 




All,


 



I developed this proposal to handle the application of data markings in STIX 2.0:  https://github.com/johnwunder/data-markings .
Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.



 



I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them.
Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).



 



John

Given the absolute criticality of getting the piece right to our use case for CTI, I'm going to risk sending this out in hopes that it helps inform the discussion by providing some real world use cases and examples.  Note that this representation focuses
on "our" use cases and challenges*.  





When you receive and decompose a " Package ",  you need to process, transform, and re-mark each " Container/Object " with any inherited attributes as you iterate through each Sibling/Child relationship.  " Containers " may in turn get passed
on as first level " Packages " to other destinations (e.g. One to the Firewall Team, one to the Mail Gateway Admins, one to your external MSSP)




[Package "X"] 



[ Marking "A"  ==>
Object1  ==]
Object2 ==>

Object2.1  ==]


Object2.2  ==]

[Marking "B ==>   Object2.3 ==]
Object3  ==]
[Marking "C" ==>  Object4 ==]







[First Decomposition]



[Marking "A" ==> Object1==]



[Marking "A" ==>  Object2 ==>

Object2.1  ==]
Object2.2   ==]



[Marking "B" ==>  Object2.3 ==]


[Marking "A" ==>  Object3 ==]


[Marking "C" ==>   Object4 ==]







[Second Decomposition]




[Marking "A" ==> Object1 ==]
[Marking "A" ==> Object2 ==]



[ Marking "A" ==> Object2.1 ==]
[ Marking "A" ==> Object2.2 ==]
[Marking "B" ==>  Object2.3 ==]




[Marking "A" ==> Object3 ==]
[Marking "C" ==>  Object4 ==]












[Re-Packaging, Remarking, and Re-Distribution]



For example within the DIB we might need to send different "pieces" of Package "X" to various places with destination specific ""re-markings":



(1) Incident Summary Report, w/Company/Employee Attributional Data, IOCs, and Malware Samples to DC3/DCISE as required under DFARS.
(2) Incident Summary Report and Malware Samples to US-CERT.
(3) Incident Summary Report, Company/Employee Attributional Data to DSS. 
(4) An RFI or Alert with just the ephemeral actionable IOCs selectively to FS-ISAC, ICS-ISAC, and Aviation ISAC via the NCI.







[Package "X"] ==> Destination X


[Marking "C" ==> 

Object1 ==]


Object2 ==]




Object2.1 ==]

Object2.2 ==]
Object2.3 ==]

Object3 ==]
Object4 ==]







[Package "Y"]   ==> Destination Y


[Marking "A" ==> 
Object1 ==]
[Marking "B" ==> 

Object2 ==]
Object2.2 ==]


[Marking "B" ==>  Object2.3 ==]

[Marking "C" ==>  Object4 ==]





[Package "Z"]   ==> Destination Z


[Marking "A" ==> 
Object1 ==]
[Marking "B" ==> 

Object2 ==]
Object2.2 ==]















Note: The above is a simplification. If we do not come to an absolute agreement that you will not send out something sourced by other entities unless it is marked identifying it as
such, then we need to deal with commingled intelligence from many sources, with differing data markings, etc.










Patrick Maroney
Office:  (856)983-0001
Cell:      (609)841-5104






President
Integrated Networking Technologies, Inc.
PO Box 569
Marlton, NJ 08053







From: < cti-stix@lists.oasis-open.org > on behalf of "Chernin, Aharon" < achernin@soltra.com >
Date: Monday, December 7, 2015 at 4:26 PM
To: John Wunder < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings








I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and
document mark that object as TLP White. 



If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning
rules or the ID hash.




I am not going to put up a huge fight here, but it just seems so obvious to me.




Aharon










From: < cti-stix@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Monday, December 7, 2015 at 3:42 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings





All,


I updated the proposal based on the comments from last week:  https://github.com/johnwunder/data-markings .


A few comments (on the comments…):


- Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back.


- Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that
if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s
earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2).


- Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach
with all the implementation complexity that it brings (as Bryan Worrell can tell you).


- That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath.


To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):


1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (
2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?
3. Should we keep markings at the package level or move all markings to the individual top-level objects?


My answers:


1. Not sure to be honest. Leaning towards not MTI.
2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway.
3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which
means other gov’t may as well.


John



On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote:






This does look like a good approach for message level markings.

Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such
“exchange agreements” have been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit
representation of any categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings
in the “instance” document augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic”
restrictions and categorizations. I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking.
-Cory
 


From: cti-stix@lists.oasis-open.org
[ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Barnum, Sean D.
Sent: Monday, December 07, 2015 9:49 AM
To: Wunder, John A.;
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings


 


I fully support this option as would be expected.


Kudos to John for such a great writeup explaining the idea.


 


sean



 


From:
" cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf
of John Wunder < jwunder@mitre.org >
Date: Thursday, December 3, 2015 at 3:11 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Applying data markings


 



All,


 


I developed this proposal to handle the application of data markings in STIX 2.0:  https://github.com/johnwunder/data-markings .
Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.


 


I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings
for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).


 


John

Comment on a related topic in this thread and on the Slack Channels:



Conformance to CTI Data Marking and Handling standards/conventions is one of the most critical aspects of Interoperability for a significant number of organizations.  Any attempts to try to remove this from Conformance,  Specification, and Interoperability
requirements are ill advised from the perspective of the organizations I represent.







From: < cti-stix@lists.oasis-open.org > on behalf of Patrick Maroney < Pmaroney@Specere.org >
Date: Monday, December 7, 2015 at 5:12 PM
To: "Chernin, Aharon" < achernin@soltra.com >, John Wunder < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings







Given the absolute criticality of getting the piece right to our use case for CTI, I'm going to risk sending this out in hopes that it helps inform the discussion by providing some real world use cases and examples.  Note that this representation focuses
on "our" use cases and challenges*.  





When you receive and decompose a " Package ",  you need to process, transform, and re-mark each " Container/Object " with any inherited attributes as you iterate through each Sibling/Child relationship.  " Containers " may in turn get passed
on as first level " Packages " to other destinations (e.g. One to the Firewall Team, one to the Mail Gateway Admins, one to your external MSSP)




[Package "X"] 



[ Marking "A"  ==>
Object1  ==]
Object2 ==>

Object2.1  ==]


Object2.2  ==]

[Marking "B ==>   Object2.3 ==]
Object3  ==]
[Marking "C" ==>  Object4 ==]







[First Decomposition]



[Marking "A" ==> Object1==]



[Marking "A" ==>  Object2 ==>

Object2.1  ==]
Object2.2   ==]



[Marking "B" ==>  Object2.3 ==]


[Marking "A" ==>  Object3 ==]


[Marking "C" ==>   Object4 ==]







[Second Decomposition]




[Marking "A" ==> Object1 ==]
[Marking "A" ==> Object2 ==]



[ Marking "A" ==> Object2.1 ==]
[ Marking "A" ==> Object2.2 ==]
[Marking "B" ==>  Object2.3 ==]




[Marking "A" ==> Object3 ==]
[Marking "C" ==>  Object4 ==]












[Re-Packaging, Remarking, and Re-Distribution]



For example within the DIB we might need to send different "pieces" of Package "X" to various places with destination specific ""re-markings":



(1) Incident Summary Report, w/Company/Employee Attributional Data, IOCs, and Malware Samples to DC3/DCISE as required under DFARS.
(2) Incident Summary Report and Malware Samples to US-CERT.
(3) Incident Summary Report, Company/Employee Attributional Data to DSS. 
(4) An RFI or Alert with just the ephemeral actionable IOCs selectively to FS-ISAC, ICS-ISAC, and Aviation ISAC via the NCI.







[Package "X"] ==> Destination X


[Marking "C" ==> 

Object1 ==]


Object2 ==]




Object2.1 ==]

Object2.2 ==]
Object2.3 ==]

Object3 ==]
Object4 ==]







[Package "Y"]   ==> Destination Y


[Marking "A" ==> 
Object1 ==]
[Marking "B" ==> 

Object2 ==]
Object2.2 ==]


[Marking "B" ==>  Object2.3 ==]

[Marking "C" ==>  Object4 ==]





[Package "Z"]   ==> Destination Z


[Marking "A" ==> 
Object1 ==]
[Marking "B" ==> 

Object2 ==]
Object2.2 ==]















Note: The above is a simplification. If we do not come to an absolute agreement that you will not send out something sourced by other entities unless it is marked identifying it as
such, then we need to deal with commingled intelligence from many sources, with differing data markings, etc.










Patrick Maroney
Office:  (856)983-0001
Cell:      (609)841-5104






President
Integrated Networking Technologies, Inc.
PO Box 569
Marlton, NJ 08053







From: < cti-stix@lists.oasis-open.org > on behalf of "Chernin, Aharon" < achernin@soltra.com >
Date: Monday, December 7, 2015 at 4:26 PM
To: John Wunder < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings








I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and
document mark that object as TLP White. 



If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning
rules or the ID hash.




I am not going to put up a huge fight here, but it just seems so obvious to me.




Aharon










From: < cti-stix@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Monday, December 7, 2015 at 3:42 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings





All,


I updated the proposal based on the comments from last week:  https://github.com/johnwunder/data-markings .


A few comments (on the comments…):


- Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back.


- Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that
if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s
earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2).


- Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach
with all the implementation complexity that it brings (as Bryan Worrell can tell you).


- That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath.


To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):


1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (
2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?
3. Should we keep markings at the package level or move all markings to the individual top-level objects?


My answers:


1. Not sure to be honest. Leaning towards not MTI.
2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway.
3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which
means other gov’t may as well.


John



On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote:






This does look like a good approach for message level markings.

Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such
“exchange agreements” have been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit
representation of any categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings
in the “instance” document augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic”
restrictions and categorizations. I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking.
-Cory
 


From: cti-stix@lists.oasis-open.org
[ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Barnum, Sean D.
Sent: Monday, December 07, 2015 9:49 AM
To: Wunder, John A.;
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings


 


I fully support this option as would be expected.


Kudos to John for such a great writeup explaining the idea.


 


sean



 


From:
" cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf
of John Wunder < jwunder@mitre.org >
Date: Thursday, December 3, 2015 at 3:11 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Applying data markings


 



All,


 


I developed this proposal to handle the application of data markings in STIX 2.0:  https://github.com/johnwunder/data-markings .
Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.


 


I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings
for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).


 


John

" If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings. Is that something that was decided? - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Aharon Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo From: Aharon Chernin <achernin@soltra.com> To: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> Date: 12/07/2015 05:26 PM Subject: Re: [cti-stix] Applying data markings Sent by: <cti-stix@lists.oasis-open.org> I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning rules or the ID hash. I am not going to put up a huge fight here, but it just seems so obvious to me. Aharon From: < cti-stix@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org > Date: Monday, December 7, 2015 at 3:42 PM To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings All, I updated the proposal based on the comments from last week: https://github.com/johnwunder/data-markings . A few comments (on the comments…): - Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back. - Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2). - Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you). - That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath. To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”): 1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? ( 2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)? 3. Should we keep markings at the package level or move all markings to the individual top-level objects? My answers: 1. Not sure to be honest. Leaning towards not MTI. 2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway. 3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which means other gov’t may as well. John
On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote: This does look like a good approach for message level markings. Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking. -Cory From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Barnum, Sean D. Sent: Monday, December 07, 2015 9:49 AM To: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Applying data markings I fully support this option as would be expected. Kudos to John for such a great writeup explaining the idea. sean From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org > Date: Thursday, December 3, 2015 at 3:11 PM To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: [cti-stix] Applying data markings All, I developed this proposal to handle the application of data markings in STIX 2.0: https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content. I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap). John

Jason, I agree. If we as a group decide to do hash based ids, then we can enforce that the object has not been revisioned (without following revision rules) and that the TLP has not been “altered”. 


Hash based Ids have not been worked through as a community at this time. 


Aharon









From: Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Date: Tuesday, December 8, 2015 at 1:44 PM
To: Aharon < achernin@soltra.com >
Cc: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings





" If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White.


This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings.


Is that something that was decided?


-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Aharon
Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo

From: Aharon Chernin < achernin@soltra.com >
To: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Date: 12/07/2015 05:26 PM
Subject: Re: [cti-stix] Applying data markings
Sent by: < cti-stix@lists.oasis-open.org >





I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in
another document and document mark that object as TLP White.

If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning
rules or the ID hash.

I am not going to put up a huge fight here, but it just seems so obvious to me.

Aharon

From: < cti-stix@lists.oasis-open.org >
on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Monday, December 7, 2015 at 3:42 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings

All,

I updated the proposal based on the comments from last week:
https://github.com/johnwunder/data-markings .

A few comments (on the comments…):

- Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back.

- Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means
that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per
Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2).

- Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure
based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you).

- That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath.

To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):

1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (
2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?
3. Should we keep markings at the package level or move all markings to the individual top-level objects?

My answers:

1. Not sure to be honest. Leaning towards not MTI.
2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway.
3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”,
which means other gov’t may as well.

John


On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote:

This does look like a good approach for message level markings.

Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative
Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under
that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not
be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered
for CTI. The exchange agreement reference can be a kind of marking.
-Cory

From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Barnum, Sean D.
Sent: Monday, December 07, 2015 9:49 AM
To: Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings

I fully support this option as would be expected.
Kudos to John for such a great writeup explaining the idea.

sean

From: " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Thursday, December 3, 2015 at 3:11 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Applying data markings

All,

I developed this proposal to handle the application of data markings in STIX 2.0:
https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves (improvements
to TLP, the work in FIRST, etc), just how those markings get applied to content.

I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about
feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).

John

Is this a problem that we can not really solve?  I mean if someone is not going to abide by the data-marking rules and fall out of alignment with the legal framework that is in place between them and who ever they got the data from, then why not just pull the IPs or Hashes or Filenames out and just craft an entirely new object?    Why just change the TLP marking?  Why not just craft an entirely new object? Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Dec 8, 2015, at 12:07, Aharon Chernin < achernin@soltra.com > wrote: Jason, I agree. If we as a group decide to do hash based ids, then we can enforce that the object has not been revisioned (without following revision rules) and that the TLP has not been “altered”.  Hash based Ids have not been worked through as a community at this time.  Aharon From: Jason Keirstead < Jason.Keirstead@ca.ibm.com > Date: Tuesday, December 8, 2015 at 1:44 PM To: Aharon < achernin@soltra.com > Cc: Wunder, John A. < jwunder@mitre.org >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings. Is that something that was decided? - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown <graycol.gif> Aharon Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo From: Aharon Chernin < achernin@soltra.com > To: Wunder, John A. < jwunder@mitre.org >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Date: 12/07/2015 05:26 PM Subject: Re: [cti-stix] Applying data markings Sent by: < cti-stix@lists.oasis-open.org > I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning rules or the ID hash. I am not going to put up a huge fight here, but it just seems so obvious to me. Aharon From: < cti-stix@lists.oasis-open.org > on behalf of Wunder, John A. < jwunder@mitre.org > Date: Monday, December 7, 2015 at 3:42 PM To: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings All, I updated the proposal based on the comments from last week: https://github.com/johnwunder/data-markings . A few comments (on the comments…): - Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back. - Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2). - Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you). - That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath. To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”): 1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? ( 2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)? 3. Should we keep markings at the package level or move all markings to the individual top-level objects? My answers: 1. Not sure to be honest. Leaning towards not MTI. 2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway. 3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which means other gov’t may as well. John On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote: This does look like a good approach for message level markings. Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking. -Cory From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Barnum, Sean D. Sent: Monday, December 07, 2015 9:49 AM To: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Applying data markings I fully support this option as would be expected. Kudos to John for such a great writeup explaining the idea. sean From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org > Date: Thursday, December 3, 2015 at 3:11 PM To: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: [cti-stix] Applying data markings All, I developed this proposal to handle the application of data markings in STIX 2.0: https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content. I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap). John <graycol.gif> --------------------------------------------------------------------- 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 Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

I do run into STIX objects that have been modified, but the GUIDS and/or timestamps remained the same. To Aharon, this is less about TLP enforcement and more about forcing people to use STIX correctly. To “other people”, it could be about ensuring the
the TLP remains the same. I don’t think that authors purposely do things wrong, but authors (or the tools they create), can do things incorrectly.  All in all, I love forcing authors to do the right thing. It reduces “optionality”.


Aharon









From: "Jordan, Bret" < bret.jordan@bluecoat.com >
Date: Tuesday, December 8, 2015 at 5:09 PM
To: Aharon < achernin@soltra.com >
Cc: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings





Is this a problem that we can not really solve?  I mean if someone is not going to abide by the data-marking rules and fall out of alignment with the legal framework that is in place between them and who ever they got the data from, then why not just pull the
IPs or Hashes or Filenames out and just craft an entirely new object?    Why just change the TLP marking?  Why not just craft an entirely new object?











Thanks,


Bret











Bret Jordan CISSP

Director of Security Architecture and Standards Office of the CTO

Blue Coat Systems

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 











On Dec 8, 2015, at 12:07, Aharon Chernin < achernin@soltra.com > wrote:





Jason, I agree. If we as a group decide to do hash based ids, then we can enforce that the object has not been revisioned (without following revision rules) and that the TLP has not been “altered”. 


Hash based Ids have not been worked through as a community at this time. 


Aharon









From: Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Date: Tuesday, December 8, 2015 at 1:44 PM
To: Aharon < achernin@soltra.com >
Cc: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings





" If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White.


This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings.


Is that something that was decided?


-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security
www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


<graycol.gif> Aharon Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo

From: Aharon Chernin < achernin@soltra.com >
To: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Date: 12/07/2015 05:26 PM
Subject: Re: [cti-stix] Applying data markings
Sent by: < cti-stix@lists.oasis-open.org >





I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object
and use it in another document and document mark that object as TLP White.


If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking
the revisioning rules or the ID hash.

I am not going to put up a huge fight here, but it just seems so obvious to me.

Aharon

From: < cti-stix@lists.oasis-open.org >
on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Monday, December 7, 2015 at 3:42 PM
To: " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings

All,

I updated the proposal based on the comments from last week:
https://github.com/johnwunder/data-markings .

A few comments (on the comments…):

- Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back.

- Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it
also means that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any
case per Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2).

- Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure
based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you).

- That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath.

To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):

1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (
2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?
3. Should we keep markings at the package level or move all markings to the individual top-level objects?

My answers:

1. Not sure to be honest. Leaning towards not MTI.
2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway.
3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”,
which means other gov’t may as well.

John


On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com >
wrote:

This does look like a good approach for message level markings.

Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative
Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under
that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not
be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered
for CTI. The exchange agreement reference can be a kind of marking.
-Cory

From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Barnum, Sean D.
Sent: Monday, December 07, 2015 9:49 AM
To: Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings

I fully support this option as would be expected.
Kudos to John for such a great writeup explaining the idea.

sean

From: " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Thursday, December 3, 2015 at 3:11 PM
To: " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Applying data markings

All,

I developed this proposal to handle the application of data markings in STIX 2.0:
https://github.com/johnwunder/data-markings . Note: it doesn't address the format of
the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.

I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s
talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).

John








<graycol.gif>
---------------------------------------------------------------------
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

I agree... I like it when optionality is reduced and there is one simple and easy way of doing things.  This will prevent bad behavior, or at least make the bad behavior more apparent..  This is also why I am advocate of creating some unit-tests that we can use to verify implementations.   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Dec 8, 2015, at 15:23, Aharon Chernin < achernin@soltra.com > wrote: I do run into STIX objects that have been modified, but the GUIDS and/or timestamps remained the same. To Aharon, this is less about TLP enforcement and more about forcing people to use STIX correctly. To “other people”, it could be about ensuring the the TLP remains the same. I don’t think that authors purposely do things wrong, but authors (or the tools they create), can do things incorrectly.  All in all, I love forcing authors to do the right thing. It reduces “optionality”. Aharon From: Jordan, Bret < bret.jordan@bluecoat.com > Date: Tuesday, December 8, 2015 at 5:09 PM To: Aharon < achernin@soltra.com > Cc: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Wunder, John A. < jwunder@mitre.org >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings Is this a problem that we can not really solve?  I mean if someone is not going to abide by the data-marking rules and fall out of alignment with the legal framework that is in place between them and who ever they got the data from, then why not just pull the IPs or Hashes or Filenames out and just craft an entirely new object?    Why just change the TLP marking?  Why not just craft an entirely new object? Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Dec 8, 2015, at 12:07, Aharon Chernin < achernin@soltra.com > wrote: Jason, I agree. If we as a group decide to do hash based ids, then we can enforce that the object has not been revisioned (without following revision rules) and that the TLP has not been “altered”.  Hash based Ids have not been worked through as a community at this time.  Aharon From: Jason Keirstead < Jason.Keirstead@ca.ibm.com > Date: Tuesday, December 8, 2015 at 1:44 PM To: Aharon < achernin@soltra.com > Cc: Wunder, John A. < jwunder@mitre.org >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings. Is that something that was decided? - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown <graycol.gif> Aharon Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo From: Aharon Chernin < achernin@soltra.com > To: Wunder, John A. < jwunder@mitre.org >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Date: 12/07/2015 05:26 PM Subject: Re: [cti-stix] Applying data markings Sent by: < cti-stix@lists.oasis-open.org > I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning rules or the ID hash. I am not going to put up a huge fight here, but it just seems so obvious to me. Aharon From: < cti-stix@lists.oasis-open.org > on behalf of Wunder, John A. < jwunder@mitre.org > Date: Monday, December 7, 2015 at 3:42 PM To: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings All, I updated the proposal based on the comments from last week: https://github.com/johnwunder/data-markings . A few comments (on the comments…): - Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back. - Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2). - Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you). - That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath. To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”): 1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? ( 2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)? 3. Should we keep markings at the package level or move all markings to the individual top-level objects? My answers: 1. Not sure to be honest. Leaning towards not MTI. 2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway. 3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which means other gov’t may as well. John On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote: This does look like a good approach for message level markings. Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking. -Cory From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Barnum, Sean D. Sent: Monday, December 07, 2015 9:49 AM To: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Applying data markings I fully support this option as would be expected. Kudos to John for such a great writeup explaining the idea. sean From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org > Date: Thursday, December 3, 2015 at 3:11 PM To: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: [cti-stix] Applying data markings All, I developed this proposal to handle the application of data markings in STIX 2.0: https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content. I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap). John <graycol.gif> --------------------------------------------------------------------- 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 Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

To me these markings are somewhere between really useful and anti-gravity packaging. The really useful part is lots of people are asking me for finer-grained markings than TLP on an entire transmission. The anti-gravity packaging is saying “a server MUST reject a message that has markings that the server will not honor” will actually happen. Last time I looked, no one was volunteering to be the protocol police and arrest that server that choses to ignore the markings and do whatever it wants with them. From a protocol perspective, data markings are advisory only. The community can enforce, through testing and certification, that a particular instance of a server does the right thing. Moreover, the community enforces the participant configures their server properly through, well, legal means, i.e., contracts, community monitoring, false info looking for leaks, etc. On Dec 8, 2015, at 6:36 PM, Jordan, Bret < bret.jordan@BLUECOAT.COM > wrote: I agree... I like it when optionality is reduced and there is one simple and easy way of doing things.  This will prevent bad behavior, or at least make the bad behavior more apparent..  This is also why I am advocate of creating some unit-tests that we can use to verify implementations.   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Dec 8, 2015, at 15:23, Aharon Chernin < achernin@soltra.com > wrote: I do run into STIX objects that have been modified, but the GUIDS and/or timestamps remained the same. To Aharon, this is less about TLP enforcement and more about forcing people to use STIX correctly. To “other people”, it could be about ensuring the the TLP remains the same. I don’t think that authors purposely do things wrong, but authors (or the tools they create), can do things incorrectly.  All in all, I love forcing authors to do the right thing. It reduces “optionality”. Aharon From: Jordan, Bret < bret.jordan@bluecoat.com > Date: Tuesday, December 8, 2015 at 5:09 PM To: Aharon < achernin@soltra.com > Cc: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Wunder, John A. < jwunder@mitre.org >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings Is this a problem that we can not really solve?  I mean if someone is not going to abide by the data-marking rules and fall out of alignment with the legal framework that is in place between them and who ever they got the data from, then why not just pull the IPs or Hashes or Filenames out and just craft an entirely new object?    Why just change the TLP marking?  Why not just craft an entirely new object? Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Dec 8, 2015, at 12:07, Aharon Chernin < achernin@soltra.com > wrote: Jason, I agree. If we as a group decide to do hash based ids, then we can enforce that the object has not been revisioned (without following revision rules) and that the TLP has not been “altered”.  Hash based Ids have not been worked through as a community at this time.  Aharon From: Jason Keirstead < Jason.Keirstead@ca.ibm.com > Date: Tuesday, December 8, 2015 at 1:44 PM To: Aharon < achernin@soltra.com > Cc: Wunder, John A. < jwunder@mitre.org >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings. Is that something that was decided? - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown <graycol.gif> Aharon Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo From: Aharon Chernin < achernin@soltra.com > To: Wunder, John A. < jwunder@mitre.org >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Date: 12/07/2015 05:26 PM Subject: Re: [cti-stix] Applying data markings Sent by: < cti-stix@lists.oasis-open.org > I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning rules or the ID hash. I am not going to put up a huge fight here, but it just seems so obvious to me. Aharon From: < cti-stix@lists.oasis-open.org > on behalf of Wunder, John A. < jwunder@mitre.org > Date: Monday, December 7, 2015 at 3:42 PM To: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings All, I updated the proposal based on the comments from last week: https://github.com/johnwunder/data-markings . A few comments (on the comments…): - Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back. - Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2). - Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you). - That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath. To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”): 1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? ( 2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)? 3. Should we keep markings at the package level or move all markings to the individual top-level objects? My answers: 1. Not sure to be honest. Leaning towards not MTI. 2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway. 3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which means other gov’t may as well. John On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote: This does look like a good approach for message level markings. Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking. -Cory From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Barnum, Sean D. Sent: Monday, December 07, 2015 9:49 AM To: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Applying data markings I fully support this option as would be expected. Kudos to John for such a great writeup explaining the idea. sean From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org > Date: Thursday, December 3, 2015 at 3:11 PM To: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: [cti-stix] Applying data markings All, I developed this proposal to handle the application of data markings in STIX 2.0: https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content. I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap). John <graycol.gif> --------------------------------------------------------------------- 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 Attachment: smime.p7s Description: S/MIME cryptographic signature

+1...  The only real way is through out-of-bands legal agreements.  Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Dec 8, 2015, at 18:56, Eric Burger < Eric.Burger@georgetown.edu > wrote: To me these markings are somewhere between really useful and anti-gravity packaging. The really useful part is lots of people are asking me for finer-grained markings than TLP on an entire transmission. The anti-gravity packaging is saying “a server MUST reject a message that has markings that the server will not honor” will actually happen. Last time I looked, no one was volunteering to be the protocol police and arrest that server that choses to ignore the markings and do whatever it wants with them. From a protocol perspective, data markings are advisory only. The community can enforce, through testing and certification, that a particular instance of a server does the right thing. Moreover, the community enforces the participant configures their server properly through, well, legal means, i.e., contracts, community monitoring, false info looking for leaks, etc. On Dec 8, 2015, at 6:36 PM, Jordan, Bret < bret.jordan@BLUECOAT.COM > wrote: I agree... I like it when optionality is reduced and there is one simple and easy way of doing things.  This will prevent bad behavior, or at least make the bad behavior more apparent..  This is also why I am advocate of creating some unit-tests that we can use to verify implementations.   Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Dec 8, 2015, at 15:23, Aharon Chernin < achernin@soltra.com > wrote: I do run into STIX objects that have been modified, but the GUIDS and/or timestamps remained the same. To Aharon, this is less about TLP enforcement and more about forcing people to use STIX correctly. To “other people”, it could be about ensuring the the TLP remains the same. I don’t think that authors purposely do things wrong, but authors (or the tools they create), can do things incorrectly.  All in all, I love forcing authors to do the right thing. It reduces “optionality”. Aharon From: Jordan, Bret < bret.jordan@bluecoat.com > Date: Tuesday, December 8, 2015 at 5:09 PM To: Aharon < achernin@soltra.com > Cc: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Wunder, John A. < jwunder@mitre.org >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings Is this a problem that we can not really solve?  I mean if someone is not going to abide by the data-marking rules and fall out of alignment with the legal framework that is in place between them and who ever they got the data from, then why not just pull the IPs or Hashes or Filenames out and just craft an entirely new object?    Why just change the TLP marking?  Why not just craft an entirely new object? Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Dec 8, 2015, at 12:07, Aharon Chernin < achernin@soltra.com > wrote: Jason, I agree. If we as a group decide to do hash based ids, then we can enforce that the object has not been revisioned (without following revision rules) and that the TLP has not been “altered”.  Hash based Ids have not been worked through as a community at this time.  Aharon From: Jason Keirstead < Jason.Keirstead@ca.ibm.com > Date: Tuesday, December 8, 2015 at 1:44 PM To: Aharon < achernin@soltra.com > Cc: Wunder, John A. < jwunder@mitre.org >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings. Is that something that was decided? - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown <graycol.gif> Aharon Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo From: Aharon Chernin < achernin@soltra.com > To: Wunder, John A. < jwunder@mitre.org >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Date: 12/07/2015 05:26 PM Subject: Re: [cti-stix] Applying data markings Sent by: < cti-stix@lists.oasis-open.org > I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning rules or the ID hash. I am not going to put up a huge fight here, but it just seems so obvious to me. Aharon From: < cti-stix@lists.oasis-open.org > on behalf of Wunder, John A. < jwunder@mitre.org > Date: Monday, December 7, 2015 at 3:42 PM To: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings All, I updated the proposal based on the comments from last week: https://github.com/johnwunder/data-markings . A few comments (on the comments…): - Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back. - Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2). - Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you). - That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath. To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”): 1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? ( 2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)? 3. Should we keep markings at the package level or move all markings to the individual top-level objects? My answers: 1. Not sure to be honest. Leaning towards not MTI. 2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway. 3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which means other gov’t may as well. John On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote: This does look like a good approach for message level markings. Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking. -Cory From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Barnum, Sean D. Sent: Monday, December 07, 2015 9:49 AM To: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Applying data markings I fully support this option as would be expected. Kudos to John for such a great writeup explaining the idea. sean From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org > Date: Thursday, December 3, 2015 at 3:11 PM To: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: [cti-stix] Applying data markings All, I developed this proposal to handle the application of data markings in STIX 2.0: https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content. I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap). John <graycol.gif> --------------------------------------------------------------------- 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 Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

Nope, for any of these approaches we rely on the client software to do the right thing and preserve data markings (as well as honor them in the first place).


For this reason, it seems to me that as long as we define the semantics for how markings are applied at the package level we don’t need to have them exist directly on the object. We can just define that they’re semantically equivalent and allow people
who are retransmitting objects to move them between the package and the object as they want (assuming of course that they preserve those semantics).


In other words, to me this would be a valid retransmission:


Org A => Org B

Package (TLP:RED)

Object 1 Object 2

Org B => Org C

Package

Object 1 (TLP:RED) Object 2 (TLP:RED)

Yes, Org B is re-writing the object in the sense that they’re moving a marking there. But since semantically the marking was already there when it received it from Org A this seems fine to me. IMO resharers should be free to do things like this so long
as they don’t change the actual content  of what they’re retransmitting.


OTOH if this is not something the community thinks is valid then I would lean more towards what Aharon is suggesting and require that people mark the objects directly, otherwise he’s right that they’ll get “stuck” because you can’t retransmit them outside
the context of the package that they came in.


John








From: Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Date: Tuesday, December 8, 2015 at 1:44 PM
To: Aharon Chernin < achernin@soltra.com >
Cc: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings





" If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White.


This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings.


Is that something that was decided?


-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Aharon
Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo

From: Aharon Chernin < achernin@soltra.com >
To: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Date: 12/07/2015 05:26 PM
Subject: Re: [cti-stix] Applying data markings
Sent by: < cti-stix@lists.oasis-open.org >





I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in
another document and document mark that object as TLP White.

If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning
rules or the ID hash.

I am not going to put up a huge fight here, but it just seems so obvious to me.

Aharon

From: < cti-stix@lists.oasis-open.org >
on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Monday, December 7, 2015 at 3:42 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings

All,

I updated the proposal based on the comments from last week:
https://github.com/johnwunder/data-markings .

A few comments (on the comments…):

- Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back.

- Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means
that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per
Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2).

- Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure
based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you).

- That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath.

To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):

1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (
2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?
3. Should we keep markings at the package level or move all markings to the individual top-level objects?

My answers:

1. Not sure to be honest. Leaning towards not MTI.
2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway.
3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”,
which means other gov’t may as well.

John


On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote:

This does look like a good approach for message level markings.

Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative
Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under
that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not
be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered
for CTI. The exchange agreement reference can be a kind of marking.
-Cory

From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Barnum, Sean D.
Sent: Monday, December 07, 2015 9:49 AM
To: Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings

I fully support this option as would be expected.
Kudos to John for such a great writeup explaining the idea.

sean

From: " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Thursday, December 3, 2015 at 3:11 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Applying data markings

All,

I developed this proposal to handle the application of data markings in STIX 2.0:
https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves (improvements
to TLP, the work in FIRST, etc), just how those markings get applied to content.

I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about
feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).

John

idea: do something similar to a PDF digital signature and fillable form fields (which are not counted in document integrity hash calculations) - i.e. put the markings outside the content when you hash. From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Wunder, John A. <jwunder@mitre.org> Sent: Tuesday, December 8, 2015 2:15 PM To: Jason Keirstead; Aharon Chernin Cc: cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Applying data markings   Nope, for any of these approaches we rely on the client software to do the right thing and preserve data markings (as well as honor them in the first place). For this reason, it seems to me that as long as we define the semantics for how markings are applied at the package level we don’t need to have them exist directly on the object. We can just define that they’re semantically equivalent and allow people who are retransmitting objects to move them between the package and the object as they want (assuming of course that they preserve those semantics). In other words, to me this would be a valid retransmission: Org A => Org B Package (TLP:RED) Object 1 Object 2 Org B => Org C Package Object 1 (TLP:RED) Object 2 (TLP:RED) Yes, Org B is re-writing the object in the sense that they’re moving a marking there. But since semantically the marking was already there when it received it from Org A this seems fine to me. IMO resharers should be free to do things like this so long as they don’t change the actual content  of what they’re retransmitting. OTOH if this is not something the community thinks is valid then I would lean more towards what Aharon is suggesting and require that people mark the objects directly, otherwise he’s right that they’ll get “stuck” because you can’t retransmit them outside the context of the package that they came in. John From: Jason Keirstead < Jason.Keirstead@ca.ibm.com > Date: Tuesday, December 8, 2015 at 1:44 PM To: Aharon Chernin < achernin@soltra.com > Cc: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings " If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings. Is that something that was decided? - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Aharon Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo From: Aharon Chernin < achernin@soltra.com > To: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Date: 12/07/2015 05:26 PM Subject: Re: [cti-stix] Applying data markings Sent by: < cti-stix@lists.oasis-open.org > I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning rules or the ID hash. I am not going to put up a huge fight here, but it just seems so obvious to me. Aharon From: < cti-stix@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org > Date: Monday, December 7, 2015 at 3:42 PM To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings All, I updated the proposal based on the comments from last week: https://github.com/johnwunder/data-markings . A few comments (on the comments…): - Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back. - Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2). - Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you). - That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath. To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”): 1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? ( 2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)? 3. Should we keep markings at the package level or move all markings to the individual top-level objects? My answers: 1. Not sure to be honest. Leaning towards not MTI. 2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway. 3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which means other gov’t may as well. John On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote: This does look like a good approach for message level markings. Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking. -Cory From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Barnum, Sean D. Sent: Monday, December 07, 2015 9:49 AM To: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Applying data markings I fully support this option as would be expected. Kudos to John for such a great writeup explaining the idea. sean From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org > Date: Thursday, December 3, 2015 at 3:11 PM To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: [cti-stix] Applying data markings All, I developed this proposal to handle the application of data markings in STIX 2.0: https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content. I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap). John

Yeah this digital signature approach (I would really prefer not to put it in IDs but as a separate signature, as we do elsewhere) needs to have some kind of canonicalization that only includes some of the information. Whitespace and markup of course needs
to be stripped out, string encodings normalized, etc. but also some information could be out of scope if we’re OK with that.


That said, you would ideally want markings in-scope. So rather than take it out of the object you’d probably want to say that even if markings were applied at the package level they somehow have to be included in the object’s signature. Which of course
is more complicated if you can apply markings at the package level.


I still think I would prefer to keep markings on the package given my philosophy below but there’s clearly a trade-off here (as Marlon pointed out yesterday).


I guess the other question is, is there any semantic meaning to marking a package itself? I.e. can a package be TLP:GREEN or is it the content in the package that’s TLP:GREEN?


John









From: pam smith < Pam.Smith@jhuapl.edu >
Date: Tuesday, December 8, 2015 at 2:23 PM
To: "Wunder, John A." < jwunder@mitre.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Aharon Chernin < achernin@soltra.com >
Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings





idea: do something similar to a PDF digital signature and fillable form fields (which are not counted in document integrity hash calculations) - i.e. put the markings outside the content when you hash.



From:
cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on behalf of Wunder, John A. < jwunder@mitre.org >
Sent: Tuesday, December 8, 2015 2:15 PM
To: Jason Keirstead; Aharon Chernin
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings
 



Nope, for any of these approaches we rely on the client software to do the right thing and preserve data markings (as well as honor them in the first place).


For this reason, it seems to me that as long as we define the semantics for how markings are applied at the package level we don’t need to have them exist directly on the object. We can just define that they’re semantically equivalent and allow people
who are retransmitting objects to move them between the package and the object as they want (assuming of course that they preserve those semantics).


In other words, to me this would be a valid retransmission:


Org A => Org B

Package (TLP:RED)

Object 1 Object 2

Org B => Org C

Package

Object 1 (TLP:RED) Object 2 (TLP:RED)

Yes, Org B is re-writing the object in the sense that they’re moving a marking there. But since semantically the marking was already there when it received it from Org A this seems fine to me. IMO resharers should be free to do things like this so long
as they don’t change the actual content  of what they’re retransmitting.


OTOH if this is not something the community thinks is valid then I would lean more towards what Aharon is suggesting and require that people mark the objects directly, otherwise he’s right that they’ll get “stuck” because you can’t retransmit them outside
the context of the package that they came in.


John








From: Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Date: Tuesday, December 8, 2015 at 1:44 PM
To: Aharon Chernin < achernin@soltra.com >
Cc: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings





" If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White.


This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings.


Is that something that was decided?


-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Aharon
Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo

From: Aharon Chernin < achernin@soltra.com >
To: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Date: 12/07/2015 05:26 PM
Subject: Re: [cti-stix] Applying data markings
Sent by: < cti-stix@lists.oasis-open.org >





I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in
another document and document mark that object as TLP White.

If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning
rules or the ID hash.

I am not going to put up a huge fight here, but it just seems so obvious to me.

Aharon

From: < cti-stix@lists.oasis-open.org >
on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Monday, December 7, 2015 at 3:42 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings

All,

I updated the proposal based on the comments from last week:
https://github.com/johnwunder/data-markings .

A few comments (on the comments…):

- Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back.

- Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means
that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per
Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2).

- Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure
based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you).

- That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath.

To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):

1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (
2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?
3. Should we keep markings at the package level or move all markings to the individual top-level objects?

My answers:

1. Not sure to be honest. Leaning towards not MTI.
2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway.
3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”,
which means other gov’t may as well.

John


On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote:

This does look like a good approach for message level markings.

Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative
Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under
that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not
be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered
for CTI. The exchange agreement reference can be a kind of marking.
-Cory

From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Barnum, Sean D.
Sent: Monday, December 07, 2015 9:49 AM
To: Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings

I fully support this option as would be expected.
Kudos to John for such a great writeup explaining the idea.

sean

From: " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Thursday, December 3, 2015 at 3:11 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Applying data markings

All,

I developed this proposal to handle the application of data markings in STIX 2.0:
https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the
markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.

I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about
feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).

John

Again, I would agree that signatures are likely best handled separate from Ids and that the real challenge with us tackling signatures/hashes of content in STIX/CybOX is determining and conveying on what data the signature/hash was computed.


>I guess the other question is, is there any semantic meaning to marking a package itself? I.e. can a package be TLP:GREEN or is it the content in the package that’s TLP:GREEN?


Since we changed Package in v1.2 to be just an envelope without context I do not see any value in marking a Package itself rather than its content. It is simply an aggregation and enclosure of the content inside it. 


sean








From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Tuesday, December 8, 2015 at 2:30 PM
To: Pam Smith < Pam.Smith@jhuapl.edu >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Aharon Chernin < achernin@soltra.com >
Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings







Yeah this digital signature approach (I would really prefer not to put it in IDs but as a separate signature, as we do elsewhere) needs to have some kind of canonicalization that only includes some of the information. Whitespace and markup of course needs
to be stripped out, string encodings normalized, etc. but also some information could be out of scope if we’re OK with that.


That said, you would ideally want markings in-scope. So rather than take it out of the object you’d probably want to say that even if markings were applied at the package level they somehow have to be included in the object’s signature. Which of course
is more complicated if you can apply markings at the package level.


I still think I would prefer to keep markings on the package given my philosophy below but there’s clearly a trade-off here (as Marlon pointed out yesterday).


I guess the other question is, is there any semantic meaning to marking a package itself? I.e. can a package be TLP:GREEN or is it the content in the package that’s TLP:GREEN?


John









From: pam smith < Pam.Smith@jhuapl.edu >
Date: Tuesday, December 8, 2015 at 2:23 PM
To: "Wunder, John A." < jwunder@mitre.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Aharon Chernin < achernin@soltra.com >
Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings





idea: do something similar to a PDF digital signature and fillable form fields (which are not counted in document integrity hash calculations) - i.e. put the markings outside the content when you hash.



From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org >
on behalf of Wunder, John A. < jwunder@mitre.org >
Sent: Tuesday, December 8, 2015 2:15 PM
To: Jason Keirstead; Aharon Chernin
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings
 



Nope, for any of these approaches we rely on the client software to do the right thing and preserve data markings (as well as honor them in the first place).


For this reason, it seems to me that as long as we define the semantics for how markings are applied at the package level we don’t need to have them exist directly on the object. We can just define that they’re semantically equivalent and allow people
who are retransmitting objects to move them between the package and the object as they want (assuming of course that they preserve those semantics).


In other words, to me this would be a valid retransmission:


Org A => Org B

Package (TLP:RED)

Object 1 Object 2

Org B => Org C

Package

Object 1 (TLP:RED) Object 2 (TLP:RED)

Yes, Org B is re-writing the object in the sense that they’re moving a marking there. But since semantically the marking was already there when it received it from Org A this seems fine to me. IMO resharers should be free to do things like this so long
as they don’t change the actual content  of what they’re retransmitting.


OTOH if this is not something the community thinks is valid then I would lean more towards what Aharon is suggesting and require that people mark the objects directly, otherwise he’s right that they’ll get “stuck” because you can’t retransmit them outside
the context of the package that they came in.


John








From: Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Date: Tuesday, December 8, 2015 at 1:44 PM
To: Aharon Chernin < achernin@soltra.com >
Cc: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings





" If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White.


This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings.


Is that something that was decided?


-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Aharon
Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo

From: Aharon Chernin < achernin@soltra.com >
To: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Date: 12/07/2015 05:26 PM
Subject: Re: [cti-stix] Applying data markings
Sent by: < cti-stix@lists.oasis-open.org >





I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in
another document and document mark that object as TLP White.

If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning
rules or the ID hash.

I am not going to put up a huge fight here, but it just seems so obvious to me.

Aharon

From: < cti-stix@lists.oasis-open.org >
on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Monday, December 7, 2015 at 3:42 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings

All,

I updated the proposal based on the comments from last week:
https://github.com/johnwunder/data-markings .

A few comments (on the comments…):

- Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back.

- Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means
that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per
Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2).

- Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure
based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you).

- That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath.

To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):

1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (
2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?
3. Should we keep markings at the package level or move all markings to the individual top-level objects?

My answers:

1. Not sure to be honest. Leaning towards not MTI.
2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway.
3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”,
which means other gov’t may as well.

John


On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote:

This does look like a good approach for message level markings.

Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative
Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under
that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not
be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered
for CTI. The exchange agreement reference can be a kind of marking.
-Cory

From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Barnum, Sean D.
Sent: Monday, December 07, 2015 9:49 AM
To: Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings

I fully support this option as would be expected.
Kudos to John for such a great writeup explaining the idea.

sean

From: " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Thursday, December 3, 2015 at 3:11 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Applying data markings

All,

I developed this proposal to handle the application of data markings in STIX 2.0:
https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the
markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.

I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about
feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).

John

If we go this route, I would want to hash the objects, not the package.  Thanks, Bret Bret Jordan CISSP Director of Security Architecture and Standards Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg.   On Dec 8, 2015, at 12:23, Smith, Pamela A. < Pam.Smith@jhuapl.edu > wrote: idea: do something similar to a PDF digital signature and fillable form fields (which are not counted in document integrity hash calculations) - i.e. put the markings outside the content when you hash. From:   cti-stix@lists.oasis-open.org   < cti-stix@lists.oasis-open.org > on behalf of Wunder, John A. < jwunder@mitre.org > Sent:   Tuesday, December 8, 2015 2:15 PM To:   Jason Keirstead; Aharon Chernin Cc:   cti-stix@lists.oasis-open.org Subject:   Re: [cti-stix] Applying data markings   Nope, for any of these approaches we rely on the client software to do the right thing and preserve data markings (as well as honor them in the first place). For this reason, it seems to me that as long as we define the semantics for how markings are applied at the package level we don’t need to have them exist directly on the object. We can just define that they’re semantically equivalent and allow people who are retransmitting objects to move them between the package and the object as they want (assuming of course that they preserve those semantics). In other words, to me this would be a valid retransmission: Org A => Org B Package (TLP:RED) Object 1 Object 2 Org B => Org C Package Object 1 (TLP:RED) Object 2 (TLP:RED) Yes, Org B is re-writing the object in the sense that they’re moving a marking there. But since semantically the marking was already there when it received it from Org A this seems fine to me. IMO resharers should be free to do things like this so long as they don’t change the actual   content  of what they’re retransmitting. OTOH if this is not something the community thinks is valid then I would lean more towards what Aharon is suggesting and require that people mark the objects directly, otherwise he’s right that they’ll get “stuck” because you can’t retransmit them outside the context of the package that they came in. John From:   Jason Keirstead < Jason.Keirstead@ca.ibm.com > Date:   Tuesday, December 8, 2015 at 1:44 PM To:   Aharon Chernin < achernin@soltra.com > Cc:   Wunder, John A. < jwunder@mitre.org >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject:   Re: [cti-stix] Applying data markings   If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White.   This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings.   Is that something that was decided? - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security     www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown   <graycol.gif> Aharon Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo From:   Aharon Chernin < achernin@soltra.com > To:   Wunder, John A. < jwunder@mitre.org >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Date:   12/07/2015 05:26 PM Subject:   Re: [cti-stix] Applying data markings Sent by:   < cti-stix@lists.oasis-open.org > I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White.   If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning rules or the ID hash. I am not going to put up a huge fight here, but it just seems so obvious to me. Aharon From:   < cti-stix@lists.oasis-open.org > on behalf of Wunder, John A. < jwunder@mitre.org > Date:   Monday, December 7, 2015 at 3:42 PM To:   cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject:   Re: [cti-stix] Applying data markings All, I updated the proposal based on the comments from last week:   https://github.com/johnwunder/data-markings . A few comments (on the comments…): - Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back. - Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2). - Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you). - That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath. To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”): 1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? ( 2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)? 3. Should we keep markings at the package level or move all markings to the individual top-level objects? My answers: 1. Not sure to be honest. Leaning towards not MTI. 2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway. 3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which means other gov’t may as well. John On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote: This does look like a good approach for message level markings.   Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking. -Cory From: cti-stix@lists.oasis-open.org   [ mailto:cti-stix@lists.oasis-open.org ]   On Behalf Of   Barnum, Sean D. Sent:   Monday, December 07, 2015 9:49 AM To:   Wunder, John A.;   cti-stix@lists.oasis-open.org Subject:   Re: [cti-stix] Applying data markings I fully support this option as would be expected. Kudos to John for such a great writeup explaining the idea. sean From:   cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org > Date:   Thursday, December 3, 2015 at 3:11 PM To:   cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject:   [cti-stix] Applying data markings All,   I developed this proposal to handle the application of data markings in STIX 2.0:   https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content. I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap). John Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

I agree with John’s characterization here.


sean









From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Tuesday, December 8, 2015 at 2:15 PM
To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Aharon Chernin < achernin@soltra.com >
Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings






Nope, for any of these approaches we rely on the client software to do the right thing and preserve data markings (as well as honor them in the first place).


For this reason, it seems to me that as long as we define the semantics for how markings are applied at the package level we don’t need to have them exist directly on the object. We can just define that they’re semantically equivalent and allow people
who are retransmitting objects to move them between the package and the object as they want (assuming of course that they preserve those semantics).


In other words, to me this would be a valid retransmission:


Org A => Org B

Package (TLP:RED)

Object 1 Object 2

Org B => Org C

Package

Object 1 (TLP:RED) Object 2 (TLP:RED)

Yes, Org B is re-writing the object in the sense that they’re moving a marking there. But since semantically the marking was already there when it received it from Org A this seems fine to me. IMO resharers should be free to do things like this so long
as they don’t change the actual content  of what they’re retransmitting.


OTOH if this is not something the community thinks is valid then I would lean more towards what Aharon is suggesting and require that people mark the objects directly, otherwise he’s right that they’ll get “stuck” because you can’t retransmit them outside
the context of the package that they came in.


John








From: Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Date: Tuesday, December 8, 2015 at 1:44 PM
To: Aharon Chernin < achernin@soltra.com >
Cc: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings





" If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White.


This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings.


Is that something that was decided?


-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Aharon
Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo

From: Aharon Chernin < achernin@soltra.com >
To: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Date: 12/07/2015 05:26 PM
Subject: Re: [cti-stix] Applying data markings
Sent by: < cti-stix@lists.oasis-open.org >





I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in
another document and document mark that object as TLP White.

If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning
rules or the ID hash.

I am not going to put up a huge fight here, but it just seems so obvious to me.

Aharon

From: < cti-stix@lists.oasis-open.org >
on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Monday, December 7, 2015 at 3:42 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings

All,

I updated the proposal based on the comments from last week:
https://github.com/johnwunder/data-markings .

A few comments (on the comments…):

- Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back.

- Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means
that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per
Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2).

- Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure
based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you).

- That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath.

To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):

1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (
2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?
3. Should we keep markings at the package level or move all markings to the individual top-level objects?

My answers:

1. Not sure to be honest. Leaning towards not MTI.
2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway.
3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”,
which means other gov’t may as well.

John


On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote:

This does look like a good approach for message level markings.

Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative
Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under
that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not
be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered
for CTI. The exchange agreement reference can be a kind of marking.
-Cory

From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Barnum, Sean D.
Sent: Monday, December 07, 2015 9:49 AM
To: Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings

I fully support this option as would be expected.
Kudos to John for such a great writeup explaining the idea.

sean

From: " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Thursday, December 3, 2015 at 3:11 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Applying data markings

All,

I developed this proposal to handle the application of data markings in STIX 2.0:
https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves (improvements
to TLP, the work in FIRST, etc), just how those markings get applied to content.

I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about
feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).

John

Moving to go deeper on L2 markings I would like more information on the restriction/enforcement of the scope of the specific field path. Background and Questions: The L2 path is supposed to be limited to the "current" object however path syntax allow you reference other (eg parent, sibling, non-self) objects.  Even given a regex to require the first characters reference the "current" object a) how do we ensure the full path doesn't go outside of the current object? b) if the full path goes outside of the current object, and what is the expected behavior? Let's continue to narrow this discussion to conclusion. -Marlon   From: cti-stix@lists.oasis-open.org on behalf of Barnum, Sean D. Sent: Tuesday, December 08, 2015 2:33:39 PM To: Wunder, John A.; Jason Keirstead; Aharon Chernin Cc: cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Applying data markings I agree with John’s characterization here. sean From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org > Date: Tuesday, December 8, 2015 at 2:15 PM To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Aharon Chernin < achernin@soltra.com > Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings Nope, for any of these approaches we rely on the client software to do the right thing and preserve data markings (as well as honor them in the first place). For this reason, it seems to me that as long as we define the semantics for how markings are applied at the package level we don’t need to have them exist directly on the object. We can just define that they’re semantically equivalent and allow people who are retransmitting objects to move them between the package and the object as they want (assuming of course that they preserve those semantics). In other words, to me this would be a valid retransmission: Org A => Org B Package (TLP:RED) Object 1 Object 2 Org B => Org C Package Object 1 (TLP:RED) Object 2 (TLP:RED) Yes, Org B is re-writing the object in the sense that they’re moving a marking there. But since semantically the marking was already there when it received it from Org A this seems fine to me. IMO resharers should be free to do things like this so long as they don’t change the actual content  of what they’re retransmitting. OTOH if this is not something the community thinks is valid then I would lean more towards what Aharon is suggesting and require that people mark the objects directly, otherwise he’s right that they’ll get “stuck” because you can’t retransmit them outside the context of the package that they came in. John From: Jason Keirstead < Jason.Keirstead@ca.ibm.com > Date: Tuesday, December 8, 2015 at 1:44 PM To: Aharon Chernin < achernin@soltra.com > Cc: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings " If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings. Is that something that was decided? - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Aharon Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo From: Aharon Chernin < achernin@soltra.com > To: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Date: 12/07/2015 05:26 PM Subject: Re: [cti-stix] Applying data markings Sent by: < cti-stix@lists.oasis-open.org > I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning rules or the ID hash. I am not going to put up a huge fight here, but it just seems so obvious to me. Aharon From: < cti-stix@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org > Date: Monday, December 7, 2015 at 3:42 PM To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings All, I updated the proposal based on the comments from last week: https://github.com/johnwunder/data-markings . A few comments (on the comments…): - Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back. - Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2). - Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you). - That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath. To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”): 1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? ( 2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)? 3. Should we keep markings at the package level or move all markings to the individual top-level objects? My answers: 1. Not sure to be honest. Leaning towards not MTI. 2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway. 3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which means other gov’t may as well. John On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote: This does look like a good approach for message level markings. Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking. -Cory From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Barnum, Sean D. Sent: Monday, December 07, 2015 9:49 AM To: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Applying data markings I fully support this option as would be expected. Kudos to John for such a great writeup explaining the idea. sean From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org > Date: Thursday, December 3, 2015 at 3:11 PM To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: [cti-stix] Applying data markings All, I developed this proposal to handle the application of data markings in STIX 2.0: https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content. I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap). John

That’s a great point that totally slipped my mind.


In STIX 1.2, we said that the “marking scope” was limited to the construct itself. We didn’t say anything about the root of the document for purposes of evaluation (I just checked) so effectively it’s the root of the full package. Thus, as you say, it
was possible to mark things outside the actual scope. I don’t know why we did this…whether we just didn’t think about it or whether it was because it’s (relatively) hard to pull a snippet of XML out of a document and have it live on its own (due to namespace
mappings and things like that “higher” in the document that impact things at “lower” levels). So, in STIX 1.2, it’s up to the implementation to ensure that the things it marks are limited to the correct marking scope.


When defining this approach for STIX 1.2 I took a queue from JSON/JSONPath and considered just “re-rooting” the document. It’s very easy to do this in JSON because things higher in the document don’t impact things lower in the document, you can just pull
that chunk out and it will always be valid JSON. Given that freedom in the (presumed) MTI, for this proposal I defined it differently: the actual evaluation root for the controlled structure is the object itself, and therefore when evaluating it you can/should
just pull the chunk out completely and evaluate against that. That would prevent people from marking things outside the scope without requiring extra work on the implementation side.


If we develop an XML binding, we’ll have to figure out whether we need to override that and go back to the old approach. I would GUESS that this approach will still be better in XML even though you have to deal with namespace prefixes, but I’m not 100%
sure. We could always use one for JSON and a different one for XML though.


That actually brings up another important point: if we assume JSON MTI is one format among several, tools will have to evaluate data markings and then track them in their repositories
separate  from the MTI approach, then be able to build and retransmit those markings in another format. In other words, if I take in JSON MTI I would need to evaluate that on the incoming JSON and store it in my database
somehow. If I want to transmit into protobuf, I can’t just use those JSONPath markings because they’re no longer valid…they have to be redone in whatever we define for Protobuf. Just something to think about regarding the “storing STIX natively” topic.


John





From: Marlon Taylor < Marlon.Taylor@hq.dhs.gov >
Date: Thursday, December 10, 2015 at 9:33 AM
To: Sean Barnum < sbarnum@mitre.org >, "Wunder, John A." < jwunder@mitre.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >,
Aharon Chernin < achernin@soltra.com >
Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Applying data markings






Moving to go deeper on L2 markings I would like more information on the restriction/enforcement of the scope of the specific field path.

Background and Questions: The L2 path is supposed to be limited to the "current" object however path syntax allow you reference other (eg parent, sibling, non-self) objects.  Even given a regex to require the first characters reference the "current" object

a) how do we ensure the full path doesn't go outside of the current object?
b) if the full path goes outside of the current object, and what is the expected behavior?

Let's continue to narrow this discussion to conclusion.

-Marlon


 


From:
cti-stix@lists.oasis-open.org on behalf of Barnum, Sean D.
Sent: Tuesday, December 08, 2015 2:33:39 PM
To: Wunder, John A.; Jason Keirstead; Aharon Chernin
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings





I agree with John’s characterization here.


sean









From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Tuesday, December 8, 2015 at 2:15 PM
To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Aharon Chernin < achernin@soltra.com >
Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings






Nope, for any of these approaches we rely on the client software to do the right thing and preserve data markings (as well as honor them in the first place).


For this reason, it seems to me that as long as we define the semantics for how markings are applied at the package level we don’t need to have them exist directly on the object. We can just define that they’re semantically equivalent and allow people
who are retransmitting objects to move them between the package and the object as they want (assuming of course that they preserve those semantics).


In other words, to me this would be a valid retransmission:


Org A => Org B

Package (TLP:RED)

Object 1 Object 2

Org B => Org C

Package

Object 1 (TLP:RED) Object 2 (TLP:RED)

Yes, Org B is re-writing the object in the sense that they’re moving a marking there. But since semantically the marking was already there when it received it from Org A this seems fine to me. IMO resharers should be free to do things like this so long
as they don’t change the actual content  of what they’re retransmitting.


OTOH if this is not something the community thinks is valid then I would lean more towards what Aharon is suggesting and require that people mark the objects directly, otherwise he’s right that they’ll get “stuck” because you can’t retransmit them outside
the context of the package that they came in.


John








From: Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Date: Tuesday, December 8, 2015 at 1:44 PM
To: Aharon Chernin < achernin@soltra.com >
Cc: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings





" If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White.


This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings.


Is that something that was decided?


-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Aharon
Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo

From: Aharon Chernin < achernin@soltra.com >
To: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Date: 12/07/2015 05:26 PM
Subject: Re: [cti-stix] Applying data markings
Sent by: < cti-stix@lists.oasis-open.org >





I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in
another document and document mark that object as TLP White.

If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning
rules or the ID hash.

I am not going to put up a huge fight here, but it just seems so obvious to me.

Aharon

From: < cti-stix@lists.oasis-open.org >
on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Monday, December 7, 2015 at 3:42 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings

All,

I updated the proposal based on the comments from last week:
https://github.com/johnwunder/data-markings .

A few comments (on the comments…):

- Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back.

- Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means
that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per
Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2).

- Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure
based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you).

- That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath.

To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):

1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (
2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?
3. Should we keep markings at the package level or move all markings to the individual top-level objects?

My answers:

1. Not sure to be honest. Leaning towards not MTI.
2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway.
3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”,
which means other gov’t may as well.

John


On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote:

This does look like a good approach for message level markings.

Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative
Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under
that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not
be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered
for CTI. The exchange agreement reference can be a kind of marking.
-Cory

From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Barnum, Sean D.
Sent: Monday, December 07, 2015 9:49 AM
To: Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings

I fully support this option as would be expected.
Kudos to John for such a great writeup explaining the idea.

sean

From: " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Thursday, December 3, 2015 at 3:11 PM
To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Applying data markings

All,

I developed this proposal to handle the application of data markings in STIX 2.0:
https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves (improvements
to TLP, the work in FIRST, etc), just how those markings get applied to content.

I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about
feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).

John

Imagine that i am signing [0] (oops marking) my "TLP Red" objects à la PGP. (Of course i defined my friends) If you find a way for Alice and Bob in  JSON please let me know Warning: dont click (complexity) [0]  http://www.w3.org/TR/XAdES/ On Thursday, 10 December 2015, Wunder, John A. < jwunder@mitre.org > wrote: That’s a great point that totally slipped my mind. In STIX 1.2, we said that the “marking scope” was limited to the construct itself. We didn’t say anything about the root of the document for purposes of evaluation (I just checked) so effectively it’s the root of the full package. Thus, as you say, it was possible to mark things outside the actual scope. I don’t know why we did this…whether we just didn’t think about it or whether it was because it’s (relatively) hard to pull a snippet of XML out of a document and have it live on its own (due to namespace mappings and things like that “higher” in the document that impact things at “lower” levels). So, in STIX 1.2, it’s up to the implementation to ensure that the things it marks are limited to the correct marking scope. When defining this approach for STIX 1.2 I took a queue from JSON/JSONPath and considered just “re-rooting” the document. It’s very easy to do this in JSON because things higher in the document don’t impact things lower in the document, you can just pull that chunk out and it will always be valid JSON. Given that freedom in the (presumed) MTI, for this proposal I defined it differently: the actual evaluation root for the controlled structure is the object itself, and therefore when evaluating it you can/should just pull the chunk out completely and evaluate against that. That would prevent people from marking things outside the scope without requiring extra work on the implementation side. If we develop an XML binding, we’ll have to figure out whether we need to override that and go back to the old approach. I would GUESS that this approach will still be better in XML even though you have to deal with namespace prefixes, but I’m not 100% sure. We could always use one for JSON and a different one for XML though. That actually brings up another important point: if we assume JSON MTI is one format among several, tools will have to evaluate data markings and then track them in their repositories separate  from the MTI approach, then be able to build and retransmit those markings in another format. In other words, if I take in JSON MTI I would need to evaluate that on the incoming JSON and store it in my database somehow. If I want to transmit into protobuf, I can’t just use those JSONPath markings because they’re no longer valid…they have to be redone in whatever we define for Protobuf. Just something to think about regarding the “storing STIX natively” topic. John From: Marlon Taylor < Marlon.Taylor@hq.dhs.gov > Date: Thursday, December 10, 2015 at 9:33 AM To: Sean Barnum < sbarnum@mitre.org >, "Wunder, John A." < jwunder@mitre.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Aharon Chernin < achernin@soltra.com > Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: RE: [cti-stix] Applying data markings Moving to go deeper on L2 markings I would like more information on the restriction/enforcement of the scope of the specific field path. Background and Questions: The L2 path is supposed to be limited to the "current" object however path syntax allow you reference other (eg parent, sibling, non-self) objects.  Even given a regex to require the first characters reference the "current" object a) how do we ensure the full path doesn't go outside of the current object? b) if the full path goes outside of the current object, and what is the expected behavior? Let's continue to narrow this discussion to conclusion. -Marlon   From: cti-stix@lists.oasis-open.org on behalf of Barnum, Sean D. Sent: Tuesday, December 08, 2015 2:33:39 PM To: Wunder, John A.; Jason Keirstead; Aharon Chernin Cc: cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Applying data markings I agree with John’s characterization here. sean From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org > Date: Tuesday, December 8, 2015 at 2:15 PM To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Aharon Chernin < achernin@soltra.com > Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings Nope, for any of these approaches we rely on the client software to do the right thing and preserve data markings (as well as honor them in the first place). For this reason, it seems to me that as long as we define the semantics for how markings are applied at the package level we don’t need to have them exist directly on the object. We can just define that they’re semantically equivalent and allow people who are retransmitting objects to move them between the package and the object as they want (assuming of course that they preserve those semantics). In other words, to me this would be a valid retransmission: Org A => Org B Package (TLP:RED) Object 1 Object 2 Org B => Org C Package Object 1 (TLP:RED) Object 2 (TLP:RED) Yes, Org B is re-writing the object in the sense that they’re moving a marking there. But since semantically the marking was already there when it received it from Org A this seems fine to me. IMO resharers should be free to do things like this so long as they don’t change the actual content  of what they’re retransmitting. OTOH if this is not something the community thinks is valid then I would lean more towards what Aharon is suggesting and require that people mark the objects directly, otherwise he’s right that they’ll get “stuck” because you can’t retransmit them outside the context of the package that they came in. John From: Jason Keirstead < Jason.Keirstead@ca.ibm.com > Date: Tuesday, December 8, 2015 at 1:44 PM To: Aharon Chernin < achernin@soltra.com > Cc: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings " If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings. Is that something that was decided? - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown Aharon Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo From: Aharon Chernin < achernin@soltra.com > To: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Date: 12/07/2015 05:26 PM Subject: Re: [cti-stix] Applying data markings Sent by: < cti-stix@lists.oasis-open.org > I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning rules or the ID hash. I am not going to put up a huge fight here, but it just seems so obvious to me. Aharon From: < cti-stix@lists.oasis-open.org > on behalf of "Wunder, John A." < jwunder@mitre.org > Date: Monday, December 7, 2015 at 3:42 PM To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings All, I updated the proposal based on the comments from last week: https://github.com/johnwunder/data-markings . A few comments (on the comments…): - Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back. - Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2). - Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you). - That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath. To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”): 1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? ( 2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)? 3. Should we keep markings at the package level or move all markings to the individual top-level objects? My answers: 1. Not sure to be honest. Leaning towards not MTI. 2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway. 3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which means other gov’t may as well. John On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote: This does look like a good approach for message level markings. Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking. -Cory From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Barnum, Sean D. Sent: Monday, December 07, 2015 9:49 AM To: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Applying data markings I fully support this option as would be expected. Kudos to John for such a great writeup explaining the idea. sean From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org > Date: Thursday, December 3, 2015 at 3:11 PM To: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > Subject: [cti-stix] Applying data markings All, I developed this proposal to handle the application of data markings in STIX 2.0: https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content. I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap). John

Digital signatures and markings are different: digital signatures allow you as consumer to to be cryptographically sure that the producer who you think sent the message actually sent it and that it was not modified in any way. Markings allows me as a producer
to tell you how you should treat the content once you get it (who you can share it with, what you can do with it, etc).


We’ll need to talk about signing JSON at some point though, when we do we can look into RFC7515 (JSON Web Signatures).


John








From: Jerome Athias < athiasjerome@gmail.com >
Date: Thursday, December 10, 2015 at 10:29 AM
To: "Wunder, John A." < jwunder@mitre.org >
Cc: Marlon Taylor < Marlon.Taylor@hq.dhs.gov >, Sean Barnum < sbarnum@mitre.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >,
Aharon Chernin < achernin@soltra.com >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings




Imagine that i am signing [0] (oops marking) my "TLP Red" objects à la PGP.
(Of course i defined my friends)


If you find a way for Alice and Bob in  JSON please let me know


Warning: dont click (complexity)
[0]  http://www.w3.org/TR/XAdES/

On Thursday, 10 December 2015, Wunder, John A. < jwunder@mitre.org > wrote:



That’s a great point that totally slipped my mind.


In STIX 1.2, we said that the “marking scope” was limited to the construct itself. We didn’t say anything about the root of the document for purposes of evaluation (I just checked) so effectively it’s the root of the full package. Thus, as you say, it
was possible to mark things outside the actual scope. I don’t know why we did this…whether we just didn’t think about it or whether it was because it’s (relatively) hard to pull a snippet of XML out of a document and have it live on its own (due to namespace
mappings and things like that “higher” in the document that impact things at “lower” levels). So, in STIX 1.2, it’s up to the implementation to ensure that the things it marks are limited to the correct marking scope.


When defining this approach for STIX 1.2 I took a queue from JSON/JSONPath and considered just “re-rooting” the document. It’s very easy to do this in JSON because things higher in the document don’t impact things lower in the document, you can just pull
that chunk out and it will always be valid JSON. Given that freedom in the (presumed) MTI, for this proposal I defined it differently: the actual evaluation root for the controlled structure is the object itself, and therefore when evaluating it you can/should
just pull the chunk out completely and evaluate against that. That would prevent people from marking things outside the scope without requiring extra work on the implementation side.


If we develop an XML binding, we’ll have to figure out whether we need to override that and go back to the old approach. I would GUESS that this approach will still be better in XML even though you have to deal with namespace prefixes, but I’m not 100%
sure. We could always use one for JSON and a different one for XML though.


That actually brings up another important point: if we assume JSON MTI is one format among several, tools will have to evaluate data markings and then track them in their repositories
separate  from the MTI approach, then be able to build and retransmit those markings in another format. In other words, if I take in JSON MTI I would need to evaluate that on the incoming JSON and store it in my database
somehow. If I want to transmit into protobuf, I can’t just use those JSONPath markings because they’re no longer valid…they have to be redone in whatever we define for Protobuf. Just something to think about regarding the “storing STIX natively” topic.


John





From: Marlon Taylor < Marlon.Taylor@hq.dhs.gov >
Date: Thursday, December 10, 2015 at 9:33 AM
To: Sean Barnum < sbarnum@mitre.org >, "Wunder, John A." < jwunder@mitre.org >,
Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Aharon Chernin < achernin@soltra.com >
Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Applying data markings






Moving to go deeper on L2 markings I would like more information on the restriction/enforcement of the scope of the specific field path.

Background and Questions: The L2 path is supposed to be limited to the "current" object however path syntax allow you reference other (eg parent, sibling, non-self) objects.  Even given a regex to require the first characters reference the "current" object

a) how do we ensure the full path doesn't go outside of the current object?
b) if the full path goes outside of the current object, and what is the expected behavior?

Let's continue to narrow this discussion to conclusion.

-Marlon


 


From:
cti-stix@lists.oasis-open.org on behalf of Barnum, Sean D.
Sent: Tuesday, December 08, 2015 2:33:39 PM
To: Wunder, John A.; Jason Keirstead; Aharon Chernin
Cc:
cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings





I agree with John’s characterization here.


sean









From: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
on behalf of John Wunder < jwunder@mitre.org >
Date: Tuesday, December 8, 2015 at 2:15 PM
To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Aharon Chernin < achernin@soltra.com >
Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings






Nope, for any of these approaches we rely on the client software to do the right thing and preserve data markings (as well as honor them in the first place).


For this reason, it seems to me that as long as we define the semantics for how markings are applied at the package level we don’t need to have them exist directly on the object. We can just define that they’re semantically equivalent and allow people
who are retransmitting objects to move them between the package and the object as they want (assuming of course that they preserve those semantics).


In other words, to me this would be a valid retransmission:


Org A => Org B

Package (TLP:RED)

Object 1 Object 2

Org B => Org C

Package

Object 1 (TLP:RED) Object 2 (TLP:RED)

Yes, Org B is re-writing the object in the sense that they’re moving a marking there. But since semantically the marking was already there when it received it from Org A this seems fine to me. IMO resharers should be free to do things like this so long
as they don’t change the actual content  of what they’re retransmitting.


OTOH if this is not something the community thinks is valid then I would lean more towards what Aharon is suggesting and require that people mark the objects directly, otherwise he’s right that they’ll get “stuck” because you can’t retransmit them outside
the context of the package that they came in.


John








From: Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Date: Tuesday, December 8, 2015 at 1:44 PM
To: Aharon Chernin < achernin@soltra.com >
Cc: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings





" If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White.


This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings.


Is that something that was decided?


-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security
www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Aharon
Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo

From: Aharon Chernin < achernin@soltra.com >
To: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Date: 12/07/2015 05:26 PM
Subject: Re: [cti-stix] Applying data markings
Sent by: < cti-stix@lists.oasis-open.org >





I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in
another document and document mark that object as TLP White.

If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning
rules or the ID hash.

I am not going to put up a huge fight here, but it just seems so obvious to me.

Aharon

From: < cti-stix@lists.oasis-open.org >
on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Monday, December 7, 2015 at 3:42 PM
To: " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings

All,

I updated the proposal based on the comments from last week:
https://github.com/johnwunder/data-markings .

A few comments (on the comments…):

- Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back.

- Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means
that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per
Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2).

- Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure
based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you).

- That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath.

To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):

1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (
2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?
3. Should we keep markings at the package level or move all markings to the individual top-level objects?

My answers:

1. Not sure to be honest. Leaning towards not MTI.
2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway.
3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”,
which means other gov’t may as well.

John


On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote:

This does look like a good approach for message level markings.

Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative
Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under
that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not
be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered
for CTI. The exchange agreement reference can be a kind of marking.
-Cory

From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Barnum, Sean D.
Sent: Monday, December 07, 2015 9:49 AM
To: Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings

I fully support this option as would be expected.
Kudos to John for such a great writeup explaining the idea.

sean

From: " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org >
Date: Thursday, December 3, 2015 at 3:11 PM
To: " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Applying data markings

All,

I developed this proposal to handle the application of data markings in STIX 2.0:
https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves
(improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.

I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about
feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).

John

If you don’t mind funding a research project (hint, Rich), we could look into partial encryption and multi key encryption technologies to cryptographically guarantee that how you mark the data is how it is received. Note that it is physically impossible, short of some kind of quantum crypto magic, to cryptographically enforce anything that lets people see plaintext at some point. [Shameless self promotion] we do have a technology that does let you send around Snort filters, yet it is impossible to decode what the filters are, even down to monitoring the firewall. It’s not science fiction - we require two devices ;-) On Dec 10, 2015, at 10:43 AM, Wunder, John A. < jwunder@MITRE.ORG > wrote: Digital signatures and markings are different: digital signatures allow you as consumer to to be cryptographically sure that the producer who you think sent the message actually sent it and that it was not modified in any way. Markings allows me as a producer to tell you how you should treat the content once you get it (who you can share it with, what you can do with it, etc). We’ll need to talk about signing JSON at some point though, when we do we can look into RFC7515 (JSON Web Signatures). John From: Jerome Athias < athiasjerome@gmail.com > Date: Thursday, December 10, 2015 at 10:29 AM To: Wunder, John A. < jwunder@mitre.org > Cc: Marlon Taylor < Marlon.Taylor@hq.dhs.gov >, Sean Barnum < sbarnum@mitre.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Aharon Chernin < achernin@soltra.com >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings Imagine that i am signing [0] (oops marking) my TLP Red objects à la PGP. (Of course i defined my friends) If you find a way for Alice and Bob in  JSON please let me know Warning: dont click (complexity) [0]  http://www.w3.org/TR/XAdES/ On Thursday, 10 December 2015, Wunder, John A. < jwunder@mitre.org > wrote: That’s a great point that totally slipped my mind. In STIX 1.2, we said that the “marking scope” was limited to the construct itself. We didn’t say anything about the root of the document for purposes of evaluation (I just checked) so effectively it’s the root of the full package. Thus, as you say, it was possible to mark things outside the actual scope. I don’t know why we did this…whether we just didn’t think about it or whether it was because it’s (relatively) hard to pull a snippet of XML out of a document and have it live on its own (due to namespace mappings and things like that “higher” in the document that impact things at “lower” levels). So, in STIX 1.2, it’s up to the implementation to ensure that the things it marks are limited to the correct marking scope. When defining this approach for STIX 1.2 I took a queue from JSON/JSONPath and considered just “re-rooting” the document. It’s very easy to do this in JSON because things higher in the document don’t impact things lower in the document, you can just pull that chunk out and it will always be valid JSON. Given that freedom in the (presumed) MTI, for this proposal I defined it differently: the actual evaluation root for the controlled structure is the object itself, and therefore when evaluating it you can/should just pull the chunk out completely and evaluate against that. That would prevent people from marking things outside the scope without requiring extra work on the implementation side. If we develop an XML binding, we’ll have to figure out whether we need to override that and go back to the old approach. I would GUESS that this approach will still be better in XML even though you have to deal with namespace prefixes, but I’m not 100% sure. We could always use one for JSON and a different one for XML though. That actually brings up another important point: if we assume JSON MTI is one format among several, tools will have to evaluate data markings and then track them in their repositories separate  from the MTI approach, then be able to build and retransmit those markings in another format. In other words, if I take in JSON MTI I would need to evaluate that on the incoming JSON and store it in my database somehow. If I want to transmit into protobuf, I can’t just use those JSONPath markings because they’re no longer valid…they have to be redone in whatever we define for Protobuf. Just something to think about regarding the “storing STIX natively” topic. John From: Marlon Taylor < Marlon.Taylor@hq.dhs.gov > Date: Thursday, December 10, 2015 at 9:33 AM To: Sean Barnum < sbarnum@mitre.org >, Wunder, John A. < jwunder@mitre.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Aharon Chernin < achernin@soltra.com > Cc: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: RE: [cti-stix] Applying data markings Moving to go deeper on L2 markings I would like more information on the restriction/enforcement of the scope of the specific field path. Background and Questions: The L2 path is supposed to be limited to the current object however path syntax allow you reference other (eg parent, sibling, non-self) objects.  Even given a regex to require the first characters reference the current object a) how do we ensure the full path doesn't go outside of the current object? b) if the full path goes outside of the current object, and what is the expected behavior? Let's continue to narrow this discussion to conclusion. -Marlon   From: cti-stix@lists.oasis-open.org on behalf of Barnum, Sean D. Sent: Tuesday, December 08, 2015 2:33:39 PM To: Wunder, John A.; Jason Keirstead; Aharon Chernin Cc: cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Applying data markings I agree with John’s characterization here. sean From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org > Date: Tuesday, December 8, 2015 at 2:15 PM To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Aharon Chernin < achernin@soltra.com > Cc: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings Nope, for any of these approaches we rely on the client software to do the right thing and preserve data markings (as well as honor them in the first place). For this reason, it seems to me that as long as we define the semantics for how markings are applied at the package level we don’t need to have them exist directly on the object. We can just define that they’re semantically equivalent and allow people who are retransmitting objects to move them between the package and the object as they want (assuming of course that they preserve those semantics). In other words, to me this would be a valid retransmission: Org A => Org B Package (TLP:RED) Object 1 Object 2 Org B => Org C Package Object 1 (TLP:RED) Object 2 (TLP:RED) Yes, Org B is re-writing the object in the sense that they’re moving a marking there. But since semantically the marking was already there when it received it from Org A this seems fine to me. IMO resharers should be free to do things like this so long as they don’t change the actual content  of what they’re retransmitting. OTOH if this is not something the community thinks is valid then I would lean more towards what Aharon is suggesting and require that people mark the objects directly, otherwise he’s right that they’ll get “stuck” because you can’t retransmit them outside the context of the package that they came in. John From: Jason Keirstead < Jason.Keirstead@ca.ibm.com > Date: Tuesday, December 8, 2015 at 1:44 PM To: Aharon Chernin < achernin@soltra.com > Cc: Wunder, John A. < jwunder@mitre.org >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings. Is that something that was decided? - Jason Keirstead Product Architect, Security Intelligence, IBM Security Systems www.ibm.com/security www.securityintelligence.com Without data, all you are is just another person with an opinion - Unknown <graycol.gif> Aharon Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo From: Aharon Chernin < achernin@soltra.com > To: Wunder, John A. < jwunder@mitre.org >, cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Date: 12/07/2015 05:26 PM Subject: Re: [cti-stix] Applying data markings Sent by: < cti-stix@lists.oasis-open.org > I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White. If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object without breaking the revisioning rules or the ID hash. I am not going to put up a huge fight here, but it just seems so obvious to me. Aharon From: < cti-stix@lists.oasis-open.org > on behalf of Wunder, John A. < jwunder@mitre.org > Date: Monday, December 7, 2015 at 3:42 PM To: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: Re: [cti-stix] Applying data markings All, I updated the proposal based on the comments from last week: https://github.com/johnwunder/data-markings . A few comments (on the comments…): - Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back. - Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2). - Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you). - That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath. To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”): 1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? ( 2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)? 3. Should we keep markings at the package level or move all markings to the individual top-level objects? My answers: 1. Not sure to be honest. Leaning towards not MTI. 2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway. 3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which means other gov’t may as well. John On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote: This does look like a good approach for message level markings. Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking. -Cory From: cti-stix@lists.oasis-open.org [ mailto:cti-stix@lists.oasis-open.org ] On Behalf Of Barnum, Sean D. Sent: Monday, December 07, 2015 9:49 AM To: Wunder, John A.; cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Applying data markings I fully support this option as would be expected. Kudos to John for such a great writeup explaining the idea. sean From: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > on behalf of John Wunder < jwunder@mitre.org > Date: Thursday, December 3, 2015 at 3:11 PM To: cti-stix@lists.oasis-open.org < cti-stix@lists.oasis-open.org > Subject: [cti-stix] Applying data markings All, I developed this proposal to handle the application of data markings in STIX 2.0: https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content. I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap). John <graycol.gif> --------------------------------------------------------------------- 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 Attachment: smime.p7s Description: S/MIME cryptographic signature

Grabbed this example from the option 5 approach overriding-package-markings-1 example (https://github.com/johnwunder/data-markings#overriding-package-markings-1):
{
  "stix_version": "2.0",
  "marking_definitions": [
    {
      "id": "us-cert:TLP-RED",
      "marking_type": "tlp",
      "tlp": "RED"
    },
    {
      "id": "us-cert:TLP-GREEN",
      "marking_type": "tlp",
      "tlp": "GREEN"
    }
  ],
  "marking_refs": ["us-cert:TLP-GREEN"],
  "indicators": [
    {
      "id": "indicator-1234",
      "structured_markings": [
        {
          "controlled_structure": [
            "@.title"
          ],
          "marking_refs": ["us-cert:TLP-RED"]
        }
      ],
      "title": "First indicator"
    },
    {
      "id": "indicator-4321",
      "title": "Second indicator"
    }
  ]
}
 
The following questions are referencing the first indicator, indicators[0], which uses L2 markings.

 
1.       
Scoping: What is the scope "controlled_structure":
is in 
"structured_markings":
which is a valid JSON object. This is valid JSON but is this the intended scope for the L2 marking?
2.       
Validation: How can we restrict/enforce the path is limited to the intended object?
3.       
Exceptions: What is the expected behavior if we receive something referencing something outside of the current object?
    {
      "id": "indicator-1234",
      "structured_markings": [
        {
          "controlled_structure": [
           
"$.indicators[1].title "
          ],
          "marking_refs": ["us-cert:TLP-RED"]
        }
      ],
      "title": "First indicator"
    },
    {
      "id": "indicator-4321",
      "title": " Second indicator "
   }
 
-Marlon


From: Wunder, John A. [mailto:jwunder@mitre.org]

Sent: Thursday, December 10, 2015 10:00 AM
To: Taylor, Marlon; Barnum, Sean D.; Jason Keirstead; Aharon Chernin
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings


 


That’s a great point that totally slipped my mind.


 


In STIX 1.2, we said that the “marking scope” was limited to the construct itself. We didn’t say anything about the root of the document for purposes of evaluation
(I just checked) so effectively it’s the root of the full package. Thus, as you say, it was possible to mark things outside the actual scope. I don’t know why we did this…whether we just didn’t think about it or whether it was because it’s (relatively) hard
to pull a snippet of XML out of a document and have it live on its own (due to namespace mappings and things like that “higher” in the document that impact things at “lower” levels). So, in STIX 1.2, it’s up to the implementation to ensure that the things
it marks are limited to the correct marking scope.


 


When defining this approach for STIX 1.2 I took a queue from JSON/JSONPath and considered just “re-rooting” the document. It’s very easy to do this in JSON because
things higher in the document don’t impact things lower in the document, you can just pull that chunk out and it will always be valid JSON. Given that freedom in the (presumed) MTI, for this proposal I defined it differently: the actual evaluation root for
the controlled structure is the object itself, and therefore when evaluating it you can/should just pull the chunk out completely and evaluate against that. That would prevent people from marking things outside the scope without requiring extra work on the
implementation side.


 


If we develop an XML binding, we’ll have to figure out whether we need to override that and go back to the old approach. I would GUESS that this approach will
still be better in XML even though you have to deal with namespace prefixes, but I’m not 100% sure. We could always use one for JSON and a different one for XML though.


 


That actually brings up another important point: if we assume JSON MTI is one format among several, tools will have to evaluate data markings and then track them
in their repositories separate  from the MTI approach, then be able to build and retransmit those markings in another format. In other words, if I take in JSON MTI I would need to evaluate that on the incoming JSON and store it in my database somehow.
If I want to transmit into protobuf, I can’t just use those JSONPath markings because they’re no longer valid…they have to be redone in whatever we define for Protobuf. Just something to think about regarding the “storing STIX natively” topic.


 


John


 



From:
Marlon Taylor < Marlon.Taylor@hq.dhs.gov >
Date: Thursday, December 10, 2015 at 9:33 AM
To: Sean Barnum < sbarnum@mitre.org >, "Wunder, John A." < jwunder@mitre.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Aharon
Chernin < achernin@soltra.com >
Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Applying data markings


 




Moving to go deeper on L2 markings I would like more information on the restriction/enforcement of the scope of the specific field path.

Background and Questions: The L2 path is supposed to be limited to the "current" object however path syntax allow you reference other (eg parent, sibling, non-self) objects.  Even given a regex to require the first characters reference the "current" object

a) how do we ensure the full path doesn't go outside of the current object?
b) if the full path goes outside of the current object, and what is the expected behavior?

Let's continue to narrow this discussion to conclusion.

-Marlon

 




From:
cti-stix@lists.oasis-open.org on behalf of Barnum, Sean D.
Sent: Tuesday, December 08, 2015 2:33:39 PM
To: Wunder, John A.; Jason Keirstead; Aharon Chernin
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings




I agree with John’s characterization here.


 


sean




 


From:
" cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of John Wunder
< jwunder@mitre.org >
Date: Tuesday, December 8, 2015 at 2:15 PM
To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Aharon Chernin < achernin@soltra.com >
Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings


 





Nope, for any of these approaches we rely on the client software to do the right thing and preserve data markings (as well as honor them in the first place).


 


For this reason, it seems to me that as long as we define the semantics for how markings are applied at the package level we don’t need to have them exist directly
on the object. We can just define that they’re semantically equivalent and allow people who are retransmitting objects to move them between the package and the object as they want (assuming of course that they preserve those semantics).


 


In other words, to me this would be a valid retransmission:


 


Org A => Org B



Package (TLP:RED)




Object 1
Object 2


Org B => Org C



Package



Object 1 (TLP:RED)
Object 2 (TLP:RED)


Yes, Org B is re-writing the object in the sense that they’re moving a marking there. But since semantically the marking was already there when it received it
from Org A this seems fine to me. IMO resharers should be free to do things like this so long as they don’t change the actual
content  of what they’re retransmitting.


 


OTOH if this is not something the community thinks is valid then I would lean more towards what Aharon is suggesting and require that people mark the objects
directly, otherwise he’s right that they’ll get “stuck” because you can’t retransmit them outside the context of the package that they came in.


 


John



 


From:
Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Date: Tuesday, December 8, 2015 at 1:44 PM
To: Aharon Chernin < achernin@soltra.com >
Cc: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings


 



" If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and document mark
that object as TLP White.

This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings.


Is that something that was decided?


-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Aharon
Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo

From:
Aharon Chernin < achernin@soltra.com >
To:
"Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Date:
12/07/2015 05:26 PM
Subject:
Re: [cti-stix] Applying data markings
Sent by:
< cti-stix@lists.oasis-open.org >






I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and
document mark that object as TLP White.

If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object
and reuse that object without breaking the revisioning rules or the ID hash.

I am not going to put up a huge fight here, but it just seems so obvious to me.

Aharon

From:
< cti-stix@lists.oasis-open.org >
on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Monday, December 7, 2015 at 3:42 PM
To: " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings

All,

I updated the proposal based on the comments from last week:
https://github.com/johnwunder/data-markings .

A few comments (on the comments…):

- Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back.

- Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that if you discard
the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s earlier e-mail
I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2).

- Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach with all
the implementation complexity that it brings (as Bryan Worrell can tell you).

- That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath.

To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):

1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (
2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?
3. Should we keep markings at the package level or move all markings to the individual top-level objects?

My answers:

1. Not sure to be honest. Leaning towards not MTI.
2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway.
3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which means other gov’t
may as well.

John
On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote:

This does look like a good approach for message level markings.

Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been
around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization
and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the
exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest
exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking.
-Cory

From: cti-stix@lists.oasis-open.org
[ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Barnum, Sean D.
Sent: Monday, December 07, 2015 9:49 AM
To: Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings

I fully support this option as would be expected.
Kudos to John for such a great writeup explaining the idea.

sean

From:
" cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
on behalf of John Wunder < jwunder@mitre.org >
Date: Thursday, December 3, 2015 at 3:11 PM
To: " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Applying data markings

All,

I developed this proposal to handle the application of data markings in STIX 2.0:
https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.

I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about feedback. If this looks
good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).

John
 

So here’s my perspective:
 
1.       
In the specification, the line is “When used on a top-level object, the root of the controlled structure specification is the object” (maybe that should
be clarified to, “the root of the controlled structure specification is the top-level object”). In other words, when used within an indicator, the controlled_structure should be evaluated as if the document is JUST that indicator. Same for a TTP, etc. When
used in a package, obviously the package is the root.
2.       
By making the root the same as the scope, it makes it very natural to do the right thing. In order to get the right answer you need to evaluate it as
if the object is the root, and thus you should not evaluate it with the whole document (you should pull that object out of the document and evaluate it). Obviously, you can write invalid JSONPath expressions, either maliciously or accidentally. These just
have to throw an error.
3.       
For the purposes of that evaluation, the document will look like this:
 
{
"id": "indicator-1234",
      "structured_markings":
[
{
          "controlled_structure": [
           
"$.indicators[1].title "
          ],
          "marking_refs": ["us-cert:TLP-RED"]
}
]
"title": "First indicator"
}
 
Thus, evaluating that JSONPath will lead to no results, because there’s no indicators key in the document. Yes, a consumer could potentially evaluate it in the
context of the document, but even for well-formed queries that will almost always lead to the wrong result. So while we’re not validating it in schema (t’s impossible to do so, either in XML or JSON) we are making it very natural and easy to do the right thing
(unlike the current approach, which is asking for this type of problem).
 
John
 


From: Taylor, Marlon [mailto:Marlon.Taylor@hq.dhs.gov]

Sent: Thursday, December 10, 2015 2:46 PM
To: Wunder, John A. <jwunder@mitre.org>; Barnum, Sean D. <sbarnum@mitre.org>; Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Aharon Chernin <achernin@soltra.com>
Cc: cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Applying data markings


 
Grabbed this example from the option 5 approach overriding-package-markings-1 example (https://github.com/johnwunder/data-markings#overriding-package-markings-1):
{
  "stix_version": "2.0",
  "marking_definitions": [
    {
      "id": "us-cert:TLP-RED",
      "marking_type": "tlp",
      "tlp": "RED"
    },
    {
      "id": "us-cert:TLP-GREEN",
      "marking_type": "tlp",
      "tlp": "GREEN"
    }
  ],
  "marking_refs": ["us-cert:TLP-GREEN"],
  "indicators": [
    {
      "id": "indicator-1234",
      "structured_markings": [
        {
          "controlled_structure": [
            "@.title"
          ],
          "marking_refs": ["us-cert:TLP-RED"]
        }
      ],
      "title": "First indicator"
    },
    {
      "id": "indicator-4321",
      "title": "Second indicator"
    }
  ]
}
 
The following questions are referencing the first indicator, indicators[0], which uses L2 markings.

 

1.       
Scoping: What is the scope "controlled_structure":
is in 
"structured_markings":
which is a valid JSON object. This is valid JSON but is this the intended scope for the L2 marking?

2.       
Validation: How can we restrict/enforce the path is limited to the intended object?

3.       
Exceptions: What is the expected behavior if we receive something referencing something outside of the current object?
    {
      "id": "indicator-1234",
      "structured_markings": [
        {
          "controlled_structure": [
           
"$.indicators[1].title "
          ],
          "marking_refs": ["us-cert:TLP-RED"]
        }
      ],
      "title": "First indicator"
    },
    {
      "id": "indicator-4321",
      "title": " Second indicator "
   }
 
-Marlon


From: Wunder, John A. [mailto:jwunder@mitre.org]

Sent: Thursday, December 10, 2015 10:00 AM
To: Taylor, Marlon; Barnum, Sean D.; Jason Keirstead; Aharon Chernin
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings


 


That’s a great point that totally slipped my mind.


 


In STIX 1.2, we said that the “marking scope” was limited to the construct itself. We didn’t say anything about the root of the document
for purposes of evaluation (I just checked) so effectively it’s the root of the full package. Thus, as you say, it was possible to mark things outside the actual scope. I don’t know why we did this…whether we just didn’t think about it or whether it was because
it’s (relatively) hard to pull a snippet of XML out of a document and have it live on its own (due to namespace mappings and things like that “higher” in the document that impact things at “lower” levels). So, in STIX 1.2, it’s up to the implementation to
ensure that the things it marks are limited to the correct marking scope.


 


When defining this approach for STIX 1.2 I took a queue from JSON/JSONPath and considered just “re-rooting” the document. It’s very easy
to do this in JSON because things higher in the document don’t impact things lower in the document, you can just pull that chunk out and it will always be valid JSON. Given that freedom in the (presumed) MTI, for this proposal I defined it differently: the
actual evaluation root for the controlled structure is the object itself, and therefore when evaluating it you can/should just pull the chunk out completely and evaluate against that. That would prevent people from marking things outside the scope without
requiring extra work on the implementation side.


 


If we develop an XML binding, we’ll have to figure out whether we need to override that and go back to the old approach. I would GUESS
that this approach will still be better in XML even though you have to deal with namespace prefixes, but I’m not 100% sure. We could always use one for JSON and a different one for XML though.


 


That actually brings up another important point: if we assume JSON MTI is one format among several, tools will have to evaluate data markings
and then track them in their repositories separate  from the MTI approach, then be able to build and retransmit those markings in another format. In other words, if I take in JSON MTI I would need to evaluate that on the incoming JSON and store it in
my database somehow. If I want to transmit into protobuf, I can’t just use those JSONPath markings because they’re no longer valid…they have to be redone in whatever we define for Protobuf. Just something to think about regarding the “storing STIX natively”
topic.


 


John


 



From:
Marlon Taylor < Marlon.Taylor@hq.dhs.gov >
Date: Thursday, December 10, 2015 at 9:33 AM
To: Sean Barnum < sbarnum@mitre.org >, "Wunder, John A." < jwunder@mitre.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Aharon
Chernin < achernin@soltra.com >
Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Applying data markings


 





Moving to go deeper on L2 markings I would like more information on the restriction/enforcement of the scope of the specific field path.

Background and Questions: The L2 path is supposed to be limited to the "current" object however path syntax allow you reference other (eg parent, sibling, non-self) objects.  Even given a regex to require the first characters reference the "current" object

a) how do we ensure the full path doesn't go outside of the current object?
b) if the full path goes outside of the current object, and what is the expected behavior?

Let's continue to narrow this discussion to conclusion.

-Marlon

 






From:
cti-stix@lists.oasis-open.org on behalf of Barnum, Sean D.
Sent: Tuesday, December 08, 2015 2:33:39 PM
To: Wunder, John A.; Jason Keirstead; Aharon Chernin
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings




I agree with John’s characterization here.


 


sean




 


From:
" cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of John Wunder
< jwunder@mitre.org >
Date: Tuesday, December 8, 2015 at 2:15 PM
To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Aharon Chernin < achernin@soltra.com >
Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings


 





Nope, for any of these approaches we rely on the client software to do the right thing and preserve data markings (as well as honor them
in the first place).


 


For this reason, it seems to me that as long as we define the semantics for how markings are applied at the package level we don’t need
to have them exist directly on the object. We can just define that they’re semantically equivalent and allow people who are retransmitting objects to move them between the package and the object as they want (assuming of course that they preserve those semantics).


 


In other words, to me this would be a valid retransmission:


 


Org A => Org B


·         
Package (TLP:RED)


o    
Object 1

o    
Object 2

Org B => Org C


·         
Package


o    
Object 1 (TLP:RED)

o    
Object 2 (TLP:RED)

Yes, Org B is re-writing the object in the sense that they’re moving a marking there. But since semantically the marking was already there
when it received it from Org A this seems fine to me. IMO resharers should be free to do things like this so long as they don’t change the actual
content  of what they’re retransmitting.


 


OTOH if this is not something the community thinks is valid then I would lean more towards what Aharon is suggesting and require that people
mark the objects directly, otherwise he’s right that they’ll get “stuck” because you can’t retransmit them outside the context of the package that they came in.


 


John



 


From:
Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Date: Tuesday, December 8, 2015 at 1:44 PM
To: Aharon Chernin < achernin@soltra.com >
Cc: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings


 



" If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another
document and document mark that object as TLP White.

This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings.


Is that something that was decided?


-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Aharon
Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo

From:
Aharon Chernin < achernin@soltra.com >
To:
"Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Date:
12/07/2015 05:26 PM
Subject:
Re: [cti-stix] Applying data markings
Sent by:
< cti-stix@lists.oasis-open.org >








I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and
document mark that object as TLP White.

If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and
reuse that object without breaking the revisioning rules or the ID hash.

I am not going to put up a huge fight here, but it just seems so obvious to me.

Aharon

From:
< cti-stix@lists.oasis-open.org >
on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Monday, December 7, 2015 at 3:42 PM
To: " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings

All,

I updated the proposal based on the comments from last week:
https://github.com/johnwunder/data-markings .

A few comments (on the comments…):

- Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back.

- Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that if you discard
the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s earlier e-mail
I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2).

- Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach with all
the implementation complexity that it brings (as Bryan Worrell can tell you).

- That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath.

To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):

1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (
2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?
3. Should we keep markings at the package level or move all markings to the individual top-level objects?

My answers:

1. Not sure to be honest. Leaning towards not MTI.
2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway.
3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which means other gov’t
may as well.

John
On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote:

This does look like a good approach for message level markings.

Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been
around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization
and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the
exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest
exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking.
-Cory

From: cti-stix@lists.oasis-open.org
[ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Barnum, Sean D.
Sent: Monday, December 07, 2015 9:49 AM
To: Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings

I fully support this option as would be expected.
Kudos to John for such a great writeup explaining the idea.

sean

From:
" cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
on behalf of John Wunder < jwunder@mitre.org >
Date: Thursday, December 3, 2015 at 3:11 PM
To: " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Applying data markings

All,

I developed this proposal to handle the application of data markings in STIX 2.0:
https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.

I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about feedback. If this looks
good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).

John
 

1.       
Rewording and examples (like your response for #3) will go a long way. See #5.
2.       
No technical-enforcement on full path result, got it. I would like to dive deeper into the expected behavior for incorrect (malicious/invalid) path
expressions with my reply in #4.
3.       
Your snippet of the active/current document for the given path expressions shows everyone what should be evaluated for a given L2 scope.
4.       
As for “throwing an error” as mentioned in #2, I have some additional questions around the expected behavior for the scenarios sublisted below. Should
the consumer log and continue/skip or stop/break?

a.       
If the given path _expression_ is invalid (incorrect syntax)

b.      
If the given path goes outside the scope (returns 0 results for the given scope)
5.       
Going deeper into scoping I have the following scenario. I expanded the previous indicator[0] with composite_indicator but this can be any referenced/embedded
object:
{
      "stix_version": "2.0",
      "marking_definitions": [{
            "id": "us-cert:TLP-RED",
            "marking_type": "tlp",
            "tlp": "RED"
      }, {
            "id": "us-cert:TLP-GREEN",
            "marking_type": "tlp",
            "tlp": "GREEN"
      }],
      "marking_refs": ["us-cert:TLP-GREEN"],
      "indicators": [{
            "id": "indicator-1234",
            "structured_markings": [{
                  "controlled_structure": [
                        "@.title",
                        " @.composite_indicators.indicators[0].description "
                  ],
                  "marking_refs": ["us-cert:TLP-RED"]
            }],
            "title": "First indicator",
            "composite_indicators": {
                  "logical_expression": "OR",
                  "indicators": [{
                        "id": "indicator-5678",
                        "structured_markings": [{
                              "controlled_structure": [
                                    "@.title"
                              ],
                              "marking_refs": ["us-cert:TLP-RED"]
                        }],
                        "title": "First Composite indicator",
                        "description": " This is how it all began ... "
                  }]
            }
      }, {
            "id": "indicator-4321",
            "title": "Second indicator"
      }]
}
This would result in Indicator-5678 being all TLP-RED, correct?

 
6.       
Would the answer/result for #5 change depending on whether the nested Indicator was referenced or embedded?
 
-Marlon


From: Wunder, John A. [mailto:jwunder@mitre.org]

Sent: Thursday, December 10, 2015 4:00 PM
To: Taylor, Marlon; Barnum, Sean D.; Jason Keirstead; Aharon Chernin
Cc: cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Applying data markings


 
So here’s my perspective:
 
1.       
In the specification, the line is “When used on a top-level object, the root of the controlled structure specification is the object” (maybe that should be clarified to,
“the root of the controlled structure specification is the top-level object”). In other words, when used within an indicator, the controlled_structure should be evaluated as if the document is JUST that indicator. Same for a TTP, etc. When used in a package,
obviously the package is the root.
2.       
By making the root the same as the scope, it makes it very natural to do the right thing. In order to get the right answer you need to evaluate it as if the object is the
root, and thus you should not evaluate it with the whole document (you should pull that object out of the document and evaluate it). Obviously, you can write invalid JSONPath expressions, either maliciously or accidentally. These just have to throw an error.
3.       
For the purposes of that evaluation, the document will look like this:
 
{
"id": "indicator-1234",
      "structured_markings":
[
{
          "controlled_structure": [
           
"$.indicators[1].title "
          ],
          "marking_refs": ["us-cert:TLP-RED"]
}
]
"title": "First indicator"
}
 
Thus, evaluating that JSONPath will lead to no results, because there’s no indicators key in the document. Yes, a consumer could potentially evaluate it in
the context of the document, but even for well-formed queries that will almost always lead to the wrong result. So while we’re not validating it in schema (t’s impossible to do so, either in XML or JSON) we are making it very natural and easy to do the right
thing (unlike the current approach, which is asking for this type of problem).
 
John
 


From: Taylor, Marlon [ mailto:Marlon.Taylor@hq.dhs.gov ]

Sent: Thursday, December 10, 2015 2:46 PM
To: Wunder, John A. < jwunder@mitre.org >; Barnum, Sean D. < sbarnum@mitre.org >; Jason Keirstead < Jason.Keirstead@ca.ibm.com >;
Aharon Chernin < achernin@soltra.com >
Cc: cti-stix@lists.oasis-open.org
Subject: RE: [cti-stix] Applying data markings


 
Grabbed this example from the option 5 approach overriding-package-markings-1 example ( https://github.com/johnwunder/data-markings#overriding-package-markings-1 ):
{
  "stix_version": "2.0",
  "marking_definitions": [
    {
      "id": "us-cert:TLP-RED",
      "marking_type": "tlp",
      "tlp": "RED"
    },
    {
      "id": "us-cert:TLP-GREEN",
      "marking_type": "tlp",
      "tlp": "GREEN"
    }
  ],
  "marking_refs": ["us-cert:TLP-GREEN"],
  "indicators": [
    {
      "id": "indicator-1234",
      "structured_markings": [
        {
          "controlled_structure": [
            "@.title"
          ],
          "marking_refs": ["us-cert:TLP-RED"]
        }
      ],
      "title": "First indicator"
    },
    {
      "id": "indicator-4321",
      "title": "Second indicator"
    }
  ]
}
 
The following questions are referencing the first indicator, indicators[0], which uses L2 markings.

 
1.       
Scoping: What is the scope "controlled_structure":
is in 
"structured_markings":
which is a valid JSON object. This is valid JSON but is this the intended scope for the L2 marking?
2.       
Validation: How can we restrict/enforce the path is limited to the intended object?
3.       
Exceptions: What is the expected behavior if we receive something referencing something outside of the current object?
    {
      "id": "indicator-1234",
      "structured_markings": [
        {
          "controlled_structure": [
           
"$.indicators[1].title "
          ],
          "marking_refs": ["us-cert:TLP-RED"]
        }
      ],
      "title": "First indicator"
    },
    {
      "id": "indicator-4321",
      "title": " Second indicator "
   }
 
-Marlon


From: Wunder, John A. [ mailto:jwunder@mitre.org ]

Sent: Thursday, December 10, 2015 10:00 AM
To: Taylor, Marlon; Barnum, Sean D.; Jason Keirstead; Aharon Chernin
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings


 


That’s a great point that totally slipped my mind.


 


In STIX 1.2, we said that the “marking scope” was limited to the construct itself. We didn’t say anything about the root of the document
for purposes of evaluation (I just checked) so effectively it’s the root of the full package. Thus, as you say, it was possible to mark things outside the actual scope. I don’t know why we did this…whether we just didn’t think about it or whether it was because
it’s (relatively) hard to pull a snippet of XML out of a document and have it live on its own (due to namespace mappings and things like that “higher” in the document that impact things at “lower” levels). So, in STIX 1.2, it’s up to the implementation to
ensure that the things it marks are limited to the correct marking scope.


 


When defining this approach for STIX 1.2 I took a queue from JSON/JSONPath and considered just “re-rooting” the document. It’s very easy
to do this in JSON because things higher in the document don’t impact things lower in the document, you can just pull that chunk out and it will always be valid JSON. Given that freedom in the (presumed) MTI, for this proposal I defined it differently: the
actual evaluation root for the controlled structure is the object itself, and therefore when evaluating it you can/should just pull the chunk out completely and evaluate against that. That would prevent people from marking things outside the scope without
requiring extra work on the implementation side.


 


If we develop an XML binding, we’ll have to figure out whether we need to override that and go back to the old approach. I would GUESS
that this approach will still be better in XML even though you have to deal with namespace prefixes, but I’m not 100% sure. We could always use one for JSON and a different one for XML though.


 


That actually brings up another important point: if we assume JSON MTI is one format among several, tools will have to evaluate data
markings and then track them in their repositories separate  from the MTI approach, then be able to build and retransmit those markings in another format. In other words, if I take in JSON MTI I would need to evaluate that on the incoming JSON and store
it in my database somehow. If I want to transmit into protobuf, I can’t just use those JSONPath markings because they’re no longer valid…they have to be redone in whatever we define for Protobuf. Just something to think about regarding the “storing STIX natively”
topic.


 


John


 



From:
Marlon Taylor < Marlon.Taylor@hq.dhs.gov >
Date: Thursday, December 10, 2015 at 9:33 AM
To: Sean Barnum < sbarnum@mitre.org >, "Wunder, John A." < jwunder@mitre.org >, Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Aharon
Chernin < achernin@soltra.com >
Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: RE: [cti-stix] Applying data markings


 





Moving to go deeper on L2 markings I would like more information on the restriction/enforcement of the scope of the specific field path.

Background and Questions: The L2 path is supposed to be limited to the "current" object however path syntax allow you reference other (eg parent, sibling, non-self) objects.  Even given a regex to require the first characters reference the "current" object

a) how do we ensure the full path doesn't go outside of the current object?
b) if the full path goes outside of the current object, and what is the expected behavior?

Let's continue to narrow this discussion to conclusion.

-Marlon

 







From:
cti-stix@lists.oasis-open.org on behalf of Barnum, Sean D.
Sent: Tuesday, December 08, 2015 2:33:39 PM
To: Wunder, John A.; Jason Keirstead; Aharon Chernin
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings




I agree with John’s characterization here.


 


sean




 


From:
" cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org > on behalf of John Wunder
< jwunder@mitre.org >
Date: Tuesday, December 8, 2015 at 2:15 PM
To: Jason Keirstead < Jason.Keirstead@ca.ibm.com >, Aharon Chernin < achernin@soltra.com >
Cc: " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings


 





Nope, for any of these approaches we rely on the client software to do the right thing and preserve data markings (as well as honor them
in the first place).


 


For this reason, it seems to me that as long as we define the semantics for how markings are applied at the package level we don’t need
to have them exist directly on the object. We can just define that they’re semantically equivalent and allow people who are retransmitting objects to move them between the package and the object as they want (assuming of course that they preserve those semantics).


 


In other words, to me this would be a valid retransmission:


 


Org A => Org B


·         
Package (TLP:RED)


o    
Object 1

o    
Object 2

Org B => Org C


·         
Package


o    
Object 1 (TLP:RED)

o    
Object 2 (TLP:RED)

Yes, Org B is re-writing the object in the sense that they’re moving a marking there. But since semantically the marking was already
there when it received it from Org A this seems fine to me. IMO resharers should be free to do things like this so long as they don’t change the actual
content  of what they’re retransmitting.


 


OTOH if this is not something the community thinks is valid then I would lean more towards what Aharon is suggesting and require that
people mark the objects directly, otherwise he’s right that they’ll get “stuck” because you can’t retransmit them outside the context of the package that they came in.


 


John



 


From:
Jason Keirstead < Jason.Keirstead@ca.ibm.com >
Date: Tuesday, December 8, 2015 at 1:44 PM
To: Aharon Chernin < achernin@soltra.com >
Cc: "Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings


 



" If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another
document and document mark that object as TLP White.

This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings.


Is that something that was decided?


-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security
www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Aharon
Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo

From:
Aharon Chernin < achernin@soltra.com >
To:
"Wunder, John A." < jwunder@mitre.org >, " cti-stix@lists.oasis-open.org " < cti-stix@lists.oasis-open.org >
Date:
12/07/2015 05:26 PM
Subject:
Re: [cti-stix] Applying data markings
Sent by:
< cti-stix@lists.oasis-open.org >










I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that it’s a specific TLP. I could take that object and use it in another document and
document mark that object as TLP White.

If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object
and reuse that object without breaking the revisioning rules or the ID hash.

I am not going to put up a huge fight here, but it just seems so obvious to me.

Aharon

From:
< cti-stix@lists.oasis-open.org >
on behalf of "Wunder, John A." < jwunder@mitre.org >
Date: Monday, December 7, 2015 at 3:42 PM
To: " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Subject: Re: [cti-stix] Applying data markings

All,

I updated the proposal based on the comments from last week:
https://github.com/johnwunder/data-markings .

A few comments (on the comments…):

- Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched it back.

- Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not duplicated across each indicator). OTOH it also means that if you discard
the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself if you add them to the object, and in any case per Eric’s earlier e-mail
I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2).

- Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but fundamentally it’s still a controlled structure based approach with all
the implementation complexity that it brings (as Bryan Worrell can tell you).

- That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath.

To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):

1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (
2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?
3. Should we keep markings at the package level or move all markings to the individual top-level objects?

My answers:

1. Not sure to be honest. Leaning towards not MTI.
2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway.
3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level markings to represent “highest-classification”, which means other gov’t
may as well.

John
On Dec 7, 2015, at 10:43 AM, Cory Casanave < cory-c@modeldriven.com > wrote:

This does look like a good approach for message level markings.

Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have been
around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any categorization
and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document augment the
exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations. I suggest
exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking.
-Cory

From: cti-stix@lists.oasis-open.org
[ mailto:cti-stix@lists.oasis-open.org ]
On Behalf Of Barnum, Sean D.
Sent: Monday, December 07, 2015 9:49 AM
To: Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings

I fully support this option as would be expected.
Kudos to John for such a great writeup explaining the idea.

sean

From:
" cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
on behalf of John Wunder < jwunder@mitre.org >
Date: Thursday, December 3, 2015 at 3:11 PM
To: " cti-stix@lists.oasis-open.org "
< cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Applying data markings

All,

I developed this proposal to handle the application of data markings in STIX 2.0:
https://github.com/johnwunder/data-markings . Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.

I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them. Please review the proposal and let’s talk about feedback. If this looks
good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).

John