Sorry for the delayed response. I did not have my computer with me at the SANS CTI Summit yesterday.
Bret, the structure for external_ids on the wiki page is what was presented during the STIX #2 time block at the F2F and had consensus from everyone present (no concerns or objections
were raised).
I would strongly assert that use cases for including external ids require more than just an array of strings.
Bare minimum you need the identifier itself and some characterization of the context for that identifier (without which you would have no idea what context the identifier comes from).
I think your comment below about
"Why does it need an “id”” is likely due to the field currently being named “id” on the wiki page and confusing it with a STIX id.
I agree this is confusing. I would suggest that this field name be changed to “exernal_identifier”.
The “url” field should likely
similarly be renamed more specifically to “url_reference”. This field capability is also something that
has been brought up in the use cases driving towards including an external_ids property. The intent being to provide an optional way to provide a resolvable way to access the content in it external context.
>External_Ids are going to be populated by internal systems or vendor products. These solutions will give a name like "malware foo xyz" for example, this is not a URL.
I don’t think this is an accurate characterization of many of the use cases for external_ids.
The initial scenario that led to external_ids being included on Incident (its first use) was raised by US-CERT and some European CERTs and was basically that a STIX characterization of an Incident shared between parties and linked to other STIX
content (TLOs) would likely be a subset of the full incident info held by the producer and it would be highly desirable to include the identifier for the incident within the producer’s context, a way to identify that context for the identifier and to provide
a URL (likely representing an API call) to the incident within the producer’s system. If a consumer (internal or external to the producer’s environment) had permissions to access that incident in the producer’s system they could follow the URL and get access,
and if they did not they would get an access error.
Alternative_IDs was later added to Indicator by the community as they felt the above sort of use case pattern likely also applied to indicators.
When we discussed normalizing these two structures to common naming and structure it was brought up that this sort of use case pattern also likely applies to almost any STIX content and so having the structure as a common property on all “top
level” objects made sense. This is what led to the current proposal and the consensus that existed until you raised your objection.
I believe this presumption of applicability across other STIX objects was confirmed during recent discussions on the Exploit_Target refactoring where it was suggested that the CVE_ID, OSVDB_ID, CWE_ID and similarly CAPEC_ID on TTP should likely
just
be implemented using the external_ids structure rather than separate purpose built fields.
Basically something like:
Notice that the external_identifer is the same but the defining contexts and url_references are different and correlated to different external data sources for this vulnerability.
I believe that the above use cases raised by the community are valid and should be supported.
I believe the proposed structure is clear (with renaming of “id” to “external_identifier” and “url” renamed to “url_reference”), consistent and simple.
I do not see any way that these sub-properties can be merged in any practical way. “external_identifer”, “defining_context” and “url_reference” each serves a specific purpose and it would place undue burden on any
consumer to parse and pull them apart if they were somehow merged. It is simpler to explicitly specify each in its own field.
sean
So fwiw I like having the identity/source separate from the reference. I do kind of agree that we could merge the url, name, and ID fields though…it’s a distinction that probably doesn’t matter for the vast majority of cases. I could go either
way.
It should just be an Array of Strings and then the user can put in what every they want.
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
url is optional,
you can use name,
which is also optional – you just have to use one of them
Well then I do not think we have consensus on the external_ids object... I thought this was going to be just an array of string values. Why does it need an "id" and why would we every make data field be a "url".
External_Ids are going to be populated by internal systems or vendor products. These solutions will give a name like "malware foo xyz" for example, this is not a URL.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
The syntax means that those fields are a sub-object nested under the parent. So that would be one of the keys within the objects in the external_ids array.
I do not believe we have consensus on all of the items in the consensus section. Namely, what are the "----" field all about?
Example
|
----id (required)
|
IDFormat
|
The external ID itself
|
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
There’s a new topic to think about! As discussed at the face to face, each top-level object in STIX and CybOX will inherit from a core set of properties…things like ID, etc. We haven’t
quite agreed on what all of those fields are, though.
Take a look at this writeup: https://github.com/STIXProject/specifications/wiki/Active-Issue:-IDable-Construct-Properties.
It has a set of fields that we have general agreement on, a list of fields we haven’t really discussed, and then a couple proposals (from Sean and from the twigs team). Feel free to either add your own proposal to that wiki page or discuss on the mailing lists
and slack. The key question to consider: what fields should be available on *all* top-level objects?