Skip navigation.

Stephen Kost's E-Business Suite Security Blog

Syndicate content
Integrigy's Oracle Security Blog with information on security for the Oracle Database, Oracle E-Business Suite and other Oracle products.
Updated: 6 hours 32 min ago

Come See Integrigy at Collaborate 2015

Fri, 2015-04-10 08:39

Come see Integrigy's session at Collaborate 2015 in Las Vegas (http://collaborate.ioug.org/). 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 info@integrigy.com.

 

Tags: Conference
Categories: APPS Blogs, Security Blogs

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

Fri, 2015-02-13 06:00

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:

BEGIN

DBMS_FGA.ADD_POLICY (
   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 (
         SELECT PAX.PERSON_ID
         FROM PER_ASSIGNMENTS_X PAX, PER_JOBS J, PER_JOB_DEFINITIONS JD
         WHERE PAX.JOB_ID = J.JOB_ID
         AND J.JOB_DEFINITION_ID = JD.JOB_DEFINITION_ID
         AND UPPER(JD.SEGMENT6) LIKE UPPER(''%EXECUTIVE%''))
         AND NOT (SYS_CONTEXT (''USERENV'',''IP_ADDRESS') 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);

END;

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: mailto:info@integrigy.com

References

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

Integrigy Database Log and Audit Framework with the Oracle Audit Vault

Fri, 2015-02-06 06:00

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.

Steps
  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:

AUDIT UPDATE, DELETE ON APPLSYS.FND_LOGINS BY ACCESS;

AUDIT UPDATE, DELETE ON APPLSYS.FND_LOGIN_RESPONSIBILITIES BY ACCESS;

AUDIT UPDATE, DELETE ON APPLSYS.FND_LOGIN_RESP_FORMS BY ACCESS;

AUDIT UPDATE, DELETE ON APPLSYS.FND_UNSUCCESSFUL_LOGINS BY ACCESS;

 

To create an alert in Audit Vault:

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

 

Name: E12 - Modify audit and logging

Condition:

 :TARGET_OWNER='APPLSYS' AND :EVENT_NAME in ('UPDATE','DELETE') AND :TARGET_OBJECT in ('FND_LOGINS','FND_LOGIN_RESPONSIBILITIES','FND_LOGIN_RESP_FORMS','FND_UNSUCCESSFUL_LOGINS')

Example:

 

                             

If you have questions, please contact us at mailto:info@integrigy.com

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