4 Replies Latest reply on Oct 8, 2015 7:54 AM by cly

    Issues with the way Cisco ASA logs are Parsed with in ESM


      I am having an issue with the way ESM is parsing the Cisco event logs.  Below are my two example:


      1> The normal is the way I would expect the log to show up: Source IP/Source port to Desination IP/Destination port.


      Example of a normal message:

      <166>%ASA-6-302015: Built inbound UDP connection 23631055 for inside: ( to identity: (

      <166>%ASA-6-302016: Teardown UDP connection 23630994 for inside: to identity: duration 0:02:01 bytes 2954


      2> The backwards message has Destination IP/Destination port to Soure IP/Source Port.


      Example of a backwards message:

      <166>%ASA-6-302013: Built outbound TCP connection 23631580 for FiServ: ( to inside: (

      <166>%ASA-6-302014: Teardown TCP connection 23631580 for FiServ: to inside: duration 0:00:00 bytes 9455 TCP FINs


      I am initially wondering if there is a way to manually correct this issue?

      Should this be something fixed with in the ESM, there for requiring a request for improvement; or is this something that should be looked at on the Cisco end?




        • 1. Re: Issues with the way Cisco ASA logs are Parsed with in ESM

          Hello Chris,


          I have around 50 ASA's and I've recently deployed the McAfee SIEM. I haven't verified all the parsing so your question caught my attention.  However, looking at the subject of your post and the following data it is unclear to me what you are identifying as an issue with parsing.  I see your raw ASA log examples, but I don't see samples of the normalized data being assigned to the incorrect fields.  I searched for logs around Built inbound and Built outbound and reviewed the parsing of the IP addresses and it looked to be correct. I was unable to find events in my environment with Built outbound to inside. I filtered Direction outbound and Interface_Dest inside. I could only find Built outbound to the outside with filter Interface_Dest outside.  Would you clarify exactly where you feel the parsing is incorrect?





          • 2. Re: Issues with the way Cisco ASA logs are Parsed with in ESM

            I had reached out to some of my Cisco contacts and received the following response:


            "This goes back to relative security levels of ASA interfaces, and the differentiator is the “inbound” or “outbound” keyword; the lower-security endpoint is always listed first. In the first case, you have to-the-box connections which would always treat the initiator as the lower-security endpoint and the ‘identity’ interface as the higher-security one. This design goes back many years, and changing it now would only introduce more confusion."

            seymoursiem  - Working on more details.

            • 3. Re: Issues with the way Cisco ASA logs are Parsed with in ESM



              I know you want it to parse correctly, but if you don't need the data for correlation  you may just want them filtered.  After I replied to your post I came across a forum document to do this very thing.  The example they used was the ASA built and teardown events.  This leaves the events in the ELM for audit purposes, but filters it from normalization and reduces the noise.   SIEM Foundations: Filter Out Low-Value Events



              • 4. Re: Issues with the way Cisco ASA logs are Parsed with in ESM

                Hi, I know I'm a bit late with this reply, but I had a similar question and posed it to Support. The ultimate response was that I didn't know what I was doing and that the parsing rules were working as designed. On one hand I can see their logic, but for investigative purposes it still seems backward. So, our options are "deal with it" or "filter them out". (still send to ELM for raw logs and history).


                Brief Description: Parser Rule: PIX_ASA Tear Down TCP Connection; source and destination info are reversed.

                     R-destination and source ports and addresses are incorrect

                     T-The ‘STOP’ portion of the connection, the Destination and Source IP addresses and Ports field assignments are correct. On the ‘START’ part they are reversed (incorrect), and makes it look as if the external address is coming into the corporate network. See attached.



                     C-misunderstanding of parsing rule

                     S-rule working as expected