OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti] Use case for data markings


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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]