Adding the "SQLtext" column to the enVision Oracle parser.

[HarootZarger1]

Hi, We have a requirement to add the "SQLText"column in Oracle for auditing purpose.The SQLText column display the exact command that was entered by the DB admin form auditing point of view. By default the Oracle query in Envision doesn't have the read function for SQLText. After modifying the default ODBC Type 'data query" I was able to add the SQLText column to it. Once this modification was done my Oracle device type started to turn as Unknown (Assuming that it couldn't match the default parser ). Now I am planning to use the ESI tool to create a new parser using the existing Oracle xml file.The main challenge here is to identify the exact Oracle fields as most of them appear to be numeric or null but then on Envision they are replaced with the exact definition. Has anybody faced a similar situation or had the same requirement? Regards, Haroot

[ScottPause]

Haroot,

   Where to start?  So, sounds like you understand some of the underbelly of enVision.  This type of customization is quite dangerous.

1.  RSA does have some type of support for merging custom messages into an existing (supported) device type.  I've seen it work (or at least try to).  I wouldn't want to rely on it if its still maintained/supported.

2.  RSA does NOT support modifying the sql tables that you've found.  As a matter of fact, they don't even back them up when they make changes to them!  Before we proded RSA they didn't even know how the parsing ordering or messages worked!  Yikes!  And we were working with their experts on this subject.

3. My company implemented a custom set of messages to Unix and Oracle by modifying those Device XMLs.  It was a total disaster for our SIEM in the past 4 years.  Any ESU would break them, and resulted in zero changes to enVision in that time frame.  We recently (last June) finally completed a long project to separate out our customizations into their own custom devices.  This has finally allowed us to use the platform as a SIEM, as opposed to a glorified reporting engine for Compliance.

So in summary, customizations to built-in devices are possible, but a VERY bad idea.  You are much better off implemeting a new custom device type for just the messages that you care to modify.  Then implement them as multi-device (and setting the parsing order via SQL db) for the systems you want to.  You can use any fields present in ANY single SQL table, but the table chosen affects where you look for the resulting messages.