Firewall log in ECS

[phruby]

I have a couple of basic questions regarding mapping firewall log fields to Elastic Common Schema, in the way compatible with the intentions of ECS designers.

Firewall is deployed on a server determined by the 'origin' field. The firewall exports logs to a log server, which is a different server than the firewall server. The event contains several fields describing the event information, and one field called 'Action', describing the outcome.

An example of and event in the firewall log is below - for simplicity I omit the fields not relevant to this question (i.e. source, destination, etc. are omitted):

<134>1 2019-08-23T08:52:01Z fwlog007 CheckPoint 15774 - [action:'Accept'; origin:'87.28.122.231'; policy_name=vfw-modq-rule; rule:'92'; rule_uid:'{DF773648-A85C-B9D5-366F-23193C818B20}']

Explanation of the fields is below:

• origin is an ip address of the firewall server
• fwlog007 is the hostname of the log server (i.e. where the firewall writes the log), it is different server than origin.
• action is the action of matched rule
• policy_name is the name of the last policy fetched
• rule is the matched rule number
• rule_uid is access policy rule ID which the connection was matched on

Taking literally the ECS field reference, the mapping could look like this - but does not look right.

• origin: => in ECS would be observer.ip
• fwlog007 => Big question in ECS. observer.hostname would be incorrect, because it is not the same server as firewall (origin). However, the firewall log server conceptually belongs to the observer system, so the host.hostname, client.hostname, server.hostname do not sound correct either.
• action => in ECS would be event.outcome, i.e. 'Accept' (in ECS describes an outcome of the action)
• policy_name, rule and rule_uid: => in ECS would all be mapped to event.action (Action describes the information in the event)

In summary, here are my questions and issues with the mapping above:

1. the firewall server and the log server conceptually both belong to ECS observer system, but observer can have only one ip and one hostname in ECS.
2. there are three fields describing the applied policy and rules (i.e. the information in the event), but ECS allows only one event.action
3. the field called 'action' in the firewall log is not mapped to event.action but to event.outcome in ECS, which could lead to confusion.

Any guidelines how to make the mapping consistent with the ECS intentions would be very helpful.
Thanks,
Pavel

[Mike_Paquette]

Thank you for the post. Good questions. If you are comfortable, why not post this as an issue in https://github.com/elastic/ecs/issues ? There's a great community of ECS implementers there that can offer advice. Some quick thoughts:

1. The observer fields should be populated with details about the observer that is closest to where the event happened. So in your case, you should populate them with the firewall (origin) details, not the log server. The logger details would not be captured in any ECS field. I think the ECS documentation should be clearer about this.

2. Fields for additional details about policy and rule might be good additions to ECS. Further discussion would be good in the GitHub repo mentioned above.

3. I think that you should map your action field to ECS event.action. The ECS event.outcome is normally filled with {"success", "failure", "unknown}. So you would have event.action:"accept" and event.outcome:"success". I would suggest you also populate observer.type:"firewall"

Thanks,
Mike

[phruby]

Thanks Mike! I'll do as you say.

Just for clarification, if "the logger details would not be captured in any ECS field", don't we loose information?

Would something like observer.logger.hostname be within the intentions of ECS?

Pavel

[Mike_Paquette]

Just for clarification, if "the logger details would not be captured in any ECS field", don't we loose information?

In theory yes, but it's a question of scope. ECS has defined a scope that excludes message queues and ETL components, including loggers. If information about the logger is important to your use case, you can always create a custom field/field set to hold information about the logger or any other devices that might be in the path between the event source and the Elasticsearch store.

Would something like observer.logger.hostname be within the intentions of ECS?

Not presently.

[phruby]

Hi Mike,
thank you very much for the answer.
Until now I thought that Elastic Common Schema attempts to be a complete taxonomy for the logging domain, and knowing that some data in the logs are out of scope of ECS is very useful.
It has simplified my mappings. Thanks!
Pavel