Blocking Executables from an Oracle DB
The trigger is designed to restrict access to only the ‘allowable’ programmes, and then validates the session information against specified Windows/Linux/Unix accounts. Additionally, if the executable is renamed in an attempt to disguise the programme, the trigger will not be able to identify the executable and immediately terminate the user’s session. If the database account has ‘admin’ options, the trigger will not terminate the session, but will record the session in an audit table, along with broadcasting an email with the connection information.
The database trigger basically identifies the session’s programme executable, and then validates the value against a list of values that resides within the OMON_TOOLPRIV_HDR and OMON_TOOLPRIV_DTL tables respectively. The rollout of this trigger and the account security maintenance is very simplistic, and is designed to reduce it’s footprint on the database by keeping most of the objects in a separate tablespace. Step 1: Create a tablespace for the table and index objects to reside. All of the objects can be created with the SYSDBA account, as the only the trigger is recommended to reside in the SYS schema.
Step 2: Create the Email header and detail tables for the recipients
Step 3: Create the Tool Privilege header and detail tables for the executables and accounts that are authorized to run the executables
Step 4: Create the audit table for recording all ‘validated’ or offending programmes
Step 5: Create the database trigger that will perform all the needed tasks. It is preferred that this trigger is created and managed by the SYSDBA account.
Building upon the generous contributions of the Oracle community, this database trigger was designed to provide companies with SOX and ICE related information regarding any 3rd party tool’s access to a given database.