Re: [cti] STIX RC3 - issues.

["Wunder, John A." <jwunder@mitre.org>]

My preference would be to keep both. Extensions have a specific purpose in Cyber Observables: defining coherent sets of fields used to describe properties beyond the base, i.e. HTTP info for a Network Traffic object. If you wanted to define some AMQP properties to the Network Traffic object you could create a custom extension for that and, eventually, it might be rolled in as an official extension. If OTOH, STIX Custom Properties also have a specific purpose: allowing vendors and communities to share data at any level of any object that isn’t part of the official STIX standard. So if you had a vendor or community-specific field for Network Traffic object (QoS, some other tag) you would use STIX Custom Properties. So CybOX Custom Extensions are used to capture data that would generally be captured as a Cyber Observable extension if it were standardized while Custom Properties are used to capture data that would otherwise be a part of the base object or an existing extension if it were standardized.

The biggest impacts I see to the other approaches:
- Doing only STIX Custom Properties requires rewriting most of the Cyber Observable specification (since if you have extensions, you need custom extensions or you have two ways of doing things) – as Trey says
- Doing only Cyber Observable Custom Extensions precludes vendors or communities from adding fields at any level of the hierarchy, which we had specifically wanted to support. In particular, tools doing JSON-LD can take advantage of this (they would not be valid STIX without the ability to add fields at any level of the hierarchy). While I wasn’t a fan of requiring tools to do JSON-LD, I also don’t think we should preclude it.
- Doing STIX Custom Properties everywhere but Cyber Observables is inconsistent and confusing IMO. It also precludes doing JSON-LD or other types of processing which require custom properties at any level of the hierarchy.

John

On 11/11/16, 12:38 PM, "Trey Darley" <cti@lists.oasis-open.org on behalf of trey@kingfisherops.com> wrote:

    On 11.11.2016 14:58:55, Allan Thomson wrote:
    > Suggest that Cyber Observables just use the same mechanism defined
    > for STIX custom properties and remove the way CybOx did it.
    > 
    
    The entire Cyber Observables (formerly CybOX) data model was built
    around the concept of base objects with extensions. CybOX
    customization was built around the concept of custom object extensions
    from the very beginning.
    
    In the course of the editorial calls on the document merge, several
    STIX editors argued for *also* allowing custom object properties in
    CybOX, since they were defined in STIX. Ivan and I agreed under
    protest, in the spirit of choosing one's battles.
    
    Ripping out custom extensions from the Observable data model would
    mean a major trip back to the drawing board. If anything, we should
    remove custom object properties from the Observable data model. Or
    content ourselves with their being two ways of customizing things.
    Ivan and I *explicitly* pointed this out when as a downside of adding
    custom object properties during the document merger.
    
    -- 
    Cheers,
    Trey
    ++--------------------------------------------------------------------------++
    Kingfisher Operations, sprl
    gpg fingerprint: 85F3 5F54 4A2A B4CD 33C4  5B9B B30D DD6E 62C8 6C1D
    ++--------------------------------------------------------------------------++
    --
    "With sufficient thrust, pigs fly just fine. However, this is not
    necessarily a good idea. It is hard to be sure where they are going to
    land, and it could be dangerous sitting under them as they fly
    overhead." --RFC 1925