OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: External ID/References in STIX



On the call today we plan on revisiting how to specify external ids and references in STIX.  Here is the write-up we will discuss.




Rich Piazza

The MITRE Corporation





There are many sources of external information that we want to reference in STIX:


·         IDs of related non STIX objects.  For example:

o   The same incident might be represented in another (perhaps external) system – e.g. your internal ticketing system.

o   an asset might be modeled/described in some other tool used internally – using a reference to the ID in that tool would avoid duplication of data in STIX.

·         IDs can reference public repositories/enumerations (CAPEC, CVE, etc)

·         Content on the web (via a URL)


Previously there was a proposal in STIX 2.0 to introduce a TLO called (External) Reference.  It has the following unique fields:

·         reference_url

·         external_identifier

·         defining_context


Any other TLO could be associated with an External Reference TLO via a Relationship TLO.  This was an attempt to cover the use cases above, which are addressed in STIX 1.2 with a combination of the InformationSource type, external_id field (on an Incident), fields of TTP and Exploit Target “subtypes” (e.g., Attack_Pattern has capec-id, Vulnerability has cwe-id, etc).


This introduces the concept that it is useful for any type of TLO to have external references.  However, it is through the use explicit Relationship TLOs, which isn’t a “lightweight” way just to say, for instance, that an Attack Pattern refers to one of the entries in CAPEC. It would take 2 additional TLOs just to add that one extra piece of data.


In the discussions of TTPs there was much interest in having a capec-id field, which would just be a string of the form CAPEC-xxx, and not using a Relationship TLO.  However, this implies that CAPEC entries are the only external ids that should be associated with an Attack Pattern.  We could always introduce other fields in future releases, or a custom field could be used, but it was instead proposed that an Attack Pattern (and other TLOs like Vulnerability, etc), could have an external_ids field which would allow any and more than one external id to be referred to:



 "type": "attack-pattern",

 "id": "attack-pattern--0c7b5b88-8ff7-4a4d-aa9d-feb398cd0061",

 "revision": "1",

 "created_time": "2016-05-12T08:17:27.000000Z",

 "modified_time": "2016-05-12T08:17:27.000000Z",

 "title": "Install New Service",

 "description": "...",

 "external_ids": [{"source": "capec", "id": "CAPEC-550"}, {"source": "att&ck", "id": "1050"}]



Here is the JSON if we use Relationship TLOs:




However, it seems redundant to have both external-reference TLOs and external_ids fields, especially if we decide that all TLOs should have an external_ids field, because it goes against the “one way” design goal of STIX 2.0.


Therefore, I propose that we:

1.       Remove the External-References

2.       Add external_references as a common TLO field (renamed from external_ids)


The open questions are:


1.       Are external_ids and external_references similar enough that we can represent them with the same structure?

2.       Currently, the External-References TLO has title and description fields – are those necessary?

3.       Should the external_references field just be a list of strings or should the entries have some structure (see example above)?  If so, what should the keywords be?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]