Can Symantec Critical Systems Protection SCSP monitor transactions in an Oracle table, such as sys.aud$ table?

Article:HOWTO58929  |  Created: 2011-08-10  |  Updated: 2012-03-27  |  Article URL
Article Type
How To

Q: Can SCSP monitor transactions in an Oracle table, such as sys.aud$ table?

A: No, SCSP does not provide a native mechanism to directly monitor database tables. This is on the enhancement list for future detection collectors. However with some simple script code (either internal to Oracle or an external program) to monitor the audit table (or any other table) and record actions of interest to a flat file, SCSP can be used to monitor a table.

The following approaches can be used to monitor transactions in an Oracle table:

Logic embedded inside Oracle database

  1. “Inline” operation—Use a trigger to intercept writes to the sys.aud$table (or any table) and write the contents of the record to a flat-file. For this approach I would recommend a separate, asynchronous function (such as an Oracle message queue or JOB) to write the actual flat file data so that the file I/O does not interfere with the main database insert operation in anyway. This will provide near real-time recording of database activity to the flat file. The code for this would be less than about 20 lines. (I can provide example code of this or the other approaches if you intend to pursue this).
  2. Scheduled “collection”— Submit an Oracle JOB that periodically monitors the table (or tables) of interest and records any data changes to the flat file. This is very straightforward to do for “insert” only tables such as sys.aud$table. Just keep a pointer to the last highwater mark and when the job runs the next time it extracts all newly added rows and records them to the flat file. This approach can be more efficient than the inline trigger method, however, the timeliness of recorded data is directly related to the collection time interval. A 5-minute interval may be too long for the customer while a 1-second interval may be too inefficient. This trade off is something the customer has to determine.

An advantage of both of the above approaches is that they are internal to the database – this means it is self-contained, operating system independent, uses the security domain of the database (without needing run-time passwords) and can be more efficient than an external process. The disadvantage is that if you want to monitor 10 separate databases you have to insert this code into all 10 systems.

 External data collector

A second approach is to develop a lightweight client program or script that performs the “scheduled collection” as described in item 2 above but the code resides outside the database domain. This is similar to how SSIM or Arcsight provide their data collection functionality. A small agent periodically monitors one or more tables in a database for new data. The agent persists in a properties file (or in a database table) the “pointer” to the last retrieved row of data. Upon every polling interval the agent or script retrieves all the new data posted beyond the pointer and then persists the new pointer value. This collector can be as simple as a small BAT or UNIX shell script running SQL*Plus that is controlled via Windows Task Manager or a UNIX cron job. Of it could be a small multi-threaded client app using ODBC or JDBC to access one or more databases on a scheduled basis.

One advantage of this approach is ease in quickly monitoring many different databases by simply knowing the tables of interest and the necessary login credentials. The downside s keeping track (and the possible exposure) of login credentials for each database to be monitored, requiring network connectivity to the databases of interest and taking on the operational burden of task scheduling issues.

In either the database internal or external.

Article URL

Terms of use for this information are found in Legal Notices