[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Re: [cti-users] "Data Marking" syntaxes
Terry, I think it would be great if we could find a way for the CTI TC and the FIRST IEPF SIG to work together on this. One question- is the goal of IEPF to have machine-readable policy expressions? I’m assuming so but wanted to confirm.
From: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On Behalf Of Terry MacDonald Pamela, That is very, very close to the work currently being performed by the FIRST Information Exchange Policy Format SIG. They are shortly to roll out a ‘strawman’ outlining their initial draft suggestion for this, but I am embargoed from discussing it further until the announcement comes out. The FIRST SIG are planning on inviting the OASIS CTI to work with us (and other interested groups) to develop a policy that will enable producers to accurately describe to consumers what is expected of them. From what I’ve seen the IEPF standard is extremely simple and logical. I can also say that the structure is so very close to what you’ve described but with some extra enhancements. Hopefully you’d be up for contributing to the FIRST IEPF SIG stakeholder discussion when it begins? Cheers Terry MacDonald Senior STIX Subject Matter Expert SOLTRA | An FS-ISAC and DTCC Company +61 (407) 203 206 | terry@soltra.com From: cti-users@lists.oasis-open.org [mailto:cti-users@lists.oasis-open.org] On Behalf Of John Anderson Thank you, Pamela. This is one of the clearest presentations of this topic I've seen yet. As a relative new-comer to CTI, I wish I'd found this on Day One. (Could this be incorporated in the documentation somewhere?) As I read through the various combinations, this reminded me of the Creative Commons approach to licensing. I wonder if something similar would work for our community? Maybe there would be some edge cases, but could most popular variations be easily expressed through something like this? http://creativecommons.org/choose/ JSA From: cti-users@lists.oasis-open.org <cti-users@lists.oasis-open.org> on behalf of Smith, Pamela A. <Pam.Smith@jhuapl.edu> Hi All, I wanted to take a step back from discussing modifications to TLP and rather discuss how we could mark data if we started from scratch. We’ve previously talked about 3 categories of restrictions: sharing, handling, and allowed actions: SHARING: Sharing restrictions specify who you’re allowed to further share content to, generally based on characteristics of the consumers. For example, you can share content with anyone in your ISAC/ISAO but not beyond that, or you can share further to the US government (USG) but only if you anonymize the producer information, or you can share further but no anonymous access is permitted (e.g. you can’t post it for the world to see). HANDLING: Handling restrictions specify how you have to treat content while you have it. We can either mark the content with a label and trust that the consumer knows how to handle it and/or we can list the explicit requirements associated with the label (PII, PCII, Safe Harbor, etc) are spelled out. Example: PII data, PCI data, or Safe Harbor data must be handled in certain ways (stored only in certain countries, encrypted at rest, deleted after one year, etc). ALLOWED ACTIONS: Allowed actions define what you can actually do with the data. For example, you might want to say that consumers can use it for their own network defense but can’t incorporate it into derivative works or resell it. Assuming the community agrees that it’s important to restrict sharing, handling, and access along these lines we can define a marking structure that permits us to specify a default as well as a set overrides to those defaults. Examples: You (the consumer or the entity I’m sharing with) can share with everyone and all actions are permitted: · Policy (further-sharing-default=permit, allowed-action-default=permit) You can share with your ISAO and USG, but if you share with USG you have to strip source information. Any actions are permitted: · Policy (further-sharing-default=deny, allowed-action-default=permit) o Over-ride on further-sharing-default § Target = USG § Permission = Permit § Caveats = AnonymizeSourceIdenity o Over-ride on further-sharing-default § Target = MyISAO § Permission = Permit § Caveats = None You can share with anyone you’d like to share with but you can’t post it on an openly accessible web site (no anonymous access is permitted). Any actions are permitted: · Policy (further-sharing-default=deny, allowed-action-default=permit) o Over-ride on further-sharing-default § Target = All § Permission = Permit § Caveats = NoAnonymousAccess You can share with anyone, but neither you nor they can repackage it (claim it as their own for profit): · Policy (further-sharing-default = permit, allowed-action-default = permit) o Over-ride on allowed-action-default § Target = All § Category = Repackage § Permission = Deny |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]