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:
- 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.
- 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.
- For defanging, I have a two part question:
- 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).
- If we do need to include it, can we similarly collapse these attributes into one “defanging_algorithm” URI? They seem very redundant right now.
John
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
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 natureis_obfuscated (boolean):
whether the property has been obfuscatedobfuscation_algorithm_ref (string):
a reference to a description of the algorithm used to obfuscate the object propertyis_defanged (boolean):
whether the property has been defangeddefanging_algorithm_ref (string):
a reference to a description of the algorithm used to defang the object propertyrefanging_transform_type (string):
the type of refanging transform specified in the refanging_transform propertyrefanging_transform (string):
an automated transform that can be applied to the object property in order to refang it to its original formatobserved_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
|