A Third Tripwire device
We are using Tripwire 7.5 and have it set up in enVision as both Tripwire Enterprise and Windows NIC. However, the Tripwire server shows up in enVision as a third, UNKNOWN, device. The data coming from is during the same time that we receive the updates from the Tripwire application, and consists only of the Date/Time and Device (IP). Does anyone have any thoughgt as to why this is happening, and if it should be reconfigured or left alone? I have deleted it a few times and it is always discovered again. The other two instances are working fine and collecting the expected data.
I've seen something similar to this before, not with tripwire but with several other event sources.
It sounds like perhaps there are unknown messages within the tripwire payload that can't be matched against the tripwire xml header definitions. In short, the tripwire .xml doesn't know how to interpret/parse them. If that's the case, and your tripwire event source (the one that's working fine) is set to "muti-device" then enVision will split off these unknown messages as a separate (3rd in this case) event source, and attempt to match them against all the other event source .xml's, looking for a match in all of their header definitions. If a match still can't be made, it will dump the device out as a new "unknown device" with a collection status of candidate (by default). You can delete that device, but in due time, you'll get it right back again.
What's interesting is that you indicated the only field present is the date/time and IP field. Where are you seeing this at? Is it in Event Viewer part of the GUI, or the Query page, or Event Explorer?
I've only seen blank line events once before when the logs contain carriage return line feeds (CR-LFs) at the end of the very last line of the log file, and depending on the collection method used (file reader in my case) it interpreted that as a new event, and the packager service would end up recording a blank line event. In effect, a date/time stamp, IP address, and a null message payload would get recorded one time after each log file processed. Not that this is what's happening in your case, but is there any correlation between the number of tripwire log files processed and the number of blank lines you're seeing?
There are ways to confirm that what I described above is in fact happening, that invloves unchecking "Multi-device", bouncing the collector service, and watching to see if the blank line events stay or move over into your tripwire payload as "unknown messages". Which, if that's the case you hang a left at Albuquerque and go down the "submit unknown messages to RSA" path because tripwire is an out-of-box factory supported event source from RSA. They need to be put on the hook to fix their header definitions.
On the other hand, if you're interested in doing all the debugging yourself and just handing them the fix (not that I've done that a billion times either) another less impacting approach to your production environment involves exporting a sample of all logs from that source IP (this would include windows, tripwire, unknown) via lsdata.exe, modifying the IP address manually to something fictitious and not already in use, and then reinjecting them in a looping pattern via injector.exe to see how the discovery process treats them under different conditions. This is a handy technique BTW for anyone who doesn't have their own development/test enVision platform to test on.
Regardless, its likely nothing to be overly concerned about, so long as there's no content in the payload.
Thanks for the input. This gives me a lot to think about. I'll spend some time on it at a later date and see, but I think you may be on track about the blank line at the end. I do remember seeing a message referring to "unexpected end of file" or something like that when I ran the nicsftpagent from command line.
The "unknown device" is only sending Date/Time and Device IP. The event is blank. This is as I view it in Event Viewer. Since this shows no event information, I'm confident I'm not missing anything. That being the case, I won't worry about it too much for the time being. When I have more time, I'll try to resolve it on my own. If I can't, I'll submit it to RSA.
I'm actually working on another project which involves expanding the use of both enVision andTripwire, so I'll be getting a lot more exposure to both of them. That should help. The Tripwire server has been seriously under-utilized and not really maintained since it has been here, so it has been handed off to me to learn it and "whip it into shape". It may be that there are some configuration issues in Tripwire, though I tend to doubt that. We have just a few basic integrity checks in there right now (though I have found some pretty neat stuff I want to try out!).
If I figure it out, I'll let you know.