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?
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.
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
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