Skip to content

How should the attribute suffixes `_uid` and `_id` be used and what are "siblings?"

These are naming conventions rather than metaschema or data type validation factors. _id is the convention for OCSF enumerated attributes. These attributes can be integer data types, or string data types, although OCSF favors integer data types with string labels. Every integer enum attribute SHOULD have standard values of 0 for Unknown and 99 for Other. There is no requirement that the integers stay within those bounds, or that they increment by 1. Every enum attribute SHOULD have a string sibling attribute of the same name but without the _id suffix. A sibling is declared within the attribute definition of the enum attribute. When the logged value is not mappable within the enum listed values, Other can be set and a source specific label can populate the sibling attribute. The exception to this convention is when an enum attribute mirrors an external standard, for example with the dns_query object’s opcode_id which mirrors the values requested from a resolver. It is recommended that the sibling attribute is populated with the enum label so that human queries can be made against a more easily remembered string, rather than a number.

_uid suffix attributes are for unique identifier values within the schema, or external identifier values, e.g. coming from a public cloud resource or similar entity. For this reason _uid suffix attributes are usually strings, in order to accommodate any type of alphanumeric format, but they MAY be integers (or longs). Within OCSF Classification attributes, _uid attributes are integers or longs (see class_uid or type_uid). The sibling for _uid attributes is an attribute of the same base name with the _name suffix (see class_name or type_name). The exception for Classification attributes is activity_id which is an enum rather than a singular identifier. However its sibling is also of suffix _name: activity_name following the convention for _uid attributes of the Classification group.

Note that sibling string attributes can be used standalone, i.e. without an associated enum or unique identifier.