RE: [Non-DoD Source] Re: [cti-stix] Object Markings - Ballot Take 2

["Mates, Jeffrey CIV DC3/DCCI" <Jeffrey.Mates@dc3.mil>]

I just wanted to point out that in some cases changing an objects classification should (or may) result in the originals revocation and the creation of a new object.  The primary use case for this is if an object was issued at a classification that was too low and then corrected to a higher classification.

Sending out an update might not be possible as some recipients might not be allowed to receive the version with the higher marking.  So the only safe way to do it would be to create a whole new object thus ensuring everyone could receive the notice that the previous object was invalid, but not necessarily why.  I know this is an edge case, but something to consider.

Jeffrey Mates, Civ DC3/DCCI
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computer Scientist
Defense Cyber Crime Institute
jeffrey.mates@dc3.mil
410-694-4335

-----Original Message-----
From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Terry MacDonald
Sent: Wednesday, July 13, 2016 6:47 PM
To: Allan Thomson
Cc: cti-stix@lists.oasis-open.org; John A. Wunder; Dave Cridland
Subject: [Non-DoD Source] Re: [cti-stix] Object Markings - Ballot Take 2

I agree. Any modification to the contents of a published object (including data marking) should result in an increase in version.

Cheers
Terry MacDonald 
Cosive 

On 13/07/2016 4:12 AM, "Allan Thomson" <athomson@lookingglasscyber.com> wrote:


	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 <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 <tel:%2B448454681066> 

	email  dave.cridland@surevine.com

	skype  dave.cridland.surevine

	mage removed by sender. 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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature