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: Re: [cti] CybOX Datatype Refactoring/Deprecation

As much as I would like fields to just be the value, I agree that we probably need this layer of indirection to support these extra properties. We’ll need to decide what that means for patterning, if anything, by the way.

On the attributes you listed, I just have a few questions:
  1. Given that we’re talking about actual observations here (instances), is “appears_random” appropriate? That seems to be a statement about a pattern of behavior over several observations rather than a single observation.
  2. Can we combine the “obfuscation” fields into some single “obfuscation_algorithm”, representing a URI or something? Then if the field is there, it’s obfuscated using that. If it’s not, then it’s not obfuscated.
  3. For defanging, I have a two part question:
    1. Given that we’re now talking about machine-to-machine transmissions, is defanging still important? Can’t the raw data be exchanged as it is and then let tools to present it to users defanged however they want? It seems weird to me to transmit it defanged if it’s M2M (vs. a PDF that people might accidentally click).
    2. If we do need to include it, can we similarly collapse these attributes into one “defanging_algorithm” URI? They seem very redundant right now.

From: <cti@lists.oasis-open.org> on behalf of Ivan Kirillov <ikirillov@mitre.org>
Date: Tuesday, February 9, 2016 at 12:21 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] 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",

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?

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