1 ACCEPTED SOLUTION
Accepted Solutions
sorry, you are right, well the bad news is that RSA doesn't have too much information.
You have two roads, one is to create log parsers for devices not supported by RSA, you have to use the ESI Tool to create the xml and config files. And then upload the files to the log decoder. There is a post here called "Security Analytics Log Parser" you can take a look on how to upload those file to SA.
The other path is to modify the RSA parser (this is not supported)
There are some key files
table-map.xml
v20_eventsourcename.xml file
If it remember correctly they are inside this directory
/etc/netwitness/ng/etc/
The parser is inside a directory with the name
In the table map file you have the conversion variables from envision to SA. (yep it's correct) the parser is the same as envision. When a variable has transient flag it is not stored on the system, and when it's None it is stored on the system /this modification will affect all parsers that use that particular variable). It is recommended to use a table-map-custom.xml for all changes in that file.
When a log to SA is received it uses the log parser which has the envision variables and process the log according to the message id received, then translate the variables using table map so SA saves them on their respective meta.
if you want to modify any parser for any log device for example a variable is not parsing and you want it, you have to modify the variable used in the parser (usually RSA call the variables <field1>, <field2>...<fieldX>) so you have to change that to something the system saves (for example ec_theme, replace field1 for ec_theme) remember you have to modify using the envision variables not the SA variable (with the dot).
And the changes has to be done in each message id, I usually do a global replace with VI 
It's a very painful situtation but this is what it is.
Also what I do , it copy the message from the parser and the received from the event source into notepad, remove the ;> and < to the actual symbols and the replace them to commas, then save it as CSV and the open it in excel so it has every field separated by columns, and the compare that to see what field I have to change,
After that changes you have to restart nwlogdecoder service, if everything is ok, the log should tell you that the parser for the certain source is parsed is loaded correctly.
let me know if this helps....
sorry, you are right, well the bad news is that RSA doesn't have too much information.
You have two roads, one is to create log parsers for devices not supported by RSA, you have to use the ESI Tool to create the xml and config files. And then upload the files to the log decoder. There is a post here called "Security Analytics Log Parser" you can take a look on how to upload those file to SA.
The other path is to modify the RSA parser (this is not supported)
There are some key files
table-map.xml
v20_eventsourcename.xml file
If it remember correctly they are inside this directory
/etc/netwitness/ng/etc/
The parser is inside a directory with the name
In the table map file you have the conversion variables from envision to SA. (yep it's correct) the parser is the same as envision. When a variable has transient flag it is not stored on the system, and when it's None it is stored on the system /this modification will affect all parsers that use that particular variable). It is recommended to use a table-map-custom.xml for all changes in that file.
When a log to SA is received it uses the log parser which has the envision variables and process the log according to the message id received, then translate the variables using table map so SA saves them on their respective meta.
if you want to modify any parser for any log device for example a variable is not parsing and you want it, you have to modify the variable used in the parser (usually RSA call the variables <field1>, <field2>...<fieldX>) so you have to change that to something the system saves (for example ec_theme, replace field1 for ec_theme) remember you have to modify using the envision variables not the SA variable (with the dot).
And the changes has to be done in each message id, I usually do a global replace with VI
It's a very painful situtation but this is what it is.
Also what I do , it copy the message from the parser and the received from the event source into notepad, remove the ;> and < to the actual symbols and the replace them to commas, then save it as CSV and the open it in excel so it has every field separated by columns, and the compare that to see what field I have to change,
After that changes you have to restart nwlogdecoder service, if everything is ok, the log should tell you that the parser for the certain source is parsed is loaded correctly.
let me know if this helps....
