STIX 2.x documentation is available here. This site contains archived STIX 1.x documentation. STIX is now maintained by the OASIS CTI TC.
Plain Wrapper Around Multiple Reports
Although not always considered as important as the content itself, the packaging of cyber threat intelligence can often be very important. A basic title, intent, and description of the data is of course important, but other metadata can include data handling instructions, information about the source of the data, and information about how the data was generated. This idiom describes representing a bundle of content coming from one source but containing several unrelated reports.
Scenario
In this scenario, two unrelated threat reports are distributed by a government sharing program via a single document at the same time. This was considered easier from an operational perspective than just distributing them separately, but other than that they are not related at all. The first report is a high-level report on an adversary’s campaign against a particular industry sector while the second is a set of indicators for a piece of malware.
Data model
STIX_Package vs. Report
Note: This guide is only applicable to STIX 1.2. In previous versions of STIX, the STIX_Package construct was used both as a wrapper for unrelated content and to denote related content as a report.
STIX_Package is simply a way to wrap up STIX content so that it can be transferred in the same document, marked in the same way, compliant with the same profile, and/or given the same Information_Source. It in no way implies that the content is related in any way (other than the fact that you got it from the source in the same package). Report, on the other hand, is not used to transfer content but is specifically meant to give shared context to a set of STIX content that is related in some way. Remember: use STIX_Package to transfer all content and then use Report as necessary to group it contextually.
For example, the following types of content would probably have reports:
A whitepaper on how a threat actor uses a piece of malware
A description of evolving attack patterns used to deliver malware
A set of indicators relevant to one particular campaign with some extra context on why they’re relevant to the consumer
The following types of content would probably not have reports:
A simple IP watchlist where the IPs are unrelated (other than all being malicious)
A group of related STIX content without any extra context beyond that captured in the relationships
A set of indicators relevant to one particular campaign without any context as to why they’re all relevant to the consumer
Put simply: if you have something to say about the set of content that cannot be expressed in the content itself (expressing in content via relationships and in-place titles/descriptions is always preferred) then you should use one or more reports.
This example describes how to distribute multiple reports as part of a scheduled release of STIX content. For example, many sharing programs have a daily or weekly release of all of their reports. Each report is self-contained, but all are released by the same organization at the same time. The data model, as you would expect, contains a single STIX_Package, a set of content included in both reports, and the two reports.
In order to focus on the important parts of this idiom the content itself is limited to just a notional campaign and TTP. In practice you would of course have much more content for each of these reports.
Using the STIX_Package wrapper
The outer wrapper serves several purposes:
It allows all content to be conveyed in a single document by serving as the “root”
It allows you to apply data markings and/or information source across all content in the document (for example, TLP or copyright) rather than having to do it individually.
It allows you to express which profile(s) the content conforms to via the Profiles element.
As explained above, this wrapper is conveyed via a STIX_Package with a STIX_Header. In this case we simply represent a common information source for all material contained in the package.
Each report is represented as a Report element inside the outer level STIX_Package in the same way that the content it refers to. Like packages, reports consist of a header and then a set of content included in the report. Unlike package, however, reports are expected to reference content defined externally rather than directly embed it. This goes back to the purpose of the constructs: packages are about conveying content (and therefore embed it), while reports are about relating content with some shared context (and therefore reference it). While reports do allow you to embed content directly, the suggested practice is that you simply reference it.
In this case, we’ll follow the suggested practice and reference content included parent package. The two reports are given separate package intents, titles, and descriptions and include references to the content included within them. The information source is inherited from the package and does not need to be re-stated in the individual reports.