We do not need to hold it hostage... I want to see this move forward as fast as possible. I am excited to see John's changes that he will implement early next week. Once that is done, and people have time to review it we can sign off on it.. I would also like to see some implementations done before we finalize the specification or write the data-markings in stone just to make sure they can be easily codified. John mentioned that the layer2 stuff is painful to implement in code right now. If we can get a few other people playing with it, we may discover a slightly easier way of doing layer2. I have very little worry about layer1 markings. That is pretty simple and easy. 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 Dec 4, 2015, at 17:01, Struse, Richard <
Richard.Struse@HQ.DHS.GOV > wrote: That’s fine in principle but we’re not going to hold this proposal hostage for that. I’m interested in hearing from others in the SC as to their views on this important capability. As we all know, trust is a crucial element in effective cyber threat intelligence sharing and having the ability to clearly specify markings is a key component of that equation. Not that the presence of markings magically protects the underlying data from abuse, but it can help make it very clear when someone is violating the rules. From:
cti-stix@lists.oasis-open.org [ mailto:
cti-stix@lists.oasis-open.org ] On Behalf Of Jordan, Bret Sent: Friday, December 04, 2015 5:43 PM To: Wunder, John A. Cc:
cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Applying data markings Ideally, I would like to see this turned in to formal proposal, and yes we can give people 1-2 weeks to review it. But I would also like to see three independent implementations in different programming languages before we vote on accepting it. We need to make sure things like this not only look good on paper but can easily hold water in code. Bret Sent from my Commodore 64 On Dec 4, 2015, at 1:28 PM, Wunder, John A. <
jwunder@mitre.org > wrote: Unfortunately I’m not going to have time to update it today but should be able to get to it on Monday. After that IMO for such a major topic we should give people a week or so to digest it (maybe even try to solicit another reference implementation?) before calling it good. John On Dec 4, 2015, at 1:32 PM, Jordan, Bret <
bret.jordan@BLUECOAT.COM > wrote: Yes. I would like to see an updated version of this document later today, based on the things we have talked about and heard from Mark and Rich. I would then like to see if we can get a motion to approve this. 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 Dec 4, 2015, at 11:23, Wunder, John A. <
jwunder@mitre.org > wrote: I had a quick chat with Bret and he gave me some good feedback on the writeup and clarifying a few things but it sounds like he’s mostly in agreement. To Mark (and Bret’s) comments: - Initially I was concerned about data markings (level 1) being MTI but I’m starting to come around based on Rich, Mark, and Bret supporting it. What does everyone else think? - I see where you’re heading with “Data Markings” and “Field Level Data Markings” and I’ll give it a shot. The main reason I liked “level 1” and “level 2” was to avoid ambiguity but if “data markings” are MTI and “field level data markings” are optional I don’t think that’s an issue. John On Dec 4, 2015, at 12:13 PM, Jordan, Bret <
bret.jordan@BLUECOAT.COM > wrote: I too like the idea of calling them Data Markings and Field Level Data Markings and like the idea of having Data Markings be a MTI. I also agree with Jason, that there is no way to know if someone will actually listen to, or do something with the markings. 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 Dec 4, 2015, at 05:41, Mark Davidson <
mdavidson@soltra.com > wrote: 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. Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail