OASIS Cyber Threat Intelligence (CTI) TC

Regarding the recent question and discussion regarding data marking use cases, the ESSA Community (Federal Entities including the National Cyber Centers) has a need for a capability to indicate that certain markings used on STIX documents are themselves sensitive. To support this in the proposed construct, there is a need for the ability to apply data markings (object_marking_refs or granular_markings) to specific marking_definitions themselves. This is supported by making marking_definitions standard TLOs.      Julie Modlin Enhance Shared Situational Awareness (ESSA) Systems Engineering Team Johns Hopkins Applied Physics Laboratory 443-778-6989 / Baltimore 240-228-6989 / Washington  

Hi Julie,   Will that secret marking information ever be seen by someone who is not allowed to see that marking information? What I’m wondering is whether it is redundant to apply data marking restrictions to data marking  if the recipients will only ever see that data marking if they are already allowed to see it.   Additionally, which data marking format would one use to document the restriction on the data marking system? i.e. if someone was using TOP_SECRET_MARKING marking system, will they describe the restriction of that using TLP, or using TOP_SECRET_MARKING? If it’s the later, then how would they describe the restriction of the restriction of that TOP_SECRET_MARKING? By labelling it with TOP_SECRET_MARKING?   As you can see I’m somewhat worried about the cyclical nature of allowing data marking to apply to data marking. I can see it has its uses (e.g. sharing restrictions on the terms of use) but it also seems to have its problems.   I’d really like to know how you and others in a similar position handle this problem in current systems.   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA   An FS-ISAC and DTCC Company +61 (407) 203 206 terry@soltra.com     From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Modlin, Julie K. Sent: Friday, 26 February 2016 6:59 AM To: 'cti@lists.oasis-open.org' <cti@lists.oasis-open.org> Cc: Moss, Mark B. <Mark.Moss@jhuapl.edu>; Barnum, Sean D. (sbarnum@mitre.org) <sbarnum@mitre.org> Subject: [cti] Use case for data markings   Regarding the recent question and discussion regarding data marking use cases, the ESSA Community (Federal Entities including the National Cyber Centers) has a need for a capability to indicate that certain markings used on STIX documents are themselves sensitive. To support this in the proposed construct, there is a need for the ability to apply data markings (object_marking_refs or granular_markings) to specific marking_definitions themselves. This is supported by making marking_definitions standard TLOs.      Julie Modlin Enhance Shared Situational Awareness (ESSA) Systems Engineering Team Johns Hopkins Applied Physics Laboratory 443-778-6989 / Baltimore 240-228-6989 / Washington  

Really well said Terry.. Previously I had not realized the issue you were trying to illustrate.  I think I now do.  Thanks. 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 Feb 25, 2016, at 13:57, Terry MacDonald < terry@soltra.com > wrote: Hi Julie,   Will that secret marking information ever be seen by someone who is not allowed to see that marking information? What I’m wondering is whether it is redundant to apply data marking restrictions to data marking  if the recipients will only ever see that data marking if they are already allowed to see it.   Additionally, which data marking format would one use to document the restriction on the data marking system? i.e. if someone was using TOP_SECRET_MARKING marking system, will they describe the restriction of that using TLP, or using TOP_SECRET_MARKING? If it’s the later, then how would they describe the restriction of the restriction of that TOP_SECRET_MARKING? By labelling it with TOP_SECRET_MARKING?   As you can see I’m somewhat worried about the cyclical nature of allowing data marking to apply to data marking. I can see it has its uses (e.g. sharing restrictions on the terms of use) but it also seems to have its problems.     I’d really like to know how you and others in a similar position handle this problem in current systems.   Cheers   Terry MacDonald Senior STIX Subject Matter Expert SOLTRA   An FS-ISAC and DTCC Company +61 (407) 203 206   terry@soltra.com     From:   cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ]   On Behalf Of   Modlin, Julie K. Sent:   Friday, 26 February 2016 6:59 AM To:   ' cti@lists.oasis-open.org ' < cti@lists.oasis-open.org > Cc:   Moss, Mark B. < Mark.Moss@jhuapl.edu >; Barnum, Sean D. ( sbarnum@mitre.org ) < sbarnum@mitre.org > Subject:   [cti] Use case for data markings   Regarding the recent question and discussion regarding data marking use cases, the ESSA Community (Federal Entities including the National Cyber Centers) has a need for a capability to indicate that certain markings used on STIX documents are themselves sensitive. To support this in the proposed construct, there is a need for the ability to apply data markings (object_marking_refs or granular_markings) to specific marking_definitions themselves. This is supported by making marking_definitions standard TLOs.        Julie Modlin Enhance Shared Situational Awareness (ESSA) Systems Engineering Team Johns Hopkins Applied Physics Laboratory 443-778-6989 / Baltimore 240-228-6989 / Washington Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

Terry, I am confused on how this seems cyclical to you. Maybe I am missing something as it seems relatively straightforward to me.
Let me take a stab at describing a fictitious but realistic scenario that illustrates how this could be used in a relatively simple way.





Lets say that I am part of a small sharing community of 5 orgs that I share CTI with. I am part of numerous other communities as well but this small community is one of them. 
Lets say that part of the context scoping this small community is the fact that we all have access to a particular tool or service that lets us do something with CTI but the existence of that tool/service is only known to the members of this small community
and not to others.
I may want to share CTI to this small community of players some of which has “action” markings saying DO NOT run this CTI in the aforementioned sensitive tool/service. This marking is very useful to tell members of this community what they are allowed
to do with the CTI. 
Now the CTI itself may not necessarily be overly sensitive and may be marked with dissemination markings that allow members of this small community to reshare it with other communities they are part of. 
The existence of the aforementioned tool/service is still sensitive however so I will want to apply more restrictive dissemination markings on the “action” markings themselves than may exist on the other STIX content saying to strip off the “action” markings
when the content is reshared outside the group.



All of this can be done very simply using our current approach where marking-definition is a normal TLO. It would not require any special or different data marking formats and is not recursive or cyclical in any way.


Package {
marking_refs = [marking3]
//marks content of package as shareable to Tier2 communities
Marking-definition {
id=marking1
marking_refs = [marking2]
//overrides package level dissemination marking and restricts this marking to Fight Club only
Action = not run on SuperFoo tool
}
Marking-definition {
id=marking2
Dissemination = Share with Fight Club Only
}
Marking-definition {
id=marking3
Dissemination = Share with Tier2 communities
}
Indicator {
//applicable dissemination marking is marking3 by default
id=ind1
}
Indicator {
id=ind2
marking_refs = [marking1]
//action marking is marking 1; applicable dissemination marking is still the default marking3
}
… STIX content …
}


If this content was shared within Fight Club it would look like the above.
If it was shared outside Fight Club within Tier2 communities it would look like:



Package {
marking_refs = [marking3]
//marks content of package as shareable to Tier2 communities
Marking-definition2 {
//this could also be simply left out as there are no marking_refs present referencing this marking-definition
id=marking2
Dissemination = Share with Fight Club Only
}
Marking-definition3 {
id=marking3
Dissemination = Share with Tier2 communities
}
Indicator {
//applicable dissemination marking is marking3
id=ind1
}
Indicator {
id=ind2
marking_refs = [marking1]
//action marking is marking 1; applicable dissemination marking is still the default marking3
}
… STIX content …
}



This involves an inherent presumption that orphaned marking_refs for marking-definitions that are not present are ignored.


Does this make sense?


Can you help me understand where you see the issue with this?
Are you talking about the possibility that marking2 in the example could also be marked with a self-referential marking_ref to ensure it is not shared beyond Fight Club?
I did not do that in the example but I don’t really see a problem with that either. It is self-referential but not recursive or cyclical.


Again, maybe I am misinterpreting the point you are making. If so, I apologize and hope to get a better understanding.


sean










From: Terry MacDonald < terry@soltra.com >
Date: Thursday, February 25, 2016 at 3:57 PM
To: "Modlin, Julie K." < Julie.Modlin@jhuapl.edu >, " 'cti@lists.oasis-open.org '" < cti@lists.oasis-open.org >
Cc: "Moss, Mark B." < Mark.Moss@jhuapl.edu >, "Barnum, Sean D." < sbarnum@mitre.org >
Subject: RE: Use case for data markings








Hi Julie,
 
Will that secret marking information ever be seen by someone who is not allowed to see that marking information? What I’m wondering is whether it is redundant to apply data marking
restrictions to data marking  if the recipients will only ever see that data marking if they are already allowed to see it.
 
Additionally, which data marking format would one use to document the restriction on the data marking system? i.e. if someone was using TOP_SECRET_MARKING marking system, will they
describe the restriction of that using TLP, or using TOP_SECRET_MARKING? If it’s the later, then how would they describe the restriction of the restriction of that TOP_SECRET_MARKING? By labelling it with TOP_SECRET_MARKING?
 
As you can see I’m somewhat worried about the cyclical nature of allowing data marking to apply to data marking. I can see it has its uses (e.g. sharing restrictions on the terms of
use) but it also seems to have its problems.
 
I’d really like to know how you and others in a similar position handle this problem in current systems.
 
Cheers
 

Terry MacDonald
Senior STIX Subject Matter Expert
SOLTRA   An FS-ISAC and DTCC Company
+61 (407) 203 206
terry@soltra.com
 

 


From:
cti@lists.oasis-open.org [ mailto:cti@lists.oasis-open.org ]
On Behalf Of Modlin, Julie K.
Sent: Friday, 26 February 2016 6:59 AM
To: 'cti@lists.oasis-open.org ' < cti@lists.oasis-open.org >
Cc: Moss, Mark B. < Mark.Moss@jhuapl.edu >; Barnum, Sean D. ( sbarnum@mitre.org ) < sbarnum@mitre.org >
Subject: [cti] Use case for data markings


 
Regarding the recent question and discussion regarding data marking use cases, the ESSA Community (Federal Entities including the National Cyber Centers) has a need for a capability to indicate that
certain markings used on STIX documents are themselves sensitive. To support this in the proposed construct, there is a need for the ability to apply data markings (object_marking_refs or granular_markings) to specific marking_definitions themselves. This
is supported by making marking_definitions standard TLOs. 
 
 
Julie Modlin
Enhance Shared Situational Awareness (ESSA) Systems Engineering Team
Johns Hopkins Applied Physics Laboratory
443-778-6989 / Baltimore
240-228-6989 / Washington
 

So here is a real example that is formatted so you can read it, to help illustrate the issue I think Terry is trying to bring up.  NOTE: I left some required fields off for brevity.  In this first example, the marking-definition file is not marked... So that is pretty simple stuff. {   type : package ,   object_marking_refs : [ marking-definition--089a6ecb-cc15-43cc-9494-767639779124 ],   indicators : [     {       type : indicator ,       id : indicator--089a6ecb-cc15-43cc-9494-767639779235     }   ],   marking_definitions : [      {       type : marking-definition ,       id : marking-definition--089a6ecb-cc15-43cc-9494-767639779124 ,       spec_version : 2.0 ,       created_at : 2016-02-19T09:11:01Z ,       defintion_type : isa ,       definition : {         classification : CLASSIFIED ,         caveats : []     }   ] } Now if I want to mark the marking-definition file, it would be done like (note red text)..... {   type : package ,   object_marking_refs : [ marking-definition--089a6ecb-cc15-43cc-9494-767639779124 ],   indicators : [     {       type : indicator ,       id : indicator--089a6ecb-cc15-43cc-9494-767639779235     }   ],   marking_definitions : [      {       type : marking-definition ,       id : marking-definition--089a6ecb-cc15-43cc-9494-767639779124 ,       spec_version : 2.0 ,       created_at : 2016-02-19T09:11:01Z ,        object_marking_refs : [ marking-definition--089a6ecb-cc15-43cc-9494-767639779121 ]       defintion_type : isa ,       definition : {         classification : CLASSIFIED ,         caveats : []     }   ] } Now that UUID ...121 points to what?  And how do you share that?  If the indicator is shared but not marking-definitions UUID ...124 , then how do assert what you need to know about the indicator.  I fully get the need to mark a marking-definition , however, how is that supposed to be done?  And what will work for you?   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.   Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail

Quick other note: in that first example, you ARE marking the marking-definition, with itself. Using object_marking_refs at the package level means it applies to all objects in the package, including any information sources (identities), marking definitions,
etc.









From: < cti@lists.oasis-open.org > on behalf of "Jordan, Bret" < bret.jordan@bluecoat.com >
Date: Thursday, February 25, 2016 at 6:39 PM
To: Sean Barnum < sbarnum@mitre.org >
Cc: Terry MacDonald < terry@soltra.com >, "Modlin, Julie K." < Julie.Modlin@jhuapl.edu >, " cti@lists.oasis-open.org "
< cti@lists.oasis-open.org >, "Moss, Mark B." < Mark.Moss@jhuapl.edu >
Subject: Re: [cti] Use case for data markings





So here is a real example that is formatted so you can read it, to help illustrate the issue I think Terry is trying to bring up.  NOTE: I left some required fields off for brevity.  In this first example, the marking-definition
file is not marked... So that is pretty simple stuff.




{
  "type": "package",
  "object_marking_refs": ["marking-definition--089a6ecb-cc15-43cc-9494-767639779124"],
  "indicators": [
    {
      "type": "indicator",
      "id": "indicator--089a6ecb-cc15-43cc-9494-767639779235"
    }
  ],
  "marking_definitions": [
     {
      "type": "marking-definition",
      "id": "marking-definition--089a6ecb-cc15-43cc-9494-767639779124",
      "spec_version": "2.0",
      "created_at": "2016-02-19T09:11:01Z",
      "defintion_type": "isa",
      "definition": {
        "classification": "CLASSIFIED",
        "caveats": []
    }
  ]
}


Now if I want to mark the marking-definition file, it would be done like (note red text).....



{
  "type": "package",
  "object_marking_refs": ["marking-definition--089a6ecb-cc15-43cc-9494-767639779124"],
  "indicators": [
    {
      "type": "indicator",
      "id": "indicator--089a6ecb-cc15-43cc-9494-767639779235"
    }
  ],
  "marking_definitions": [
     {
      "type": "marking-definition",
      "id": "marking-definition--089a6ecb-cc15-43cc-9494-767639779124",
      "spec_version": "2.0",
      "created_at": "2016-02-19T09:11:01Z",
       "object_marking_refs": ["marking-definition--089a6ecb-cc15-43cc-9494-767639779121"]
      "defintion_type": "isa",
      "definition": {
        "classification": "CLASSIFIED",
        "caveats": []
    }
  ]
}



Now that UUID "...121" points to what?  And how do you share that?  If the indicator is shared but not marking-definitions UUID "...124", then how do assert what you need to know about the indicator. 


I fully get the need to mark a "marking-definition", however, how is that supposed to be done?  And what will work for you?  















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." 

>Now that UUID "...121" points to what?  


Did you intentionally leave out the “…121” marking definition?
As I said in my post, "This involves an inherent presumption that orphaned marking_refs for marking-definitions that are not present are ignored.”
This is based on the special nature of markings where any applicable markings that you have expectations will be adhered to MUST be present with the marked content. You cannot assume that consumers of the marked content will have some separate
vector to retrieve the markings.
So, for your example there is not really any ambiguity. You are referencing a marking definition that is not present and can therefore be ignored so the second snippet is equivalent to the first snippet.
If you did not leave it out intentionally then just add in whatever marking definition that “…121” is and it will apply to marking definition “…124”. Again, nothing ambiguous or cyclical about tit.


>And how do you share that? 


How do you share what? 
Marking definition “…121”? If it is not provided you cannot share it. 
The STIX package? Since it is not provided then you simply treat the package in the same way you would treat the first package without that object marking ref.


>If the indicator is shared but not marking-definitions UUID "...124", then how do assert what you need to know about the indicator. 


If the sharer feels that marking definition “…121” is something that consumers "need to know about the indicator” then it is their responsibility to make sure it is provided with the content referencing it. If it is not provided then consumers
have no ability or responsibility to honor it.


>I fully get the need to mark a "marking-definition", however, how is that supposed to be done?  And what will work for you?



I think the examples in my email clearly show how it can be done.


Again, I am not seeing the troubling scenario here. It may exist and I am not yet groking it but I do not believe that the examples here demonstrate such a scenario.


sean








From: "Jordan, Bret" < bret.jordan@bluecoat.com >
Date: Thursday, February 25, 2016 at 6:39 PM
To: "Barnum, Sean D." < sbarnum@mitre.org >
Cc: Terry MacDonald < terry@soltra.com >, "Modlin, Julie K." < Julie.Modlin@jhuapl.edu >, " cti@lists.oasis-open.org "
< cti@lists.oasis-open.org >, "Moss, Mark B." < Mark.Moss@jhuapl.edu >
Subject: Re: [cti] Use case for data markings





So here is a real example that is formatted so you can read it, to help illustrate the issue I think Terry is trying to bring up.  NOTE: I left some required fields off for brevity.  In this first example, the marking-definition
file is not marked... So that is pretty simple stuff.




{
  "type": "package",
  "object_marking_refs": ["marking-definition--089a6ecb-cc15-43cc-9494-767639779124"],
  "indicators": [
    {
      "type": "indicator",
      "id": "indicator--089a6ecb-cc15-43cc-9494-767639779235"
    }
  ],
  "marking_definitions": [
     {
      "type": "marking-definition",
      "id": "marking-definition--089a6ecb-cc15-43cc-9494-767639779124",
      "spec_version": "2.0",
      "created_at": "2016-02-19T09:11:01Z",
      "defintion_type": "isa",
      "definition": {
        "classification": "CLASSIFIED",
        "caveats": []
    }
  ]
}


Now if I want to mark the marking-definition file, it would be done like (note red text).....



{
  "type": "package",
  "object_marking_refs": ["marking-definition--089a6ecb-cc15-43cc-9494-767639779124"],
  "indicators": [
    {
      "type": "indicator",
      "id": "indicator--089a6ecb-cc15-43cc-9494-767639779235"
    }
  ],
  "marking_definitions": [
     {
      "type": "marking-definition",
      "id": "marking-definition--089a6ecb-cc15-43cc-9494-767639779124",
      "spec_version": "2.0",
      "created_at": "2016-02-19T09:11:01Z",
       "object_marking_refs": ["marking-definition--089a6ecb-cc15-43cc-9494-767639779121"]
      "defintion_type": "isa",
      "definition": {
        "classification": "CLASSIFIED",
        "caveats": []
    }
  ]
}



Now that UUID "...121" points to what?  And how do you share that?  If the indicator is shared but not marking-definitions UUID "...124", then how do assert what you need to know about the indicator. 


I fully get the need to mark a "marking-definition", however, how is that supposed to be done?  And what will work for you?  















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."