Oracle Security Blog

The Data Mover allows for total manipulation of data within PeopleSoft. You can use it to transfer data among PeopleSoft databases, regardless of operating system and database vendor. To state that Data Mover scripts need to be carefully secured is an understatement – the security of Data Mover scripts and activities must be HIGHLY secured.

When performing a PeopleSoft security audit Integrigy carefully reviews batch processing activity generated through the Process Scheduler. Of particular focus is who has access to administer the Process Scheduler and reviewing batch jobs to identify where jobs are being run with super user privileges.

To look today at your environment for who has access to manage the Process Scheduler, the following can be used:

When performing a PeopleSoft security audit, reconciling users should be one of the first tasks. This includes default accounts created through the installation of PeopleSoft as well as user accounts associated with staff, vendors and customers.

The following are several of the topics that Integrigy investigates during our PeopleSoft security configuration assessments - take a look today at your settings:

Jolt along with Tuxedo supports PeopleSoft web requests. Specifically, Jolt is the layer between the application server and the web server. It is also described as a Java-enabled version of Tuxedo.

When performing a PeopleSoft security audit, Integrigy reviews in detail the PeopleSoft Jot security settings to ensure they are set per best practice recommendations.  To do this yourself, use the table below to review your settings. These settings should also be regularly reviewed to ensure against configuration drift.

When performing a PeopleSoft security audit, Integrigy reviews in detail the PeopleSoft Web Portal security settings to ensure they are set per best practice recommendations.  To do this yourself, use the table below to review your settings.

These settings should also be regularly reviewed to ensure against configuration drift.

Protection of sensitive data while at-rest, in-motion or in-use all need to be addressed as part of a holistic security strategy. This includes both Personally Identifiable Information (PII) as well as sensitive PeopleSoft system configurations.

When performing a PeopleSoft security audit, Integrigy reviews the use and implementation of encryption within all components of the PeopleSoft technology stack. This includes the following, all which are critical. Review yours today and contact Integrigy with any questions.

PeopleSoft Public users are not required to authenticate (sign on). These are generic accounts created for specific purposes, for example informational pages and/or company directories. Public users are also not subject to timeouts (session inactivity). Because no authentication is required, no sensitive data should be accessible to these users. It also goes without saying, that if you don’t need Public accounts, don’t use them.

Oracle has released support for TLS 1.2 in Oracle E-Business Suite 12.1 and 12.2.  Previously, Oracle E-Business Suite only supported SSLv3 and TLS 1.0, which are no longer approved for use with Federal systems and are not PCI-DSS compliant as of June 2014.  For TLS 1.2 support, new My Oracle Support (MOS) documents are available:

Enabling TLS in Oracle E-Business Suite Release 12.2 (Doc ID 1367293.1)

Enabling TLS in Oracle E-Business Suite Release 12.1 (Doc ID 376700.1)

Being hospitable and welcoming to guests is usually considered good manners.  That said, being a gracious host does not mean you should be careless with your security.

With regard to PeopleSoft application security, the user GUEST is a default account created with the installation of PeopleSoft.  When performing a PeopleSoft security audit, several attributes of the GUEST user are reviewed, including the following -  take a look today at your settings:

For the GUEST user:

When performing a PeopleSoft security audit, reviewing what rights and privileges individual users have been granted for system and application security privileges (authorization) is one of the key deliverables. The following are several of the topics that Integrigy investigates during our PeopleSoft security configuration assessments - take a look today at your settings:

Review users with access to

Securing the PeopleSoft Integration Broker (IB) ensures the security of messaging both within PeopleSoft applications and among third-party systems. The following are several of the key tasks that Integrigy performs during our PeopleSoft security configuration assessments - take a look today at your settings:

Logging and auditing are one of the pillars of PeopleSoft Security.  Both application and database auditing is required. Logging and auditing support a trust-but-verify approach which is often deemed required to secure the activities of privileged system and database administrators.

While both the application and database offer sophisticated auditing solutions, one key feature Integrigy always recommends is to ensure that EnableDBMononitoring is enabled within the psappssrv.cfg file. This is set by default but we at times find it disabled.

PeopleSoft, similar to other major ERP applications, while depending on a database to store information, arguably does not secure the supporting database. The security of the database is the client’s responsibility.

In order to give a few examples of what we are talking about when we refer to database security, the following are several of the 200+ database security checks that Integrigy performs during our PeopleSoft security configuration assessments - take a look today at your database for a few quick checks:

The prior blog post (PeopleSoft Security Patches) reviewed PeopleSoft CPU patching. Worthy of its own post is the October 2014 CPU. A show of hands back in April at our PeopleSoft database security presentation at Collaborate 2016 (PeopleSoft Database Security) further confirmed Integrigy’s research that a surprising number of PeopleSoft installations have not applied this patch.

The process of applying security patches starts with identifying which patches to apply. For PeopleSoft, security patches need to be considered for both the application and the major technical components. The application of security patches, referred to by Oracle as Critical Patch Updates (CPUs), for one component DO NOT apply security patches for the other components.

For example, PeopleTools CPU patches DO NOT include database CPUs – applying one will not automatically apply nor include the other. The same holds for WebLogic and Tuxedo CPU patches.