Network Connection Information object encodes the same information two ways

[JasonKeirstead]

Network connection information contains several duplicate mandatory fields that contain the same information

Field Name	Field	Type	Desc
Boundary	boundary	String	The boundary of the connection
Boundary ID	boundary_id	Integer	The boundary of the connection
IP Version	protocol_ver	String	The Internet Protocol version.
IP Version ID	protocol_ver_id	Integer	The Internet Protocol version identifier.
Direction	direction	String	The direction of the initiated connection.
Direction ID	direction_id	Integer	The direction of the initiated connection.

The string versions of these are especially problematic because there are no guidelines as to what options are valid. They are limited in value to an analyst because every product will be outputting them differently (ie "IPV4" vs "IP V4" vs "4" and "inbound" vs "ingress" vs "in" vs "source_to_dest" vs...)

Protocol Name and Protocol Num are also duplicate, but at least protocol name is optional, and it has constraints (maps to IANA in lowercase) so there is going to be consistency.

Boundary and Boundary ID are also duplicate, but both are optional so damage is a bit less, however once again the string versions of these will have limited value

Proposed Solution

I would propose all of the string fields be simply eliminated

[davaya]

On the call, Josh mentioned two use cases:

1. mnemonic names for enumerated data items
2. non-standard extensions beyond core

The discussion must treat those two cases differently. For extended values an int of -1 is used and a string provides extra information (e.g., "MyTeapotOverheat") in addition to the value -1. For that use case the string is not duplicate information, it is supplemental information, and both are needed.

But for the first use case, -1 has a defined mnemonic string "other". A protocol would never send both -1 and "other" in the same message, just as a port attribute would never have both 80 and "http" in the same message or the same database. But database A could store 80 and database B could store "http" and their events could be joined because 80 = "http".

The OCSF framework can define four values for each item in an Enum:
id: 80
name: http
caption: HyperText Transport Protocol
description: The language of the World Wide Web

Caption and description would never be sent or stored in event instances. Either id or name but not both would be sent and stored in event instances. Name has the identical semantics as id: it must have a unique (normalized) value and it cannot collide.

The poll must be clarified to distinguish supplemental information (-1/other + "my custom event") and normalized int/string representations of the identical information (80/http).

Poll option 5:
() Define normalized string names corresponding to each id, require either id or name depending on data flavor.