EAS-SEC. Oracle PeopleSoft Security Configuration. Part 10: Logging of Security Events

One of the most important aspects to ensure the PeopleSoft security is security event logging in place. In case of an incident (which is likely to happen since there are plenty of settings and it is difficult to control all of them), only the security audit that is configured correctly allows a company to discover the fact of an attack in due time and, perhaps, to respond to it. Besides, this security audit enables preventing cyberattacks in their early stages of collecting system data. If you collect events timely and analyze them with the help of techniques based on signature or machine learning for anomalies detection, you can both detect and prevent attacks quickly.

The security event logging system is complicated. It has a lot of different logs for each PeopleSoft component to store sensitive information. Taking into account all of the above, each component controls become vital. However, the control is not always centralized. For example, the password policies of WebLogic and PeopleSoft are configured separately as well as security event logging. This section contains four most critical logs.

Logging of table changes [EASSEC-PVAG-PS-31]

Description

In the PeopleSoft system there are three methods of data auditing:

1. Field Level Auditing is used when few fields needs to be audited in a record. The entire fields audit will be stored in a single record PSAUDIT.
2. Record Level Auditing allows you to have separate audit tables dedicated to one database record. It will be helpful to easily find the set of fields modified in a row in a particular record. It is also very useful when key fields might change itself due to the correction (Eg: Effdt in JOB).
   The Audit record should have the following fields:
   • AUDIT_OPRID
   • AUDIT_STAMP
   • AUDIT_ACTN
3. Database Level Auditing i.e. trigger-based auditing functionality is provided by PeopleTools Utilities as an alternative to the record-based auditing provided by Application Designer. This type of auditing is much better than record and/or field level auditing. It will audit changes made to any security table via Tools or any other mechanisms. Our record/field level auditing wouldn’t catch a change made via a SQL tool or COBOL, SQR, etc.

For Option 1 and 2, Audit captures changes of data for the online page. If the data is changed by any program using a SQL statement then Audit is not captured. As of Option 3, it covers both online and database changes of the transaction record.

Threat

With no direct table change logging, there is a risk of late or no response to potential unauthorized table data modifications, e.g. a malicious person may change the bank account value and commit fraud by money transfer to another account or change financial aid and student grades.

Solution

Best practise is to implement table change logging, especially Record level and Database level Audits.

Field Level Audit

Open the record definition and then Record Field Properties for any of the field for which Audit needs to be captured. In the Audit section, select the type of Action that needs to be audited.

For any change in the field, there will be multiple rows inserted in the Audit record.

Record Level Audit

Open the record definition and then Record Properties. You will find the section where you enter Audit Record Name and Type of Actions(Add/Delete/Selective/Change) which needs to be captured.

For any change done to the fields in the record, a row will be inserted into Audit record.

Database level Audit

There is navigation available in PIA to generate trigger script which is then executed in the database. This kind of Audit captures the changes done to the record at database level.

Audit record should start with AUDIT_XXX and should contain these fields as Key fields:

• AUDIT_OPRID — Captures Info on who changed the data;
• AUDIT_STAMP — Captures the TimeStamp;
• AUDIT_ACTN — Captures the Type of Transaction done (Insert/Delete/Update..);

Logging of PeopleSoft Integration Gateway activities [EASSEC-PVAG-PS-32]

Description

You can generate and view integration gateway logging data on on-demand basis for outbound requests in the Service Operations Monitor.

When on-demand logging is enabled in the Service Operations Monitor, the integration gateway creates log files corresponding to the transaction IDs of outbound requests, that is .html. Depending on the log level set, the standard integration gateway message log will also include the transactional message logging data. Data logged also contains the URL of the gateway performing the logging, including the transaction ID and IP address. If you have implemented inbound load balancing using virtual application server domains, this information will help you determine the gateway that is performing the logging.

Scroll through the integrationGateway.properties file until you find the logging section. The following line is sets the logging level (2 is the default):
ig.log.level=2

The logging levels are:

Threat

With no security event logging, there is a risk of late or no response to potential attacks on a gateway. The risk of a security breach is considerably increased by service vulnerabilities (e.g. CVE-2013-3821 and CVE-2017-3548) and exploits available on the Internet. It enables getting unauthorized access to the service and executing any OS commands.

Solution

To change Integration Gateway logging level, go to [PIA_HOME]\webserv\[DOMAIN]\applications\peoplesoft\PSIGW.war\WEB-INF directory and edit integrationGateway.properties in the logging section. Assign appropriate level of logging according with your company security policy. It’s recommended to use level 3.

Logging of HTTP access [EASSEC-PVAG-PS-33]

Description

In addition to logging and tracing options that PeopleTools provides, Web Server (WebSphere or WebLogic) offers a variety of tracing options. But HTTP access logging is configured in a particular web server in use.

Threat

If the security event registration is not maintained, there is a risk of delayed response (or its absence) to potential attacks with the HTTP protocol use. Most of the initial attacks to compromise the system are made by HTTP protocol such as SQL Injections, XSS, OS Command Injections and others. Forensic Investigations of an incident which are related to Internet attacks are almost impossible with these service logs disabled.

Solution

It’s recommended to enable HTTP logging in the particular Web Server.

WebLogic

To enable or disable HTTP access log:

1. Make sure the PIA server is running (WebLogic Server is starting).
2. Log on to the Administrative Console.
3. Open Server’s Logging configuration page.

• In the Domain Structure tree, expand Environment, and click Servers.
• Click PIA (or your custom server name) in the Servers list.
• Select the Logging tab, and select the HTTP tab.

• Click the Lock&Edit button.
• Select the HTTP access log file enabled check box to turn on the access.log.
• Modify the Log file name field if desired.
• Click Save and Activate Changes.

WebSphere

To enable HTTP access and error logging:

1. In the Administrative Console, select Servers, Server Types, WebSphere application servers, server1, and click the NCSA access and HTTP error logging link.
2. Enable HTTP access logging by selecting the options Enable logging service at server start-up and Enable access logging. The HTTP access logs will be written to PIA_HOME/webserv/profileName/logs/server1/http_access.log.
3. Enable HTTP error logging by selecting Enable error logging. The HTTP error logs will be written to PIA_HOME/webserv/profileName/logs/server1/http_error.log.

IDDA Logging [EASSEC-PVAG-PS-34]

Description

The PeopleSoft Instrumented Development Diagnostic Aid (IDDA) logger, enables gathering specific information about various areas within the PeopleSoft Internet Architecture and PeopleSoft Interaction Hub, including:

• PeopleSoft Internet Architecture processing;
• Integration Broker;
• Reporting, Report Repository;
• Portal;
• Caching;
• File processing;
• Security, authentication;
• Performance Monitor;
• WSRP;
• Jolt.

The IDDA functional categories are:

Threat

If the IDDA Logging is not maintained, there is a risk of delayed response (or its absence) to potential external attacks or internal fraud. An opportunity to carry out the Forensic Investigation after the fact of hacking is almost fully excluded, too.

Solution

To enable IDDA logging:

1. Select PeopleTools >Web Profile > Web Profile Configuration, and open the current web profile.
2. Select the Custom Properties page.
3. Add a new row, and enter these values:

Column	Value
Property Name	IDDA
Validation Type	Number
Property Value	The sum of the bit values of the functional area(s) you want to log. For example, if you wanted to log PIA (1) and Portal (8), you enter 9.

4. Click Save.
5. Restart the PeopleSoft site.

Further steps

After enabling four basic logs described above, implement the fine-tuned settings, e.g. detailed table lists with enabled table logging, details of security event logging in security audit logs, detailed event types in the PeopleSoft Integration Gateway log, etc. Also, their central collection and storage implementation should be accompanied with critical events analysis. Only then, you may add and analyze more detailed optional logs for each service, such as SYSAUDIT, Logging of PeopleSoft Process Scheduler Server events, etc.

The post EAS-SEC. Oracle PeopleSoft Security Configuration. Part 10: Logging of Security Events appeared first on ERPScan.