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.
