Active Issue: Relating Source

Consensus

Information identifying and characterizing sources of CTI information should be broken out into a separate "top level" Source construct rather than embedded within each "top level" construct.

Open Questions

1. How should the relationship between a "top level" construct instance and its Source be asserted?

Questions to consider

1. Should Source follow the "one way to do things" with relationships or should it be an exception to the rule?
2. Is Source a key CTI object or only metadata?
3. Should there be a distinction between the producer of the STIX and the source of the content?
4. If so, how should that distinction be conveyed?
5. How do we deal with anonymous sources?
6. Separate Source object each time an anonymous source is asserted or one general anonymous Source object that is related to for each anonymous source assertion?
7. How do we deal with deanonymizing an anonymous source?
8. How do we deal with third party source assertions?
9. How do we deal with complex source chains (e.g., Z sends me STIX that is a translation of STIX produced by Y that was a STIX codification of information created by X)?
10. How do we deal with uncertainty/confidence on source assertions?
11. How important is bandwidth efficiency?
12. What are the best approaches for dealing with the issue?

Proposal #1

Follow the "one way of doing things" for relationships and assert source relationships for all "top level" construct instances using the Relationship object with a relationship nature of "Has Source".

Strong assertion that Source is a key CTI object and not simply metadata.

Advantages:

• Consistency (one way of doing relationships)
• Treats Source as a key CTI object and allows its characterization and correlation like any other CTI object
• Inherently graph-based to support analysis
• Enables assertions for both producer of the STIX itself and the creator of the content itself
  • In large majority of cases they will be the same and this approach allows them to be asserted consistently
• Enables support for anonymous sources and for deanonymizing sources
• Supports third party source assertions
• Inherently supports complex source chains in a consistent fashion
• Allows assertion of confidence for any source assertion
• When same exact content received from multiple sources, allows you to characterize (with confidence) them separately
• Supports more flexible pivoting on Source

Disadvantages:

• Could result in more verbose content (a few extra lines for the "Has Source" relationship of each construct).
  • Can be mitigated by a many-to-one relationship for "Has Source" which would offer the most efficient representation available.

Examples

Example #1: simple indicator with attributed source for the information

{
	"id": "example:src-83dc6b53-ac3d-40e0-82ef-eab173c7ee1e",
	"type": "source",
	"timestamp": "2015-12-21T19:59:11Z",
	"name": "US-CERT"
}

{
	"id": "example:ind-b8e37090-5d62-45a1-ac2e-a88601b08432",
	"type": "indicator",
	"timestamp": "2015-12-21T19:59:11Z",
	"title": "Sakurel Malware",
	"indicator_expression": "this would be an observable pattern for a particular file hash using the new CybOX patterning language under consideration",
	"indicator_type": ["File Hash Watchlist"]
}

{
	"id": "example:rel-9d0c539e-a874-42c7-a055-3e900b98724f",
	"type": "relationship",
	"timestamp": "2015-12-21T19:59:12Z",
	"from": "example:ind-b8e37090-5d62-45a1-ac2e-a88601b08432",
	"to": "example:src-83dc6b53-ac3d-40e0-82ef-eab173c7ee1e",
	"relationship_nature": "Has Source"
}

Proposal #2