OASIS Cyber Threat Intelligence (CTI) TC

 View Only

CybOX Datatype Refactoring/Deprecation

  • 1.  CybOX Datatype Refactoring/Deprecation

    Posted 02-09-2016 17:22



    Sending this to the broader CTI since it’s part of the STIX/CybOX Indicator tranche. 


    Given that we’ll be splitting out embedded patterning from CybOX, there are changes that we need to make to the base datatypes used currently for specifying properties in CybOX Objects. At a high level, this involves the following:

    Deprecating any types/enums associated with patterning Refactoring the base BaseObjectPropertyType (the base type for ALL Object properties) to remove patterning and permit more accurate datatype based field specification in Objects (e.g., an integer is represented as an integer and not a string). Accordingly,
    this would entail creating a new BaseStringObjectPropertyType and BaseNumberObjectPropertyType that extend from the refactored BaseObjectPropertyType. Updating the existing ObjectPropertyTypes (e.g., StringObjectPropertyType, DoubleObjectPropertyType, etc.) to extend from the new BaseString/Number ObjectPropertyTypes
    More details on these proposed changes can be found here:  https://github.com/CybOXProject/schemas/issues/416#issuecomment-181916815


    Accordingly, this would result in CybOX instance content that looks like the following; each property is an Object (so that it can specify metadata about refanging/defanging/etc) and thus the “value” field MUST be included in every property to capture
    its actual value.



    {
    " size " : { " value " : 23134 },
    " file-system-properties " : { " file_name " : { " value " : " test.dll " ,
    " observed_encoding " : " utf-8 " }}
    }



    Some open questions:

    Does this approach seem reasonable? Do we need all of the properties defined on the BaseObjectPropertyType (see below), or are there other properties that we should consider adding?

    appears_random  (boolean):
    whether the property appears random in nature is_obfuscated  (boolean):
    whether the property has been obfuscated obfuscation_algorithm_ref  (string):
    a reference to a description of the algorithm used to obfuscate the object property is_defanged  (boolean):
    whether the property has been defanged defanging_algorithm_ref  (string):
    a reference to a description of the algorithm used to defang the object property refanging_transform_type  (string):
    the type of refanging transform specified in the refanging_transform property refanging_transform  (string):
    an automated transform that can be applied to the object property in order to refang it to its original format observed_encoding  (string):
    the encoding of the string as observed
    For the extensions of the BaseStringObjectPropertyType and BaseNumberObjectPropertyType, such as PositiveIntegerPropertyType, should we define additional patterns (i.e. regular expressions) for field-level validation of these
    types? E.g., in this example, to make sure that the number is a valid positive integer?
    Regards,
    Ivan