RSA Netwitness Parsing order

[ShishirKumar1]

While going through the logs, I identified that few of the event sources are being identified as multiple event source types.

For example, an event source from linux was identified as aix,bigip, ciscorouter, junosrouter, oracle, tippingpoint, bigipapm, cisconoxos.

I had to hard tag it to the rhlinux log source type. But as we have a huge environment, identifying and hard tagging each device type is going to be really an enormous task for us. I would like to know how RSA identifies which parser to use against which log source type.

I individually opened each of these parsers in the NW Log Parser tool and I could see each of them parsed the linux messages. This was a huge surprise for me, as I thought one log source type should not be able to parse logs from other types as the headers will be different . But the log source types mentioned above have a generic header which is common among all the parsers.

For example the log:

Jul 31 12:40:03 hostname sshd[24721]: Accepted publickey for root from 1.1.1.1.1 port 63255 ssh2: RSA 6ß:e5:c1:d0:55:b2:b7:aa:0c:2d:65:55:5c:a9:d5:f0 [MD5] can be parsed using any of these parsers referred above.

I would like to know if there is an alternative to hard tagging as in our environment we have lots of autodiscovered syslog and manually tagging them is going to be difficult.

[EricPartington]

Start with disabling any log parsers that you do not have in your environment.  This will reduce your problem space to just those devices that you expect to see.

Depending on your NW version, you may have to do more work in the 10.6 world to review the device.ip that have more than 1 device.type associated to them (create a report for this and review).  Then you would use the device mapping function to force those that have toxic combos to the right parser.  As you noticed there are many different device types that send very similar log formats that RSA NW cannot differentiate well (in 10.6 branch).

In NW 11 things get better for you.  There is an Event Sources tab which does the same mapping as in 10.6 world but also takes a better guess as to what the device type really is based on a large grouping of event sources from that IP  You can accept the matching from the system or you can override the ones that need extra help to map correctly.

The score is determined by header matching I think which gives a basic confidence in which device.ip is sending the logs. You can also order the parsers which will influence which parser of the set you determine for that IP matches first.

[DaveGlover]

Linux type messages are a challenge at times due to the fact that most of the devices you listed run a Linux base OS under the applications.  Bigip and oracle for example run Linux under the covers.

In an attempt to parse all of the messages from all those applications the base Linux OS messages are part of those parsers.

Like Eric said, the best starting point is to disable all parsers that are not in use.

Then after that you could start mapping devices to parsers.  I understand that in large organizations this can be a challenge, which is why reducing the inactive parsers is the best option to start with

[ShishirKumar1]

Thanks for the replies Eric and Dave. I would also like to ask your advice on what parser to use for unix logs. Should I use aix/rhlinux/solaris . I want to use one common parser for all linux based logs and build up on them. Would selecting 'rhlinux' be a correct approach for uniformity on the linux logs in my deployment?

Note: Asking this question, because each of these parsers, parse some logs and don't parse some. There is no one parser among these that parsers all the logs.

[DaveGlover]

You should use the parser that matches your product, as each has a message or two that is specific to that parser.

The is no "global unix" parser that will parse all messages from all flavors of Linux

[DavidEagen]

How can we script the parser assignments? With discovery essentially not working as it thinks everything is a ciscorouter, we have to specify mapping for each device. Doing that one by one for every device through the web UI isn't reasonable.

[ShishirKumar1]

Hi David,

I am doing it now for my environment and it is really painful. The problem arises when you have ciscorouter and rhlinux  logging on the same hybrid. Here hard tagging will also not help as I cannot disable one of these and netwitness will still assign any of these parsers randomly for any new logging hosts.

I wish headers were not common between these event sources. bigip, aix, rhlinux, ciscorouter and junosrouter have generic headers which is a problem

[RonaldRoskens]

Why would netwitness identify a RHEL 7 system with a higher score for being a ciscorouter device than a rhlinux?