Skip navigation.

Security Blogs

Coding in PL/SQL in C style, UKOUG, OUG Ireland and more

Pete Finnigan - Wed, 2015-05-20 01:05

My favourite language is hard to pin point; is it C or is it PL/SQL? My first language was C and I love the elegance and expression of C. Our product PFCLScan has its main functionallity written in C. The....[Read More]

Posted by Pete On 23/07/14 At 08:44 PM

Categories: Security Blogs

Integrating PFCLScan and Creating SQL Reports

Pete Finnigan - Wed, 2015-05-20 01:05

We were asked by a customer whether PFCLScan can generate SQL reports instead of the normal HTML, PDF, MS Word reports so that they could potentially scan all of the databases in their estate and then insert either high level....[Read More]

Posted by Pete On 25/06/14 At 09:41 AM

Categories: Security Blogs

Automatically Add License Protection and Obfuscation to PL/SQL

Pete Finnigan - Wed, 2015-05-20 01:05

Yesterday we released the new version 2.0 of our product PFCLObfuscate . This is a tool that allows you to automatically protect the intellectual property in your PL/SQL code (your design secrets) using obfuscation and now in version 2.0 we....[Read More]

Posted by Pete On 17/04/14 At 03:56 PM

Categories: Security Blogs

Twitter Oracle Security Open Chat Thursday 6th March

Pete Finnigan - Wed, 2015-05-20 01:05

I will be co-chairing/hosting a twitter chat on Thursday 6th March at 7pm UK time with Confio. The details are here . The chat is done over twitter so it is a little like the Oracle security round table sessions....[Read More]

Posted by Pete On 05/03/14 At 10:17 AM

Categories: Security Blogs

PFCLScan Reseller Program

Pete Finnigan - Wed, 2015-05-20 01:05

We are going to start a reseller program for PFCLScan and we have started the plannng and recruitment process for this program. I have just posted a short blog on the PFCLScan website titled " PFCLScan Reseller Program ". If....[Read More]

Posted by Pete On 29/10/13 At 01:05 PM

Categories: Security Blogs

PFCLScan Version 1.3 Released

Pete Finnigan - Wed, 2015-05-20 01:05

We released version 1.3 of PFCLScan our enterprise database security scanner for Oracle a week ago. I have just posted a blog entry on the PFCLScan product site blog that describes some of the highlights of the over 220 new....[Read More]

Posted by Pete On 18/10/13 At 02:36 PM

Categories: Security Blogs

PFCLScan Updated and Powerful features

Pete Finnigan - Wed, 2015-05-20 01:05

We have just updated PFCLScan our companies database security scanner for Oracle databases to version 1.2 and added some new features and some new contents and more. We are working to release another service update also in the next couple....[Read More]

Posted by Pete On 04/09/13 At 02:45 PM

Categories: Security Blogs

Oracle Security Training, 12c, PFCLScan, Magazines, UKOUG, Oracle Security Books and Much More

Pete Finnigan - Wed, 2015-05-20 01:05

It has been a few weeks since my last blog post but don't worry I am still interested to blog about Oracle 12c database security and indeed have nearly 700 pages of notes in MS Word related to 12c security....[Read More]

Posted by Pete On 28/08/13 At 05:04 PM

Categories: Security Blogs

Come See Integrigy at Collaborate 2015

Come see Integrigy's session at Collaborate 2015 in Las Vegas ( Integrigy is presenting the following paper:

IOUG #763
Detecting and Stopping Cyber Attacks against Oracle Databases
Monday, April 13th, 9:15 - 11:30 am
North Convention, South Pacific J

If you are going to Collaborate 2015, we would also be more than happy to talk with you about your Oracle security or questions. If you would like to talk with us while at Collaborate, please contact us at


Tags: Conference
Categories: APPS Blogs, Security Blogs

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:


Tags: AuditingSensitive DataHIPAAOracle E-Business Suite
Categories: APPS Blogs, Security Blogs

Integrigy Database Log and Audit Framework with the Oracle Audit Vault

Most clients do not fully take advantage of their database auditing and logging features. These features are sophisticated and are able to satisfy most organization’s compliance and security requirements. 

The Integrigy Framework for database logging and auditing is a direct result of Integrigy’s consulting experience and will be equally useful to both those wanting to improve their capabilities as well as those just starting to implement logging and auditing.  Our goal is to provide a clear explanation of the native auditing and logging features available, present an approach and strategy for using these features and a straight-forward configuration steps to implement the approach.

Integrigy’s Framework is also specifically designed to help clients meet compliance and security standards such as Sarbanes-Oxley (SOX), Payment Card Industry (PCI), FISMA, and HIPAA.  The foundation of the Framework is PCI DSS requirement 10.2.

Integrigy’s Log and Audit Framework can be easily implemented using the Oracle Audit Vault.  The high-level summary is a follows –

Level 1

Enable database auditing as directed by the Integrigy Framework Level 1 requirements. 

Level 2
  1. Install the Oracle Audit Vault.  If already installed, it is highly recommended to perform a health check as described in Audit Vault Server Configuration Report and Health Check Script (Doc ID 1360138.1).
  2. Configure Oracle database to use Syslog per Integrigy Framework Level 2 requirements.  Set the database initialization parameter AUDIT_TRAIL parameter to equal ‘OS’ and AUDIT_FILE_DEST parameter to desired file in the directory specification.  Last set the initialization parameter AUDIT_SYSLOG_LEVEL to ‘LOCAL1.WARNING’ to generate Syslog formatted log files.
  3. Install and activate the Oracle Audit Vault collector agent OSAUD for operating system files.  Collect Syslog formatted logs located by the AUDIT_FILE_DEST parameter.
Level 3

Protect application log and audit tables by creating standard database audit policies and adding these new policies the Audit Vault Collectors.  Create database alerts based on correlations between standard database events and application audit logs.

Oracle E-Business Suite Example

To use the Oracle Audit Vault with the Oracle E-Business Suite, no additional patches required either for the E-Business Suite or the Oracle database.  This is because the Oracle Audit Vault uses only standard Oracle database functionality. 

There are two steps for Level 3.  The first is to protect the Oracle E-Business Suite audit tables, the second is to build alerts and reports that correlate application and database log information.  To protect the E-Business Log and Audit tables, enable standard auditing on them.  The second step is to define the Audit Vault alerts and reports.

Below is an example of event E12 - Protect Application Audit Data

The sign-on audit tables log user logon and navigation activity for the professional forms user interface.  This data needs to be protected.

  1. Enable Standard Auditing
  2. Create Audit Vault Alert
  3. Forward to Alert to Syslog (This feature is available as of Oracle AVDF version 12.1.2)

To enable standard auditing:






To create an alert in Audit Vault:

Audit Vault -> Auditor -> Policy -> Alerts -> Create Alert


Name: E12 - Modify audit and logging






If you have questions, please contact us at

Reference Tags: AuditingOracle Audit Vault
Categories: APPS Blogs, Security Blogs