|
3 Points:
(1)
First off, let me begin by saying I think that John Wunder's Level 1 and Level 2 markings "hit the mark."
(2)
I'd like to foot-stomp a broad need for Level 2 markings. See use cases below.
(3) I think we are touching on the
fact that that sharing (brokering) between different sharing communities
will require processing (including re-marking/translation/config mgmt) that needs to
be ironed out (in another topic). See use cases below.
============================================
Two use cases that are basically identical:
Use Case 1: Governments useing STIX to communicate classified information amongst each other. Lets assume that they have a sharing environment that supports Unclassified and Secret sharing. Let's also assume they want to ensure that the information gets
as broadly disseminated as allowable. Example: information that is unclassified can be shared broadly. Let's posit a use case where the observable itself is unclassified but the description of how the analyst arrived at that observable is Secret. The field
level (Level 2) marking is used for description. The default (Level 1) marking is Unclassified. If we had brokering software that was going to broker this to some Unclassified sharing community, then the brokering software would need to remove the Secret
information and Level 2 Secret marking before sharing with the Unclassified sharing community. The broker bears responsibility for doing this kind of processing and re-marking.
Use Case 2: Basically the same example but applicable to the private sector. A company uses STIX to communicate internally and some of the fields, objects, etc are Proprietary. That Company has brokering software that automatically processes internal
STIX documents, removes proprietary information, and re-marks the information for automated sharing with peers.
============================================
I suggest we have broad need for Level 2 marking for automated brokering between sharing communities. I also suggest that package level marking is
a convenience that we'd want to keep, recognizing that certain sharing communities will never need object marking and/or Level 2 marking but would appreciate the simplicity of package marking. In
many cases, a broker will need to process and re-mark between communities (and
keep track of revisioning - which like Marlon says is another topic.)
Pam Smith
JHU/APL
From: cti-stix@lists.oasis-open.org <cti-stix@lists.oasis-open.org> on behalf of Jordan, Bret <bret.jordan@bluecoat.com>
Sent: Monday, December 7, 2015 7:44 PM
To: Taylor, Marlon
Cc: Aharon Chernin; Wunder, John A.; cti-stix@lists.oasis-open.org
Subject: Re: [cti-stix] Applying data markings
It seems like markings, at least L1 markings, could be treated as "labels" on data. So you send me a STIX package with a L1 marking at the package level. Inside there are 3 indicators. I consume the indicators, apply a label to each one with the L1
marking. I then throw away the package.
If I in turn send two those indicators back out, and I use an object level L1 marking to convey what was in the package level before, how is this not the same.
It seems like it is 6 of one and half a dozen of another.
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."
Since the object defaults to the marking, if any, on the Package level, then the Package level marking goes to the document.
Default marking could be a messy matter either way. What if 60% of the Package is one way and 50% is another and both MUST do conveyed in the same Package? Package level
marking will remove the work for 50% but the other 50% will have to implement overwriting object-level marking (still L1).
I see your concern with Package vs Object. I think Package level makes it easier for the transfer layer (only mentioned once, if all the same) and adds some work on
the processing level.
Revision/ID rules will need to be revisited to take reassigning marking into play, especially if you plan on granting any assurance on handling immutability. BUT THAT’S
ANOTHER THREAD!
-Marlon
I ask the group this, if your markings are at the package level, how do you reuse the objects? If you mark at the package level there is no enforcement within the object that
it’s a specific TLP. I could take that object and use it in another document and document mark that object as TLP White.
If we require markings at the object level, then you are protected by object revisioning rules, and potentially ID hashing. You could never change the TLP of the object and reuse that object
without breaking the revisioning rules or the ID hash.
I am not going to put up a huge fight here, but it just seems so obvious to me.
A few comments (on the comments…):
- Mark suggested renaming “Level 1” to “Data Markings” and “Level 2” to “Field Level Data Markings”. I initially made that change but found the language got very confusing so I switched
it back.
- Per Aharon’s comments, this proposal does have markings at the package level for both L1 and L2. This allows you to mark everything in a package as TLP:RED in a single statement (not
duplicated across each indicator). OTOH it also means that if you discard the package you would need to have some way of tracking the markings separately. IMO that’s totally fine…it’s metadata about an object so it’s not like you’re changing the object itself
if you add them to the object, and in any case per Eric’s earlier e-mail I would imagine that after ingest your tool would probably be dealing with markings in something outside of STIX anyway (I certainly would, in particular for L2).
- Aharon commented that we were getting rid of XPath and that’s an advantage of this proposal. That’s true……...kind of. Replacing XML with JSON means we use JSONPath instead of XPath, but
fundamentally it’s still a controlled structure based approach with all the implementation complexity that it brings (as Bryan Worrell can tell you).
- That said, JSON is more straightforward than XML and so I think using it will minimize the occurrence of bugs like the ones we’ve had in the past with misunderstanding XPath.
To summarize things, here’s the open questions that I can think of (beyond “is this proposal good”):
1. Should the ability to handle Level 1 markings be MTI (mandatory to implement)? (
2. Should we spend further time investigating better approaches for L2 markings (Option 3, 4, others) or just go with this (Option 5)?
3. Should we keep markings at the package level or move all markings to the individual top-level objects?
1. Not sure to be honest. Leaning towards not MTI.
2. We should use L2 as-is…it’s hard, but marking fields is hard and so IMO that’s fine. Most people will use L1 anyway.
3. Keep markings at the package level. This allows you to represent a “default” marking and override it. I also *think* (maybe I’m wrong) that certain entities in USG require package-level
markings to represent “highest-classification”, which means other gov’t may as well.
This does look like a good approach for message level markings.
Any information exchange, except for open data, is done under some explicit or implicit agreement between the parties. Various forms of such “exchange agreements” have
been around for years. For example, the “Collaborative Partner Profile Agreement” in EbXML, which came out of IBM. Having a reference to an exchange agreement provides the basis for trust between specific parties as well as an explicit representation of any
categorization and/or restrictions on any exchange under that agreement. For example, asserting that telephone numbers are personally identifiable information and that personally identifiable information shall not be stored. Markings in the “instance” document
augment the exchange agreement. It would simply not be practical or trustworthy to expect all such “markings” to be in every instance, so reference to an exchange agreement provides that level of trust and a place to put “generic” restrictions and categorizations.
I suggest exchange agreements be considered for CTI. The exchange agreement reference can be a kind of marking.
-Cory
I fully support this option as would be expected.
Kudos to John for such a great writeup explaining the idea.
All,
I developed this proposal to handle the application of data markings in STIX 2.0: https://github.com/johnwunder/data-markings.
Note: it doesn't address the format of the markings themselves (improvements to TLP, the work in FIRST, etc), just how those markings get applied to content.
I this this meets the need for simplicity for object-level markings as we’ve talked about many times while still allowing for more complicated field-level markings for those that need them.
Please review the proposal and let’s talk about feedback. If this looks good to everyone we could use it as the solution for issue #231 (currently #2 on our roadmap).
|