Fine Grained Auditing (FGA) and Protecting Oracle E-Business PII Data for Executives

With the recent news about yet another database breach of Personally Identifiable Information (PII), Integrigy had a discussion with a client about how to better protect the PII data of their executives.

The following Fine-Grained-Auditing (FGA) policy started the discussion. The policy below will conditionally log direct connections to the Oracle E-Business Suite database when the PII data of corporate executives is accessed. For example, it will ignore E-Business Suite end-user connections to the database, but will catch people directly connecting to the database from their laptop. However, it will only do so if PII data for executives is accessed:


   object_schema     =>  'HR',
   object_name       =>  'PER_ALL_PEOPLE_F',
   policy_name       =>  'FGA_PPF_NOT_GUI_AND_OFFICER',
   audit_condition   =>  ' PER_ALL_PEOPLE_F.PERSON_ID IN (
         (''IP of your DB server’’, ‘’IP of your cm server’’, 
           ‘’IP of your application server’’) 
        AND SYS_CONTEXT (''USERENV'',''CURRENT_USER'') = ''APPS'' ) ',
   audit_column      =>   NULL,
   handler_schema    =>   NULL,
   handler_module    =>   NULL,
   enable            =>   TRUE,
   statement_types   =>  'SELECT',
   audit_trail       =>   DBMS_FGA.DB,
   audit_column_opts =>   DBMS_FGA.ANY_COLUMNS);


Here is an explanation of the policy above:

  • Audits only direct database activity and ignores database connections from the E-Business Suite user interface, the database server, the web and application servers, as well as the concurrent manager.
  • Audits SELECT activity against PER_ALL_PEOPLE_F or any view based on the table PER_ALL_PEPOPLE_F. PII data exists outside of PER_ALL_PEOPLE_F but this table is the central table within the E-Business Suite that defines a person and thus contains critical PII data such as name, birthdate and National Identifier.
  • Audits ALL columns in the table but could easily be restricted to only specific columns.
  • Audits ONLY those result sets that includes current or ex-employee whose job title has ‘%Executive%' in the Job Title. Note this policy was demonstrated using the Vision demo database. Your Job Key Flexfield definition will be different.
  • FGA comes standard with the Enterprise license of the Oracle database. If you own the Oracle E-Business Suite, you don't need an additional license to use FGA.

The policy above would certainly strengthen an overall database security posture, but it does have several immediate drawbacks:

  • While it does address risks with direct database activity, including the use of the APPS account from a laptop, it will not guard against privileged database users such as DBAs.
  • Spoofing of USRENV attributes is possible which precludes using any USERENV attribute other than the IP address and DB username.
  • Audit data needs security stored and regularly purged. Privileged users may have access to FGA data and policies. Audit data also needs to be retained and purged per corporate policies.
  • Lastly, the performance impact of the policy above would need to be carefully measured. If the policy above were to be implemented, it would need to be seriously tested, especially if modules are to be used such as Oracle Advanced Benefits and/or Payroll.

As part of a database security program, Integrigy recommends that all clients implement defense in depth. No one tool or security feature will protect your data. Oracle Traditional Auditing (TA) as well as FGA policies similar to the above should be implemented, but the both TA and FGA have limitations and trade-offs.

Integrigy recommends that both Oracle TA and FGA be used with database security solutions such as the Oracle Audit Vault and Database Firewall (AVDF), Splunk, Imperva, and IBM Guardium.  Database monitoring and alerting needs to be automated and should done using a commercial tool. You also need to secure and monitor privileged users such as DBAs and database security cannot come at the cost of overall application performance.

Our client conversation about the FGA policy above concluded that while the policy could work, given the variety of different database connections, a better solution would be to utilize a variation of the policy above along with Splunk, which they already own.

If you have questions about the sample FGA policy above or about database security, please contact us at:


 Share this post

Subscribe to RSS

Add us to your favorite news reader.

Follow on Twitter

Get the latest updates.