Re: [cti-stix] Applying data markings

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

"* When this gets worked into the spec, I'd prefer to avoid making Data Markings a dimension for negotiating interoperability. Said another way, I don't want two otherwise compatible STIX implementations to be incompatible because they support different levels of Data Markings."

For sure, there is no way data marking support should be included in an interoperability negotiation, because you have no way to even know if the "support" being asserted is adequate for your use of marking anyway.

Data makings in protocols of all types have a classic problem where you actually have no idea if the recipient is respecting or even doing anything with them at all, and even if they are, they may not be doing what the producer actually intended. Fixing this isn't really something you can accomplish as part of a protocol standards body either, because the only way it could be checked and enforced is via a software auditing process (which the CTI could come up with but it would be a separate work product than the protocol standard).

Really, aside from the aforementioned auditing possibilities, data markings are only useful within a given trust group because you have to have trust that the other systems are in fact respecting the markings you apply and processing them in the way you intend.


-
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


Mark Davidson ---12/04/2015 08:41:51 AM---A few comments from me: * Overall, I like the design and I think it is in the right ballpark. I have

From: Mark Davidson <mdavidson@soltra.com>
To: "Jordan, Bret" <bret.jordan@bluecoat.com>, "Struse, Richard" <Richard.Struse@HQ.DHS.GOV>
Cc: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 12/04/2015 08:41 AM
Subject: Re: [cti-stix] Applying data markings
Sent by: <cti-stix@lists.oasis-open.org>

---

A few comments from me:

* Overall, I like the design and I think it is in the right ballpark. I have some comments (below), but overall I'd be on board with using this as our foundation for STIX 2.0 data markings and moving on to other topics, as long as we recognize that things might change as a result of prototyping and other decisions (but hopefully not too much!)

* I really like "override markings of the same type" and I consider this a key benefit of the proposal. We've had conversations about the 'more restrictive' marking applying, but there's no guarantee that markings can be objectively identified as more or less restrictive. This is a very straightforward way of determining which marking(s) apply.

* I'd like some clarity on what it means to process a data marking, but that can be sorted out later when this gets worked into a specification.

* I don't like the two modes of marking - Level 1 has markings as a property of the marked object, and Level 2 has the marked object as a property of the marking. That said, I recognize this may be a necessity that can't be worked around, especially if we desire the ability to mark information whose representation is under our control (in STIX 1.x, CIQ, OVAL, et al would fall under this category - in STIX 2.0 I'm not clear which items are in this category).

* When this gets worked into the spec, I'd prefer to avoid making Data Markings a dimension for negotiating interoperability. Said another way, I don't want two otherwise compatible STIX implementations to be incompatible because they support different levels of Data Markings. I'm not sure we'll ever get to the point where you can just plug together two products that say "STIX" on the label, but IMO we should move as far in that direction as possible. Rich's idea of MTI/optional looks like it would accomplish my goal.

* This is a personal preference: Level 1 Markings and Level 2 Markings could instead be called "Data Markings" and "Field Level Data Markings". IMO this would make it more clear to a reader what each thing is, and make it clear that Level 2 is effectively an extension of Level 1. Then the conformance clause could read like "Data Markings MUST be implemented. Field Level Data Markings MAY be implemented" or some such. That said, this is personal preference and my opinion on the design is not contingent on this comment being accepted.

TBH, most of my questions/comments can probably be captured as "open questions" in the proposal's wiki page. John, I'm happy to make those edits myself if you'd like (Let me know offline or in slack; no need to reply on-list for that).

Thank you.
-Mark

P.S. - I like the idea of establishing a naming convention, can we add that topic to the discussion queue?

P.P.S. - Right now STIX and TAXII are capturing rough consensus decisions differently. STIX is using the GitHub issue trackers and TAXII is using TAXIIProject.github.io. In hopes of not spawning another discussion thread, I'll raise this in the slack channel and see if we can reach a unification proposal to bring back to the list. (Note: Let me know if you want a slack invite)

---

From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Jordan, Bret <bret.jordan@bluecoat.com>
Sent: Friday, December 4, 2015 12:03 AM
To: Struse, Richard
Cc: Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings 
 
I should rephrase as my statement was not clear, I am not sold yet on the way layer 2 markings are being proposed.  But that could mean I just do yet fully understand John's vision for them.  I am going to try and schedule a call with John tomorrow to walk through it.  

Bret 

Sent from my Commodore 64

On Dec 3, 2015, at 8:22 PM, Struse, Richard <Richard.Struse@HQ.DHS.GOV> wrote:

For some context, there are significant users of STIX, especially within the public sector, that require finer-grained marking than what Level 1 markings provide. The whole point of having two levels of marking defined is to allow implementations that are not concerned with that finer-grained capability to implement just Level 1 markings. My guess is that support for Level 1 would be MTI with support for Level 2 (in addition to Level 1 of course) being optional.

From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Jordan, Bret
Sent: Thursday, December 03, 2015 8:46 PM
To: Wunder, John A.
Cc: cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings

So I really like what you have done for Level 1 markings, and I can get behind that. A few nits/comments though:

1) you have defined marking_definitions and marking_refs. I am guessing you are using an abbreviated form of references because of the legacy "idref" field. I would prefer that we adopt a general style guide for the field names.

Options to be discussed:
a) use underscores || camel casing
b) all lower case || camel casing
c) spell words out || try to use abbreviated forms when possible

My preferences:
I prefer underscores even though the JSON uses camel casing
I personally prefer all lower case
I would prefer abbreviations when possible. So marking_defs and marking_refs (this might be hotly debated by this group)


2) EclecticIQ published a great style guide for JSON STIX when they did theirs. One thing that I did not like at first, but came to love in code was their use of a "type" field. For example:

{
"type": "six_package",
"indicators": [
{
"type": "indicator",
"id": "indicator-1234"
}
]
}

It might be good to do this in your marking objects as well. Something like "type": "marking" or something. Please the attached PDF of their email to the STIX list from long ago.


3) Can you give some examples of a Level 2 marking structure that is valid? I am still not sold on the Level 2, but am willing to work with you, so you can enlighten me.