Add names to enumerated item definitions

[davaya]

Discussion 243 addresses how to represent enumerated values as data in transit and storage. Keith refers to the "verbosity" discussion and the fact that it is not yet resolved.

This poll does not affect data values within OCSF, it concerns translation of external enumerations to the OCSF framework. It proposes adding a name to all OCSF enumerated item definitions to support robust translation between external environments and OCSF. This proposal enables OCSF to support both verbose and machine-optimized data without affecting any decision on which to use in a particular situation.

DEFINITIONS:

• id: an integer unique identifier (e.g., 80)
• name: a text unique identifier (e.g., "http"). Event Template defines name syntax: "The name is all lower case letters, combine words using underscore."
• caption: an unrestricted friendly text label (e.g., "HyperText Transport Protocol").

But Understanding OCSF uses name and caption interchangeably:

Categories also have friendly name captions, such as System Activity, Network Activity, Security Findings, etc.
Enum constant identifiers are integers from a defined set where each has a friendly name label.

This conflicts with the actual definition of Category, which has explicit id, name, and caption values, not "friendly name captions":

id	name	caption
1	system	System Activity
2	findings	Findings
3	audit	Audit Activity

The current framework enumerations have only id and "friendly name labels" (caption), but no name:

id	caption
1	Access Granted
2	Access Denied
3	Access Revoked
4	Access Error

PROPOSAL

Update all framework enumerations to have id, name and caption values, e.g.:

id	name	caption
1	granted	Access Granted
2	denied	Access Denied
3	revoked	Access Revoked
4	error	Access Error

RATIONALE

Many existing authorities maintain enumeration registries, including:

• ISO 3166: Countries
• ICANN Country Code Top Level Domains

id	name	caption
4	af	Afghanistan
826	uk	United Kingdom of Great Britain and Northern Ireland
840	us	United States of America

• Internet Assigned Numbers Authority: Service Names and Port Numbers

id	name	caption
21	ftp	File Transfer Protocol [Control]
22	ssh	The Secure Shell [SSH] Protocol
25	smtp	Simple Mail Transfer
53	domain	Domain Name Server
80	http	World Wide Web HTTP

• MITRE ATT&CK Framework: Tactics and Techniques

id	name	caption
1	TA0001	Initial Access
2	TA0002	Execution
3	TA0003	Persistence
42	TA0042	Resource Development
43	TA0043	Reconnaissance

The purpose of adding a name value to OCSF enumerations is to facilitate unambiguous translation to external enumerations. For example, ICANN registers top-level DNS domains by name (two-letter ISO 3166 country code) and caption (full country name), but does not define any numeric ID and thus cannot be used in OCSF enumerations without a name field.

Similarly, the MITRE ATT&CK framework does not explicitly assign numeric Tactic and Technique IDs, although their name strings contain numbers from which id numbers could in principle be derived. If OCSF enumerations explicitly define a name value, that theoretical mapping becomes explicit, enabling OCSF enumerations to be defined and obviating the need for hand-waving user instructions like "The a list [sic] of tactic ID's that are associated with the attack technique, as defined by https://attack.mitre.org/wiki/ATT&CK_Matrix". Is a "tactic ID" in this sentence a numeric id, an alphanumeric name string, or a friendly caption string?

The port id to name mapping is well-defined and well-known, unlike the id to caption mapping (is it "Simple Mail Transfer", or "Simple Mail Transfer Protocol"? Defining a name value in OCSF enumerations aligns it with common practice and facilitates translating string unique identifiers in data sources like log files to OCSF numeric ids.

[pagbabian-splunk]

enums can be text, or names, along with captions; do we need all three? It would force us to fill in all the existing enums, many won’t need short names.