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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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


Subject: CybOX Datatype Refactoring/Deprecation


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


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