EAS-SEC. Oracle PeopleSoft Security Configuration. Part 8: Access control and SoD conflicts
PeopleSoft has multiple functional opportunities, which are implemented through programs, transactions, and reports. An access to these objects should be strictly regulated by defining user profiles, roles and permission lists as the access to critical actions (e.g. access to modify data or to read any tables) enables users to attack PeopleSoft systems in order to steal critical data or escalate their privileges.
Segregation of Duties (SoD) is a security method to prevent conflict of interests, i.e. to avoid two or more access rights which – being granted together – may increase the risk of fraudulent actions (e.g. a right to create and approve a Payment Order). SoD helps to segregate incompatible responsibilities, which give an individual a chance to commit fraud.
This category provides only 6 basic checks for this access control scope that covers the most critical access rights and relevant settings. Since SoD is based on business processes of an individual company (i.e. an individual method) and its configuration is the second step after assigning critical duties, we do not give a check for SoD in this issue.
PeopleSoft Administrator Role [EASSEC-PVAG-PS-22]
PeopleSoft Administrator is a powerful role that contains one permission list PSADMIN that gives full access to all menus and pages. Being undefined (unlike other roles), the PeopleSoft Administrator role cannot be viewed, edited, modified or cloned. It is hard-coded into every application. You will not find this role if you search for it in the roles component.
With the PeopleSoft Administrator role, a user gains full access to all menus, pages, component interfaces, web libraries, PeopleTools and everything that can be secured through roles & permission lists. If the PeopleSoft administrator’s authentication data was compromised, the adversary gets an unlimited access to the sensitive business data and processes.
The number of users with rights granted by the PeopleSoft Administrator role should be minimized. Roles should be assigned according to the principle of least privileges.
To delete the PeopleSoft Administrator role in a User Profile, go to tabs: Home > PeopleTools > Security > User Profiles > User Profiles and delete this role on Roles page .
Page Security [EASSEC-PVAG-PS-23]
Pages are individual screens that a user sees and interfaces with when using PeopleSoft. They allow users to access data in the database without performing SQL commands. Pages are contained within components, which are ultimately included into a menu name. Security within PeopleSoft is controlled by restricting users’ access to menu items or pages.
PeopleSoft delivers a number of default permission lists, such as ALLPAGES and HCPPALL (for PeopleSoft HCM), that provides the access to all pages.
Users with default permission lists, such as ALLPAGES and HCPPALL, have access to all pages of PeopleSoft application and can execute a variety of critical actions. If there is an authentication data compromise of a user with these permission lists, an attacker will access the system and his/her actions can seriously damage it. Also, if permission lists and roles are not assigned appropriately, an unauthorized access to data takes place here.
The user privileges should be specified according to the least-privilege principle. The access to default permission lists, such as ALLPAGES and HCPPALL, should be examined, and it is necessary to restrict access to them. The role and permission lists definition should be performed based on the access requirements of a job or a function (e.g. payroll manager) rather than on the user’s perception of his/her access requirements. It should also be noted that the greatest level of access is provided to the user when more than one permission list provides access to a particular page.
PeopleTools Permissions [EASSEC-PVAG-PS-24]
The PeopleTools Permissions section applies to stand-alone PeopleTools applications. They are not Pure Internet Architecture-based but are considered to be Microsoft Windows programs that were not developed using PeopleSoft Application Designer. They include:
- PeopleSoft Application Designer;
- PeopleSoft Data Mover;
- PeopleSoft Definition Security;
- PeopleSoft Query (Microsoft Windows interface, not the browser interface).
Users with access to stand-alone PeopleTools applications can execute various critical actions that can seriously damage the system. For example, a malicious user can edit PeopleCode leading to a change in business logic for PeopleSoft applications, modify Definition Security resulting in an unauthorized access to update critical objects or move PeopleSoft database causing the loss of valuable information.
Review the list of users with access to stand-alone PeopleTools applications and decide which of them really need these rights to perform their tasks. To change access rights in permission lists, go to the following tabs: Home > PeopleTools > Security > Permissions & Roles > Permission Lists on PeopleTools page and clear/select appropriate check box. These access rights are assigned to User Profile via the role.
Process Security [EASSEC-PVAG-PS-25]
Process within PeopleSoft may be a program, a batch job, a report, an interface transfer or any activity that requires performing numerous tasks within the system. Such processes are run and managed by the Process Scheduler within PeopleSoft. The access to run a certain process requires a combination of access to the Run Control page from where the process can be run along with the access to the Process Group to which the process itself is assigned. The access to the Run Control page is controlled in the same way as any other PeopleSoft page (see the check above). A batch process is assigned a process group when created, then that process group is linked to a permission list.
Users with process groups can execute a variety of critical actions, e.g. run system processes, archive processes or start/stop the Application Server.
Assign Process Groups appropriately to Permission lists and User Profiles following the need and tasks.
To change the Process Group in permission lists, go to the following tabs: Home > PeopleTools > Security > Permissions & Roles > Permission Lists on Process page. These access rights are assigned to User via Process Profile field in General tab of User Profile.
Query Security [EASSEC-PVAG-PS-26]
PeopleSoft provides the ability to run ad hoc queries to access data (in the form of SQL queries) in addition to the information generated via standard reports. This is carried out via the Query tool. It may be necessary to restrict access not only to the Query tool function, but also to the data records upon which queries are run. Query users should have access just to the information to which they usually access via menu options and pages. This is accomplished by setting up query access groups and linking to query trees and permission lists.
Users with incorrectly assigned query permissions can get unauthorized access to critical data, as a result, this data can be used for future attacks.
Assign Access Group Permissions and Query Profile appropriately to Permission lists and User Profiles according to the need and tasks.
To change Access Group Permissions and Query Profile in permission lists, go to the following tabs: Home > PeopleTools > Security > Permissions & Roles > Permission Lists on Query page. These rights are assigned to User Profile via the role.
Application Data Security [EASSEC-PVAG-PS-27]
Application Data Security is addressed with table, row security and field access restriction. It is additional security concept and configuration to be considered in relation to how data security is managed within the PeopleSoft application. This is the concept of security sets and aligned security access types:
- table level (for queries only)
- row level
- field level
If the Application Data Security is configured incorrectly, unauthorized users will access data for which they do not have rights. For example, a manager will have access to review personal data of employees from other departments, or employee will access data that is intended for managers.
Assign Application Data permissions in accordance with user functions. Application Data Security is implemented by using Application Designer, then assigned to User Profiles through Permission List in General tab in Primary or Row Security Permission Lists fields. For more detail settings, use the PeopleSoft Security Administration guide.
In the PeopleSoft PeopleTools, there are nearly hundred of such critical privileges, with each module (PeopleSoft HCM, FSCM, etc.) including the similar number. As mentioned above, these privileges sometimes overlap each other. It is under control of the SoD matrix. A standard matrix contains more than 200 different SoD patterns, while each company can use their own depending on the functional area. Before the SoD analysis, you should check default authorization values in access rights. These rights are often excessive and cause hundreds of various SoD conflicts.