[ ] Add network.bytes (derived from source.bytes + destination.bytes)
1: ingress/egress depends on user-assignment (see fortigate for example).
2: Needs to be set based on contents of log. Other integrations use an log ID/event code to do this. We may only be able to use the log type, unless I'm missing something.
There may be other fields, this is what I saw on an initial look. As always, fortigate is a good integration to reference. Here's its ecs.yml as reference, and note that not all fields will be applicable here, it's just to get an idea of what's out there.
Inputs
ECS Improvements
New mappings (from existing vendor fields)
in_bytes
->source.bytes
out_bytes
->destination.bytes
dstif
->observer.[ingress|egress].interface.alias
(1)dstifname
->observer.[ingress|egress].interface.name
(1)srcif
->observer.[ingress|egress].interface.alias
(1)srcifname
->observer.[ingress|egress].interface.name
(1)fw
->observer.name
(noobserver.id
in https://www.elastic.co/guide/en/ecs/current/ecs-observer.html)msg
->message
starttime
->event.start
time
->@timestamp
Cleanup
origdst
origdstport
tz
New mappings
event.kind
event.category
event.type
(2)destination.mac
to fields.ymlnetwork.bytes
(derived from source.bytes + destination.bytes)1: ingress/egress depends on user-assignment (see fortigate for example). 2: Needs to be set based on contents of log. Other integrations use an log ID/event code to do this. We may only be able to use the log type, unless I'm missing something.
There may be other fields, this is what I saw on an initial look. As always, fortigate is a good integration to reference. Here's its ecs.yml as reference, and note that not all fields will be applicable here, it's just to get an idea of what's out there.