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
