Not from my perspective.
I think it should cause a version change and we should make that clear in the normative text.
Allan
From:
Dave Cridland <
dave.cridland@surevine.com>
Date: Tuesday, July 12, 2016 at 8:37 AM
To: Allan Thomson <
athomson@lookingglasscyber.com>
Cc: "Wunder, John" <
jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <
cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Object Markings - Ballot Take 2
In most environments, any change to a security label is an exceptional event, so changing the version is a certainty there. In addition, if the version doesn't change, it's further increasing the chances of a TOCTOU where the marking data
is used for access control.
So in my world, it's a definite yes - but I'm curious as to whether there's a particular driver for doing the opposite?
Dave.
On 12 July 2016 at 14:46, Allan Thomson <
athomson@lookingglasscyber.com > wrote:
John – thanks for the reminder.
I have a question on versioning.
Will a change to an object’s markings require a change to the version of the object itself?
So in the example below you have an indicator and it has a marking for that indicator. Say its TLP-red. If the indicator marking is changed at some
point in the future is changed to TLP-Green. Does that mean the producer changes the indicator version as well as the marking?
I * think * it should change the version of the indicator but not sure our normative text states one way or the other. If the consensus is to
not change the version with object marking change then we should make that clear too.
allan
From:
"
cti-stix@lists.oasis-open.org " <
cti-stix@lists.oasis-open.org > on behalf of "Wunder,
John" <
jwunder@mitre.org >
Date: Tuesday, July 12, 2016 at 6:41 AM
To: "
cti-stix@lists.oasis-open.org " <
cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Object Markings - Ballot Take 2
All,
I haven’t seen any further comments on the Object Markings text since the update to address the ballot comments, so I’ve copied it into the main document
here:
https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#heading=h.bnienmcktc0n Since it seems like most (though not all) of the disagreements are resolved,
I move that the TC open a ballot to mark the Object-Level Markings section in the STIX 2.0-Core document as Consensus.
Complete text of that section is below.
John
---
?6.2.? Object-Level Markings
Status:
Review
MVP :
Yes
Data markings provide the ability to mark data in STIX, typically to represent restrictions and permissions for how
that data can be used and shared. For example, data may be shared with the restriction that it not be re-shared, or that it must be encrypted at rest. Object-level data markings define how markings are applied to TLOs.
Object-level markings are contained in the
object_marking_refs field, which is an optional list of ID references (of type
identifier ) that resolve to objects of type
marking-definition . The markings referenced by the
object_marking_refs field and defined in the
marking-definition object apply to that TLO and all of its fields.
?6.2.1.? Precedence
Some types of marking definitions have rules about precedence. If the marking definition defines these rules, markings
appearing earlier in the list have precedence over those appearing later. For example, a TLP marking appearing as the first element in the list has precedence over a TLP marking appearing as the second element.
?6.2.3.? Examples
This example marks the indicator with the marking definition referenced by the ID.
{
"type": "indicator",
"id": "indicator--089a6ecb-cc15-43cc-9494-767639779235",
...
"object_marking_refs": ["marking-definition--089a6ecb-cc15-43cc-9494-767639779123"],
...
}
John
--
Dave Cridland
phone +448454681066
email
dave.cridland@surevine.com skype dave.cridland.surevine
Participate Collaborate Innovate
Surevine Limited, registered in England and Wales with number 06726289. Mailing Address : PO Box 1136, Guildford GU1 9ND
If you think you have received this message in error, please notify us.