Re: [cti] Top-Level Object Properties

First in defense of Sean, the majority of the proposals attributed to Sean are actually the result of collaboration of with a number of us that are in the threat intelligence business and actively do threat sharing. So much like there is a TWIGS team, there is a team working with Sean in much the same manner (we just don’t have a catchy name), they’re not just Sean’s opinions. @Sean – sounds like a high priority tasker is for us to create a catchy name ;-)

With regards to external_ids, it does appear we don’t consensus YET, but I’m hopeful as I don’t see Proposal #1 and #2 that far apart with regards to the topic of external_ids. If one looks around, you'll find that everything doesn’t have a “well-known” id format (e.g., CVE) which could be used to indicate what well-know external system the entity is in. In addition, there are other situations others where the external_id value requires context in which to allow the consumer to know how to use that ID, be it formatted or just plain-text as in Bret’s example or a reference to a document. In those cases, it needs to be allowable to specify that additional context and include a reference in the form of a URL as an option. So I don’t believe that we can just conclude that this field will always be a simple string. This was the reason external_ids defined the way they were in both proposals.

As I look at both proposals, I don’t see them that far off from one another. To the point of proposal #2, perhaps a more appropriate field name should be something like ‘external_refs’, where a reference could be to a document, an id in an external system, etc. In order to avoid confusion, perhaps ‘id’ in proposal #1 and ‘name’ in proposal #2 should be renamed to some different, like ‘identifier’. ‘defining_context' and ‘type' are essentially attempting to provide the same notion except in proposal #2 the actually context in which the ‘identifier’ is valid can’t be expressed. In addition, we should continue to reserve the field name ’type’ to specify the type of the object. The remaining fields, ‘name’ and ‘url’ can be supported in both proposals.

So as a ‘vendor’ who produces shared threat intelligence as a product, I need this level of capability because I need to provide my clients with as much context as I can so that they have the background necessary regardless if the object is being used at the tactical level and actioned by a machine, or included in something at the operational or strategic level which would involve humans (e.g., analysts).

Paul Patrick

Chief Architect

iSIGHT Partners

From: <cti@lists.oasis-open.org> on behalf of "Jordan, Bret" <bret.jordan@bluecoat.com>
Date: Wednesday, February 3, 2016 at 10:24 AM
To: "Wunder, John A." <jwunder@mitre.org>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Top-Level Object Properties

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.

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."

cti message