Report Object Options

Option 0: Do nothing

Option 1: Accept FS-ISAC Proposal

Accept the FS-ISAC Proposal proposal and implement via a minor release.

Option 2: Accept FS-ISAC Proposal, but as Major Release

Accept the FS-ISAC proposal, but delay until the next major release. That avoids the "As Minor Release" implications of the the changes.

Option 3: Rename STIX_Package to Report in next Major Release

This would clarify the usage of STIX_Package as a "Report" (set of content w/ either explicit or implicit context) rather than simply a raw envelope without any context. It would not change any processing rules in STIX.

Note that in many ways this is the opposite of the FS-ISAC proposal even though both introduce an element called Report.

Option 4: Implement FS-ISAC proposal via a profile

Use a profile to restrict the fields that are allowed in the top-level STIX_Package.

Option 5: Add an "is_report" flag to STIX_Package as a minor release

This proposal is a modification of the original FS-ISAC proposal to get to the same (or similar) end state with less impact during the minor version period. It contains two parts: the first part is to add an "is_report" flag to STIX_Package in a minor release of STIX; the second part is to further distinguish reports from envelopes a future major release of STIX.

This change allows (or potentially requires) producers to indicate unambiguously whether they intend that the bundle of content included have some contextual grouping.

5.1 First Part (Minor Release)

For the minor release period:

• Producers would indicate whether they intend to convey a logical grouping of content (with some context) by setting @is_report appropriately. is_report="true" would be equivalent to a "Report" object, is_report="false" would be equivalent to an "Envelope" object that contains information that is not logically grouped.
• When @is_report="true" the descriptive context fields on STIX_Package (e.g., Package_Intent) would be suggested
• When @is_report="false" the descriptive context fields would be strongly discouraged or deprecated
• Both "reports" and "envelopes" could contain embedded (aka inline) content.
• The @is_report flag could be used on "Related_Packages" to convey an envelope (<STIX_Package @is_report="false" >) with included content and reports (which have @is_report="true").

This approach maintains the explicit distinction between envelopes and reports in the original FS-ISAC proposal and introduces the explicit word "report" into the schema but (in our analysis) would likely cause less disruption to users.

5.2 Second Part (Major Release)

In a future major release, this would merge towards the original FS-ISAC proposal:

• STIX_Package would become a raw envelope and would never convey context. This is equivalent to the original FS-ISAC proposal
• A new Report Object would be added per the FS-ISAC proposal. At that time the community could evaluate whether this Report could contain embedded content (making simple reports more compact) or would be equivalent to the FS-ISAC proposal and only allow references. That decision could be made during the major release cycle to allow tool authors, content creators, and users to get experience with the processing model.

Option n

We're always open to other suggestions. Does anyone else have any thoughts on how to implement this capability with a minimum of disruption?