[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] Applying data markings
Dear Richard, "Resistance to False Input" is a critical capability. It is evaluated (not in details) for 3 Contexts/Designs in Table 4.1: Summary of Sharing Scheme Performance, Page 75 of the attached document. @All: please kindly note that I am not sharing this document just for the resolution of a very small piece of the global equation... PS: @Richard and others who would listen: imho, we are wasting a significant amount of time ($) dealing with very small tactical elements with people that don't have a strategic vision of "our thing". But Security can't wait. Best regards 2015-12-05 3:01 GMT+03:00 Struse, Richard <Richard.Struse@hq.dhs.gov>: > 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:
Scalable_Security-Cyber_Threat_Information_Sharing_in_the_Internet_Age.pdf
Description: Adobe PDF document
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]