You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@metron.apache.org by Yohann Lepage <yo...@lepage.info> on 2016/09/21 19:51:16 UTC
[DISCUSS] Metron standard field names
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.
Re: [DISCUSS] Metron standard field names
Posted by Yohann Lepage <yo...@lepage.info>.
2016-09-21 22:00 GMT+02:00 Zeolla@GMail.com <ze...@gmail.com>:
> Elasticsearch can't use periods in field names,
It's possible again since the latest release
https://www.elastic.co/blog/elasticsearch-2-4-0-released
--
Yohann L.
Re: [DISCUSS] Metron standard field names
Posted by "Zeolla@GMail.com" <ze...@gmail.com>.
Elasticsearch can't use periods in field names, I think that's part of why
they aren't used generally. I think this is a worthwhile discussion
though, specifically regarding the timestamp and protocol discussion you
started above.
On Wed, Sep 21, 2016, 15:52 Yohann Lepage <yo...@lepage.info> wrote:
> 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.
>
--
Jon