I would be concerned that having more specific TLP definitions than the current FIRST.org/tlp definitions would actually dilute meaningfulness of the additional caveats and confuse adopters. A TLP fork is what everybody was hollering about after the publication of the FIRST TLP last year, and I would advise against potentially rejuvenating those debates.
From: iep-sig-request@lists.first.
org [mailto:iep-sig-request@lists.first.org ] On Behalf Of Patrick Maroney via iep-sig
Sent: 16 May, 2017 20:31
To: Terry MacDonald <terry.macdonald@cosive.com>
Cc: CTI TC Discussion List <cti@lists.oasis-open.org>; iep-sig@first.org
Subject: Re: [iep-sig] [cti] STIX 2.1 Proposal: IEP v2.0
Terry,
Thank you very much for driving this discourse. While I do not want to weigh in on the technical details of one approach over another, I do want to weigh in on the political/legal/policy based impediments to adoption. You have characterized these well in your narrative.
We have had much discourse and extended effort focused on reducing technical impediments to adoption (I.e., JSON vs. XML). It is time to address the greatest impediments to adoption.
The bottom line is: if we cannot have confidence that our marking/handling constraints will at least be unambiguously understood, we will not share the intelligence. To paraphrase Dr. Burger: 'our marking language must be "butt simple". A globally adopted marking language is the only answer.
I believe the IEP initiative represents our best opportunity to address this critical aspect of a global, real-time CTI Interexchange ecosystem.
Patrick MaroneyPrincipal Engineer - Data Science & Analytics
(609)841-5104
On May 16, 2017, at 6:10 PM, Terry MacDonald <terry.macdonald@cosive.com> wrote:Hi All,
After the feedback I've received so far, I went through our proposal again and refactored it to split the IEP Data Marking object into two. Doing this simplifies the structure of the IEP data Marking objects, flattening it much more, and makes it very plain which version of the IEP you are using (embedded or referenced).
I've attached the revised proposal to this email. Please tell me what you think!
Cheers
Terry MacDonald | Chief Product Officer
On Wed, May 17, 2017 at 9:22 AM, Terry MacDonald <terry.macdonald@cosive.com> wrote:
Hi All,
To clarify the intent of this object a little.... it's a type of container designed to house the IEP JSON content. There is a delineation of where the STIX ends and the IEP JSON format begins. Using an example IEP (that has been changed slightly) as a reference, and using this colour to indicate IEP and this colour to indicate STIX, we get the following:
{
"type": "marking-definition",
"id": "marking-definition--34098fce-
860f-48ae-8e50-ebd3cc5e41da", "created": "2016-08-01T00:00:00Z",
"modified": "2016-08-01T00:00:00Z",
"definition_type": "iep",
"definition": {
"id": "01bc4353-4829-4d55-8d52-
0ab7e0790df9", "name": "FIRST IEP-SIG TLP-AMBER",
"version": 2.0
"start_date": "2017-01-01T00:00:00Z",
"end_date": null,
"encrypt_in_transit": "may",
"encrypt_at_rest": "may",
"permitted_actions": "externally-visible-direct-
actions", "affected_party_notifications"
: "may", "tlp": "amber",
"attribution": "must-not",
"obfuscate_affected_parties": "may",
"unmodified_resale": "must-not",
"external_reference": " https://www.first.org/about/
policies/bylaws "}
}
The same for the IEP reference:
{
"type": "marking-definition",
"id": "marking-definition--34098fce-
860f-48ae-8e50-ebd3cc5e41da", "created": "2016-08-01T00:00:00Z",
"modified": "2016-08-01T00:00:00Z",
"definition_type": "iep_reference",
"definition": {
"id_ref": "9891b2be-aa5a-4cb2-8a87-
b3af93744d85", "version": 2.0
}
}
With this in mind I'll answer the questions that have been asked so far (and please keep them coming).
In the IEP Reference container, I think you need to use the STIX Hashes type, like what we did with External References. This way you know that the think you are linking to has not changed.
The IEP reference can only ever reference a single IEP policy in a IEP Policy File. There will be a one-to-one relationship between the IEP policy within the .iepj file, and the data marking object created by the producer within STIX. I expect that each Producer will create a an IEP Data marking object for content that they produce, that they then use to mark all their data the same way. Our goal is to provide standard JSON IEP Policy Files (.iepj) that any content producer can use, so that eventually most producers and vendors use the same standard IEP policies to describe things... kind of like how people use TLP, but with IEP extending that functionality to describe Handling, Actions, Sharing and Licensing.
a) the marking definition object examples in Section 9.1.7 still have version in the JSON. That field is no longer in STIX 2.0. Suggest removing that attribute from the examples.
Thanks for that catch, I've updated the examples above, and will do so in my proposal PDF too.
b) STIX uses created/modified/deleted as timestamp fields. The IEP JSON schema appears to use “start_date” and “end_date”. Any reason why this could not be consistent with STIX naming and use “start” and “end” without the _date in the name?
IEP policies are immutable. There is no way to update them. New policies are the only way to make changes. Any STIX objects that need to be updated would have an updated IEP Data Marking object released that would point to the new IEP policy (or contain it embedded).
c) The id in the IEP policy object does not have a type-name in it like other STIX objects would. Why not? Would we not want the ids to be created using the same id creation policy as STIX?
The id is within the IEP part of the object. It is part of the IEP. Any parsing engine needs to be able to understand IEP in order to process it, so it will be fine to leave the id as is. IEP is designed to work with any other information sharing protocol, not just STIX, so we needed to keep things as agnostic as possible.
d) The version field represents what version? IEP? For ease of integration it might be best if we name that field “iep_version” to avoid other uses of the common name ‘version’
Hopefully it's clearer now that the version is the IEP version. We are on version 2.0 of IEP. Again, this is the IEP policy part of the object, and reflects the formatting of the JSON object.
----
As a slight aside, I think its important to note that STIX will be having many more of these instances over time of where STIX encapsulates another JSON based protocol. We cannot expect the 'foreign' protocol encapsulated to change it's structure to conform to STIX standards, as it's not STIX. As long as it is JSON compliant that should really be enough.
Cheers
Terry MacDonald | Chief Product Officer
Cheers
Terry MacDonald | Chief Product Officer
On Tue, May 16, 2017 at 11:07 AM, Allan Thomson <athomson@lookingglasscyber.
com > wrote:Hi Terry – Some minor tweaks.
a) the marking definition object examples in Section 9.1.7 still have version in the JSON. That field is no longer in STIX 2.0. Suggest removing that attribute from the examples.
b) STIX uses created/modified/deleted as timestamp fields. The IEP JSON schema appears to use “start_date” and “end_date”. Any reason why this could not be consistent with STIX naming and use “start” and “end” without the _date in the name?
c) The id in the IEP policy object does not have a type-name in it like other STIX objects would. Why not? Would we not want the ids to be created using the same id creation policy as STIX?
d) The version field represents what version? IEP? For ease of integration it might be best if we name that field “iep_version” to avoid other uses of the common name ‘version’
allan
From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of Terry MacDonald <terry.macdonald@cosive.com>
Date: Monday, May 15, 2017 at 1:22 PM
To: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org >, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] STIX 2.1 Proposal: IEP v2.0
Hi All,
I'd like to propose that we add an IEP Data Marking object to STIX 2.1 to allow object creators the option of marking their data using IEP v2.0. More information about the proposal is in the STIX2.1Proposal-
InformationExchangePolicyMarki ngType.pdf. I've also included background information about the IEP Framework, and the IEP JSON Specification if you're interested. There two documents have been updated based on feedback from CTI members to better align IEP with STIX.
The FIRST Information Exchange Policy (IEP) Framework enables threat intelligence providers to inform recipients of how they may use the threat intelligence they receive. IEP ensures that both parties are aware of any restrictions on the use of the shared threat intelligence, and reduces the likelihood of misunderstandings.
Think of it as TLP that also describes Handling, Action, Sharing and Licensing restrictions. In other words it answers "What am I allowed to do with this intel?"
The real power of IEP is in the ability for content producers to reference the same IEP policy. IEP allows communities to create and reference one or more shared IEP policies that members can choose from and reference. The FIRST IEP-SIG will be creating and hosting some common IEP policies that anyone will be free to use, in the interest of making threat intelligence sharing easier.
Cheers
Terry MacDonald | Chief Product Officer
<image001.png>
<STIX2.1Proposal-
InformationExchangePolicyMarki ngObjectTypeupdated20170517. pdf>
------------------------------------------------------------ ---------
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
