Hi everyone,

I wanted to solicit some discussion around  Metron standard field names.

I would love to have "convenient" field names. As convenient, I mean:
short, not ambiguous, well-known, documented.

Here is my feeling regarding  the actual standard field names[0]:
- ip_src_addr:  too long, could be "ip.src"
- ip_dst_addr:   too long, could be "ip.dst"
- ip_src_port:  I prefer tcp.srcport
- ip_dst_port: I prefer tcp.dstport
- protocol:  ambiguous, I prefer ip.proto
- timestamp: ambiguous, which timetamp ? When the event happend  ? Or
when the log has been received ?  Or when the log has been generated ?

Also, it would be useful to publish a "reference list" of  fields
(It's helpful when you write correlation rules or new parsers).
Example: https://www.wireshark.org/docs/dfref/

Wireshark, as a well-known tool used by SOC investigator,  could be a
good starting point[1][2] to find convenient field names. Quick
example (markdown format):

|Field Name|Description |Type|Example|
|---|---|---|---|
|frame.len| Frame length on the wire|   Unsigned integer, 4 bytes|123|
|ip.src|Source Address|IPv4 address|192.0.2.1|
|ip.dst|Destination Address|IPv4 address|192.0.2.1|
|ip.addr|Source or Destination Address|IPv4 address|192.0.2.1|
|ip.proto|Protocol|Unsigned integer, 1 byte|6|
|ip.srcport|UDP or TCP source Port|Unsigned integer, 2 bytes|12345|
|ip.dstport|UDP or TCP destination Port|Unsigned integer, 2 bytes|53|
|tcp.srcport|TCP source Port|Unsigned integer, 2 bytes|12345|
|tcp.dstport|TCP destination Port|Unsigned integer, 2 bytes|80|
|tcp.len|TCP Segment Length|Unsigned integer, 4 bytes|123|
|udp.srcport|UDP source Port|Unsigned integer, 2 bytes|12345|
|udp.dstport|UDP destination Port|Unsigned integer, 2 bytes|67|
|http.host|Host|Character string|example.net|
|http.referer|Referer|Character string|http://example.net/foo|
|http.request.method|Request Method|Character string|POST|
|http.full_uri or uri |Full request URI|Character
string|http://example.net/foo?bar=baz|

What do you think?

My 2 cents,
-- 
Yohann L.

Reply via email to