|
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
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
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."
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
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."
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)
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
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.
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.
a) use underscores || camel casing
b) all lower case || camel casing
c) spell words out || try to use abbreviated forms when possible
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:
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.
|