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


I agree... I like it when optionality is reduced and there is one simple and easy way of doing things.  This will prevent bad behavior, or at least make the bad behavior more apparent..  This is also why I am advocate of creating some unit-tests that we can use to verify implementations.  


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 8, 2015, at 15:23, Aharon Chernin <achernin@soltra.com> wrote:

I do run into STIX objects that have been modified, but the GUIDS and/or timestamps remained the same. To Aharon, this is less about TLP enforcement and more about forcing people to use STIX correctly. To “other people”, it could be about ensuring the the TLP remains the same. I don’t think that authors purposely do things wrong, but authors (or the tools they create), can do things incorrectly.  All in all, I love forcing authors to do the right thing. It reduces “optionality”.

Aharon

From: "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Tuesday, December 8, 2015 at 5:09 PM
To: Aharon <achernin@soltra.com>
Cc: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Applying data markings

Is this a problem that we can not really solve?  I mean if someone is not going to abide by the data-marking rules and fall out of alignment with the legal framework that is in place between them and who ever they got the data from, then why not just pull the IPs or Hashes or Filenames out and just craft an entirely new object?    Why just change the TLP marking?  Why not just craft an entirely new object?


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 8, 2015, at 12:07, Aharon Chernin <achernin@soltra.com> wrote:

Jason, I agree. If we as a group decide to do hash based ids, then we can enforce that the object has not been revisioned (without following revision rules) and that the TLP has not been “altered”. 

Hash based Ids have not been worked through as a community at this time. 

Aharon

From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Tuesday, December 8, 2015 at 1:44 PM
To: Aharon <achernin@soltra.com>
Cc: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject: Re: [cti-stix] Applying data markings

" 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.

This would work if and only if IDs are mandated to always be derrived based on hashing all of it's content, including any and all makings.

Is that something that was decided?


-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


<graycol.gif>Aharon Chernin ---12/07/2015 05:26:45 PM---I ask the group this, if your markings are at the package level, how do you reuse the objects? If yo

From: Aharon Chernin <achernin@soltra.com>
To: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 12/07/2015 05:26 PM
Subject: Re: [cti-stix] Applying data markings
Sent by: <cti-stix@lists.oasis-open.org>





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.

Aharon

From: <cti-stix@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date:
Monday, December 7, 2015 at 3:42 PM
To:
"cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Subject:
Re: [cti-stix] Applying data markings

All,

I updated the proposal based on the comments from last week: https://github.com/johnwunder/data-markings.

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?

My answers:

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.

John
      On Dec 7, 2015, at 10:43 AM, Cory Casanave <cory-c@modeldriven.com> wrote:

      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

      From:cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org] On Behalf Of Barnum, Sean D.
      Sent:
      Monday, December 07, 2015 9:49 AM
      To:
      Wunder, John A.; cti-stix@lists.oasis-open.org
      Subject:
      Re: [cti-stix] Applying data markings

      I fully support this option as would be expected.
      Kudos to John for such a great writeup explaining the idea.

      sean

      From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org>
      Date:
      Thursday, December 3, 2015 at 3:11 PM
      To:
      "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
      Subject:
      [cti-stix] Applying data markings

      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).

      John


<graycol.gif>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]