Currently parsed events coming from Cisco ASA firewall ingest pipeline show 4 types of values in field event.action: firewall-rule; flow-expiration; flow-creation and error.
Value "firewall-rule" is very much a useless value, when you want to validate if a connection was allowed or denied.
Many Syslog messages from ASA do have actual action values present, so it would seem logical to also include those in event.action.
This is a quite important request when you are trying to make exceptions for threat indicator matches in the Security module.
This is about an integration, provided by Elastic and it is a request to improve ingest pipeline logic. Obviously, I could write one myself, but since this is OOB, I do believe that Elastic is responsible for correct parsing.
Ok, yes just wanted to make sure we are talking about the same thing. You should be able to modify the ingest pipeline as needed. I've had to do that for some of our cisco asa rules. If you think you've found a bug in that pipeline I'd recommend opening up an issue through git hub.
You need to open an issue in the Integrations repository, this one to see if this is an error in the parsing or a feature request.
The ingest pipeline for the Cisco ASA integration will populate the field event.action with values direct from the message or using conditionals based on the message id, but there are more than those 4 values you mentioned.
Basically the value firewall-rule is only added if the field with the message id is empty:
The majority of ASA logs that we receive from customer are for below event codes:
710005
305011
305012
302013
302014
302015
302016
302020
106023
The complaint mostly stems from the fact that ingest pipelines for most other firewall brands process the "action" for a traffic log in field event.action, which is good for our case, because we process logs for many firewall brands and prefer that all fields contain similar values universally. Sadly, the ingest pipeline for Cisco ASA is just not doing that.
After having taken a look how ASA logs are processed, i see that some of the status values are filled into field event.type with some comparable value, which sometimes is straightforward, like a denied or allowed, but when it sais info, that does not compute, because "info" is not an action. looking at the message itself for most cases it looks that when info is mentioned this is comparable to an allow, so we can work with that.
Also, while we are busy, for event code 302016 the values of source and destination IP and ports are switched around, but when you look at how the events message text is written, this confusion is understandable. (From other discussion posts, I have found this is already being suggested before)
I would say that this is because the majority of the parsing on the integrations are community contributions from people that were using Filebeat Modules and now Elatic Agent, so the effectiveness of the parsing pipeline will depends on the contributor use case, which may be different from other use cases.
In some cases the fields will be populated with generic information until someone else contributes improving it or open a feature request providing some sample data so Elastic can look on it.
In this case the best way would be to open an Issue on Github with the Cisco Event codes that do not have event.action or just have generic ones like flow-creation and flow-expiration and provide some sample messages for Elastic to analyze.
The event.type field is one of the categorization fields that elastic uses in the SIEM and Alerts modules, it will not match the value of event.action and Elastic recommend to limit the values for this field to the allowed values.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.