Proposal: Move Indicator Campaign relationships from Campaign construct to Indicator construct

Status: Open
Comment Period Closes: TBD
Affects Backwards Compatibility: Yes
Relevant Issue: https://github.com/STIXProject/schemas/issues/55

Background Information

This proposal concerns the ability to characterize relationships between Indicators and Campaigns in a simpler, more consistent, more ontologically coherent and more practical manner. The use of the current approach is considered a bug that needs resolving as soon as possible.

In STIX 1.0, relationships between Indicators and Campaigns are asserted with the Related_Indicators element of the Campaign construct. There are several downsides to this approach:

• From an ontology perspective it does not really make sense for related Indicators to be a part of Campaigns as Campaigns are a meta construct tying together various Incidents and/or TTP with some believed attribution and intent. Indicators may indicate TTP behaviors used within a Campaign but they are not really part of the Campaign itself
• If one wishes to specify an Indicator and give a simple name label to refer to believed related activity before details are known, they would have to create a separate Campaign construct with just a Name given and Related_Indicator and then pass along both the Campaign (mostly empty) and Indicator contstructs.
• A very common use case would be to specify one or more Indicators related to a Campaign, share these and then over time specify and share more Indicators as more is learned. In this use case, the complete Campaign instance would need to be updated and resent with each new Indicator even though its core content had not changed.
• If a given Campaign was known by multiple different names to different parties (a common occurrence), the current approach would require separate Campaign entries for each name with Related_Indicators defined within each Campaign instance to the set of related Indicators.
• If a single Indicator was applicable to several different Campaigns, the current approach would not give an easy way to discover this without scanning across all known Campaigns.

Based on their predominant use cases, numerous stakeholders in the STIX community have asked for a simple way to add Campaign relationships to Indicators rather than the other way around.

Proposal

Create a new CampaignReferencesType that can contain one or more Campaign_Reference elements each of which can contain:

• 0 or 1 campaign_ref attribute (a STIX ID reference to a separately defined Campaign)
• 0 or 1 Campaign_Names element containing 1 to many Campaign_Name elements each of which may be a string name for a campaign label
• 0 or 1 Confidence elements that is of the STIX ConfidenceType (enabling characterization of the confidence in the assertion that the referenced Campaign (whether by campaign_ref or Campaign_Name) is actually associated with the object containing the Campaign_References element). Using this approach you could easily do the following things:
• Add a simple campaign appellation to an Indicator where a separate Campaign construct for that campaign may not exist (e.g. <Campaign_Name>Disco Foo</Campaign_Name>)
• Add a reference to a separately defined Campaign construct using the campaign_ref attribute (e.g. campaign_ref="example:campaign-1e2c4237-d469-4144-9c0b-9e5c0c513c49")
• Add a set of simple campaign appellations to an Indicator where a given campaign may be known by several names (e..g <Campaign_Names><Campaign_Name>Disco Foo</Campaign_Name><Campaign_Name>Sunday Parade</Campaign_Name></Campaign_Names>)
• Add a simple campaign appellation as a newly created name for new activity and then in the future also add a campaign_ref to a Campaign entry when more is known and that knowledge is formalized This new type would be added to the stix_common.xsd schema file such that it could be leveraged in several places throughout STIX. We currently propose adding a Campaign_References element of CampaingReferencesType to Indicator. For STIX 2.0, we see potential applicability to adding a similar element to other constructs such as Incident, TTP, Exploit_Target, Threat_Actor and potentially Observables.

It should be noted that this relationship structure is a subset of the standard full extension of GenericRelationshipListType used in most relationships between STIX top level constructs. This is due to the fact that Campaigns are only applicable as separate constructs related from an Indicator and would never make sense to define inline within an Indicator as an inherent part of the Indicator itself.

It is further proposed that the existing Related_Indicators structure within the Campaign construct be removed in order to avoid consistency and complexity issues with maintaining the same relationships in multiple places.

Upon our review of this proposed approach there do not seem to be any major ontological issues, though we are interested if you see any.

Here is a graphical image of the draft schema for the new proposed structure.

Here is the draft XSD code for the proposed solution.

	<xs:complexType name="CampaignReferencesType">
		<xs:annotation>
			<xs:documentation>The CampaignReferencesType specifies identity for one or more referential campaigns asserted to be related to this component.</xs:documentation>
		</xs:annotation>
		<xs:sequence>
			<xs:element maxOccurs="unbounded" name="Campaign_Reference"
				type="campaignref:CampaignReferenceType">
				<xs:annotation>
					<xs:documentation>The Campaign_Reference field specifies identity for one referential campaign asserted to be related to this component.</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
	</xs:complexType>
	<xs:complexType name="CampaignReferenceType">
		<xs:sequence>
			<xs:element name="Campaign_Names" type="campaignref:CampaignNamesType" minOccurs="0">
				<xs:annotation>
					<xs:documentation>The Campaign_Names field provides one of more referential campaign names.</xs:documentation>
				</xs:annotation>
			</xs:element>
			<xs:element name="Confidence" type="stixCommon:ConfidenceType" minOccurs="0">
				<xs:annotation>
					<xs:documentation>The confidence field specifies the level of confidence in the assertion of the relationship between the two components.</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
		<xs:attribute name="campaign_ref" type="xs:QName">
			<xs:annotation>
				<xs:documentation>Specifies a globally unique identifier for a cyber threat Campaign specified elsewhere.</xs:documentation>
			</xs:annotation>
		</xs:attribute>
	</xs:complexType>
	<xs:complexType name="CampaignNamesType">
		<xs:sequence>
			<xs:element maxOccurs="unbounded" name="Campaign_Name" type="xs:string">
				<xs:annotation>
					<xs:documentation>The Campaign_Name field provides a single referential campaign name.</xs:documentation>
				</xs:annotation>
			</xs:element>
		</xs:sequence>
	</xs:complexType>

Impact

This proposal resolves what is considered a bug in STIX 1.0 and is not fully backward compatible. Specifically, it removes the Related_Indicators element from CampaignType. Any Campaign instance content currently containing such relationship specifications would need to be transformed to utilize the proposed Campaign_References structure on Incidents in order to be valid for STIX 1.1.

Requested Feedback

1. Is there value in the ability to refer to Campaigns from Indicators?
2. Is the set of fields outlined for the CampaignReferencesType appropriate and adequate?
3. Are there any significant issues with removing Related_Indicators from CampaignType?
4. Are there any ontological issues other than those discussed above?