OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[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]