Securing Your PeopleSoft Application

PeopleSoft applications are depended upon to deliver data in a secure, reliable fashion. Data integrity, confidentiality and availability must be maintained. PeopleTools must be installed and maintained in a manner that prevents unauthorized access, unauthorized use, and disruptions in service.

The purpose of this chapter is to describe the requirements for installing and operating PeopleTools in a secure fashion, to maintain the security integrity of PeopleTools and the application software. This chapter applies to all individuals who are responsible for installation of new software, operation of existing software, and security administration.

Before a PeopleSoft application is put into production, you should take reasonable steps to ensure that PeopleTools security has been hardened. Through the appropriate use of PeopleTools authentication, authorization, and audit functionality, you can help mitigate risk to your security infrastructure.

The hardening procedure is a group of tasks that should be completed in order to harden PeopleTools. Many of these items are industry standard best practices; others are specific to PeopleTools. This list is by no means exhaustive; however, it should give you a feel for items to check. Some of the general steps included in the PeopleTools hardening procedure include:

  • Deleting or disabling unused user IDs.
  • Setting security parameters.
  • Enabling audit logging.
  • Appling security patches to keep software properly updated.

     

    Delete or Disable Unused User IDs

    Every delivered PeopleSoft database comes with several default User IDs. Before migrating a database into production, it is critical that you identify these IDs and either delete or disable them.

    To delete a user profile:
  1. Select PeopleTools, Security, User Profiles, Delete User Profiles to access the Delete User Profile page.
  2. Make sure that you have selected the correct user profile. 
  3. Click Delete User Profile to remove information related to this particular user profile that appears in PeopleTools, application tables, and every security table in the system. 

    To disable a user profile:
  4. Select PeopleTools, Security, User Profiles, User Profiles to access the Find Existing Values page.
  5. Select the user ID that you want to disable.
  6. Select the Account Locked Out checkbox to disable the user profile. The user can't sign on until you clear this check box again.

     

    Enable Password Controls

    If you're using PeopleSoft user ID and password authentication, you are strongly encouraged to enable password controls and follow industry best practices with regard to the settings. You use the Password Controls page to set password restrictions such as duration or minimum length of a password that you might want to impose on your end users.

    Select PeopleTools, Security, Password Configuration, Password Controls to access the Password Controls page.

    Here are the available options:

    Enable Signon PeopleCodeSelect this check box to enable the Age and Account Lockout password controls. The other password controls are not enabled by this field. 

    If you don't want these password controls, when for example you already have a third party utility that performs equivalent features, leave this check box cleared. 

    Note. You can extend or customize the controls by modifying the PeopleCode.
    AgeYou define a number of days (between 1 and 365) that a password is valid. To do this, select the Password Expires in N Days option. Users signing on after a password expires must change their password before they can sign on. If you don't want the password to expire, select Password Never Expires. When a password expires, the user can't sign on to the system and will be prompted to change it. 

    If you want to specify a period during which the system warns users that their password is about to expire, you have the following options: 

    • If you want to specify a warning period, select Warn for N Days, and enter the number of days in the edit box. 
    • If you don't want any warning period, select Do not warn of expiration. 

      PeopleSoft delivers a default permission list named PSWDEXPR (Password Expired). When a password expires for a user, the system automatically revokes all of that user's roles and permission lists and temporarily assigns them the PSWDEXPR permission list only. 

      A user whose password has expired can access only items in the PSWDEXPR permission list, which typically grants access to the Change Password component only. For the duration of the session, until the user changes the password, the user is restricted solely to the PSWDEXPR permission list. 


      Note. The actual user profile stored in the database is not changed in any way when the password expires. You don't need to redefine the profile. When the password is changed, the system restores the user profile's previous roles and permission lists.
    Account LockoutThis control enables you to lock an account after a specified number of failed logon attempts. For example, if you set the Maximum Logon Attempts value to 3, and a user fails three consecutive logons, they are automatically locked out of the system. Even if they correctly enter a user ID and password on the fourth attempt, the user is not permitted to sign on. This feature reduces the risk of any "brute force" intruders into your system. It also provides a reminder to your end users to remember the password they choose. After the account is locked out, a system administrator needs to open the user profile and clear the Account Locked check box manually.
    MiscellaneousThe Allow password to match User ID control enables administrators to ensure that users don't use their own user ID as a password. This helps you to prevent hackers from guessing passwords based on a list of employee names.
    Minimum LengthAdministrators can opt to set a minimum length for passwords maintained by the PeopleSoft system. If the minimum length is set to 0, the PeopleSoft password controls do not enforce a minimum length on the user's password. This does not, however, imply that the password can be blank. When you create a new user or a user changes a password, the system checks this value. If it is not zero, the system tests the password to ensure it meets length requirements, and if it doesn't, an error message appears.
    Character RequirementsAdministrators can require a set number of digits or special characters within a password. Special characters, or "specials," refer to symbols such as # and @, and digits refer to numbers (integers), such as 1 or 2. 

    Here is the list of special characters you can include within a password:
    ! @ # $ % ^ & * ( ) - _ = + \ |[ ] {} ; : / ? . > <
    Purge User ProfilesThis setting enables you to purge the system of user profiles that have not been used in a specified amount of time. This aids in general housekeeping. In particular, if you maintain user profiles in a directory server, a row is still added to the PSOPRDEFN table for the system to access while the user interacts with the system. However, if that user is deleted from the directory server you still need to delete the row in PSOPRDEFN associated with the deleted user profile. 
    Note. The Application Engine program that performs this operation is named PURGEOLDUSERS.

    Expire Password At Next Login

    If you're using PeopleSoft password controls, we recommend you use this option to force users to change their passwords in the following situations: 
  • The first time that a user signs in to PeopleSoft.
  • The next time that a user signs in.
  • The first time that a user signs in after the system has emailed the user a randomly generated password.
    To set this option:
  1. Select PeopleTools, Security, User Profiles, User Profiles to access the Find Existing Values page.
  2. Select the user ID that you want.
  3. On the General page, select the Expire Password At Next Login checkbox.
    Note. To use this option, you must first enable the Password Expires in N Days PeopleSoft password control 

    Allow Password to be Emailed

    PeopleTools contains functionality that will enable users to receive a new password via email if they have forgotten their existing one. At some sites, the security administrator may not want passwords appearing unencrypted in anyone's email. You implement this feature using a permission list. None can use it, some can use it, or all can use it, depending on your implementation. Users who don't have the proper authority receive an error message if they attempt to have a new password emailed to them.

    To change this setting:
  4. Select PeopleTools, Security, Permissions & Roles, Permission Lists.
  5. On the search page, search for the permission list that you want to modify and select it.
    The Permission List component appears.
  6. On the General page, review the setting of the Allow Password to be Emailed checkbox.
    Note. that if the user is a member of at least one permission list where this checkbox is checked, then they will be allowed to have a new password emailed. 

    Review Sign-in and Timeout Security

    A user attempting to sign in to PeopleSoft enters a user ID and a password on the PeopleSoft Signon page. If the ID and password are valid, PeopleSoft connects the user to the application, and the system retrieves the appropriate user profile. 
    If the user attempts to sign in during an invalid sign-in time, as defined in the user's security profile, the user is not allowed to sign in. A sign-in time is an adjustable interval during which a user is allowed to sign in to PeopleSoft. For example, if a given sign-in time is Monday through Friday from 7 a.m. to 6 p.m. for a set of users, those users cannot access a PeopleSoft application at any time on Saturday, or on Friday at 6:05 p.m. 
    After a user signs in, he or she can stay connected as long as the sign-in time allows and as long as the browser doesn't sit idle for longer than the timeout interval. A timeout interval specifies how long the user's machine can remain idle before PeopleSoft automatically disconnects the user from the application.

    You specify both the sign-in times and the timeout interval using PeopleTools Security. The sign-in times are maintained on the Signon Times page of the permission list. The timeout settings are maintained on the General page of the permission list. These settings should be reviewed prior to moving a PeopleSoft application into production.

    Change the Access Password

    The PeopleSoft access ID is the RDBMS ID with which PeopleSoft applications are ultimately connected to your database after the PeopleSoft system authenticates the user. The access ID has all the RDBMS privileges necessary to access and manipulate data for an entire PeopleSoft application.

    Due to the privileges associated with the access ID, it is extremely important that you choose a strong access password (e.g., minimum length of 8 characters, including mixed case, numerals and/or special characters, etc.). Generally, we recommend that only your database administrator should know this password. In addition, we recommend that this password be changed periodically (e.g., every 30 days).

    To change an Access Profile password
  7. In Application Designer, select Tools, Miscellaneous Definitions, Access Profiles.
    The Access Profiles dialog appears.
  8. In the Access Profiles list, highlight the profile that you want to modify and click Edit.
    The Change Access Profile dialog appears. This dialog provides fields to enter the old password and the new password, and to confirm the new password for the Access Profile.
  9. Enter and confirm the new password.
    The Access Password is the password string for the ID. Confirm Password is a required field and its value must match that of Access Password. 
  10. Click OK.

     

    Change the Connect Password

    The connect ID is an RDBMS ID that's used to perform the initial connection to the database when an application server is booted, or during a two-tier connection. Although this ID only has select privileges on a handful of tables, we still recommend that you select a strong connect password, keep it confidential, and change it periodically.

    To change the connect password, you'll need to follow your RDBMS-specific instructions. After you've changed the password, remember that you'll also need to change it in your application server configuration and in Configuration. When specifying the connect password for an application server in the PSADMIN utility, be sure to select the option to encrypt it.

    If you have two-tier users, it's recommended that you set the connect password once in Configuration Manager and then roll the configuration out to your user community.

    Change the IB Gateway Properties Password

    The default username and password combination for accessing the Integration Broker gateway properties is administrator/password. This password should be changed prior to production.

    On the authentication page that protects gateway properties administration, there's a checkbox labeled Change password. Checking this box when signing in enables an administrator to change the default password to a password that follows stricter (for instance corporate policy) password guidelines.


    Review the Single Signon Configuration 

    PeopleSoft supports single signon within PeopleSoft applications. Within the context of your PeopleSoft system, single signon means that after a user has been authenticated by one PeopleSoft application server, that user can access a second PeopleSoft application server without entering an ID or a password. Although the user is actually accessing different applications and databases, the user navigates seamlessly through the system. Recall that each suite of PeopleSoft applications, such as HR or CRM, resides in its own database. 
    After the first application server and node authenticates a user, PeopleSoft delivers a web browser cookie containing an authentication token. PeopleSoft Internet Architecture uses web browser cookies to store a unique access token for each user after they are authenticated initially. When the user connects to another PeopleSoft application server and node, the second application server uses the token in the browser cookie to re-authenticate the user behind the scenes so they don't have to complete the signon process again. 
    Single signon is critical for PeopleSoft portal implementations because the portal integrates content from various data sources and application servers and presents them in a unified interface. When the users signs in through the portal, they always take advantage of single signon. Users need to signon once and be able to navigate freely without encountering numerous signon screens.

    Before a PeopleSoft application is migrated into production, it's very important to review the single signon configuration. For each database, you should review which nodes you're going to accept authentication tokens from. You do not want a production system accepting authentication tokens from an untrusted system (or a system it should not trust). To review your single sign configuration, select PeopleTools, Security, Security Objects, Single Signon to access the Single Signon page

    Here is a brief description of the items on this page:

    Expiration time in minutesYou need to set an expiration time for the tokens that this system accepts for authentication.
    Message Node nameShows the name of a trusted message node. In order to share authentication tokens between nodes, the nodes need to trust each other. By adding a node to this grid, you indicate that a particular node is known to the system and trusted. When a node is trusted, the local node accepts tokens issued by it.
    Local NodeIndicates whether the node is local or not.

    See also Enterprise PeopleTools 8.49 PeopleBook: Security Administration, "Setting up Digital Certificates and Single Signon."

    Use Strong Node Passwords or Use Certificates

    When you configure nodes for single signon, there are two authentication options: Password or Certificate. The more secure of these two is Certificate. If you choose to use Password, be sure to select a strong password and change it periodically.
    You set up node definitions using the Portal, Node Definitions component. The two options related to single signon are as follows:


    Authentication OptionDetermines how nodes in a single signon configuration authenticate other nodes in the same configuration. You have the following options: None. Specifies no authentication between nodes. 

    Note. This option conflicts with PeopleSoft Integration Broker. If you select None, PeopleSoft Integration Broker messaging will fail, as will Single Signon. 


    Password. Indicates that each node in the single signon configuration authenticates other nodes by way of knowing the password for each node. For example if there are three nodes (A, B, and C), the password for node A needs to be specified in its node definition on node A, B, and C. 
    Certificate. Indicates that a digital certificate authenticates each node in the single signon configuration. PeopleSoft recommends using certificate authentication for single signon. For certificate authentication, you need to have the following in the key store in the database for each node: 

    • A digital certificate for each node.
    • The root certificate for the CA that issued the node certificate.

      Important! For single signon, the alias for the certificate of a node needs to be the same as the node name. You must set up your digital certificates before you select Certificate as the authentication option.
    Default Local NodeThe default local node is used specifically for setting up single signon. This indicates that the current node represents the database you're signed in to. The options you set for single signon should be made in the default local node definition.

     

    Review Signon PeopleCode and User Exits

    Signon PeopleCode is delivered that allows you to enable directory-based authentication, password controls, and other functionality. In addition, signon PeopleCode and user exits can be used to customize the authentication process.

    Before putting a system into production, all signon PeopleCode and user Exits exits should be carefully reviewed and tested. Mistakes in this area could lead to serious authentication vulnerabilities.

    Please refer to Enterprise PeopleTools 8.45 PeopleBook: Security Administration, "Employing Signon PeopleCode and User Exits" for detailed information on this topic.


    Limit Usage of the PeopleSoft Administrator Role

    Generally, only a handful of users — perhaps even just one user — should have the PeopleSoft Administrator role. A user with this special role is authorized for virtually everything within the PeopleSoft system. It's essential to keep at least one user ID with this role so you don't end up in a situation where you're locked out of the security administration pages. You should choose a strong password for this user and change the password periodically.

    The Roles component includes queries that you can run to find out which users are associated with each role.


    Limit Access to Application Designer and Data Mover

    In a development system, it's likely that numerous users will have access to PeopleSoft Application Designer and PeopleSoft Data Mover; however, in a production system, access to these development tools should be strictly limited.

    Generally, these development tools should not be used in production. Rather, development should be done in a separate database, tested, and then migrated into production using the upgrade tools.

    Keep in mind that if someone has access to development tools in a production system, they have the ability to change virtually any data in the database. For example, with PeopleSoft Data Mover access or a SQLExec in PeopleCode, any SQL could be run against the database.

    To lock down access to the design tools, review the settings on the PeopleTools page of the Permission List definition.


    Limit Access to User Profiles, Roles, and Permission Lists

    In your production system, only your security administrator should have access to the user profiles, roles, and permission lists. If any other user has access to these components, it's possible that they could elevate their own privilege levels.

    Several queries are delivered for user profiles, roles, and permission lists that will give you a good picture of who has access to what. This information should be carefully reviewed prior to going live as well as periodically to ensure security policies and guidelines are being maintained.


    Limit Ability to Start Application Server

    On the General page of the Permission List component, there's a check box titled "Can Start Application Server?". This option should be enabled only for the user ID that's being used to boot the application server, otherwise it's possible that a rogue application server could be started.

    Can Start Application Server?Select to enable a user profile with this permission to start a PeopleSoft application server. This may be a user ID used solely for starting the application server. At least one of the permission lists associated with the user ID used for starting the application server must have this permission selected. 

    This user ID does not refer to the actual user who signs in to an application server and starts it by submitting the appropriate commands. Rather, this option applies to the user ID and password that you enter into PSADMIN (or PSAPPSRV.CFG) in the Startup section. This is the user ID that the application server uses to connect to the database. In many installations, the application server starts with an automated process, not by a user physically submitting the commands. 

    When you build an application server domain, one of the parameters an administrator enters is a PeopleSoft user ID (and password). These values are contained in a configuration file that BEA Tuxedo reads when the application server is started. The user ID stored in the file is the user ID that requires the "Can Start Application Server" option set in a permission list that it's associated with. 

    Note. This permission also applies to starting a PeopleSoft Process Scheduler server. Password controls don't apply for the user profile that's used to start the application server.

     

    Review Query Security

    Query is a utility that helps you build SQL queries to retrieve information from your application tables. For each Query user, you can specify the records they are allowed to access when building and running queries. 
    You do this by creating Query Access Groups in the Query Access Group Manager, then you assign users to those groups with Query permissions. Keep in mind that Query permissions are enforced only when using Query; it doesn't control run-time page access to table data.

    Query is a very powerful tool and thus query security should be reviewed very carefully prior to production. 
    Please refer to Enterprise PeopleTools 8.49 PeopleBook: Security Administration, "Implementing Query Security" for detailed information.

    Enable SQL Error Message Suppression

    SQL error suppression can be enabled by updating the PeopleSoft application server configuration file. This file, called psappsrv.cfg, can be found in the application server directory under the database-named folder. Add the following line to the file:

    Suppress SQL Error = 1


    Generally, you'll want detailed SQL errors during development; however, in a production environment it's best to suppress the SQL error messages. If attackers can manipulate SQL queries through parameters, input fields, or in specialized locations such as Query Manager, they can generate invalid SQL that causes the database to return an error to the application server. When the application displays this error, the attackers gain information about the underlying query structure, database type, table names, column names, and other useful information that could be used to launch more sophisticated attacks. Database attack is much more difficult when attackers must guess blindly at query structure and cannot view error messages to understand why specially constructed queries fail.

    Track Users' Login and Logout Activity

    PeopleSoft Security provides two audit logs which tracks users' signin and signout activity in PeopleSoft. Signout activity includes timeouts, browser closings and browser freezes. Access these logs by navigating to PeopleTools, Security, Common Queries. Select Access Log Queries, then one of the following logs:
  • Access Activity by User.
    View a single user's login and logout activity. This log includes a user's Client IP address, login times and logout times.


     
  • Access Activity by Day.
    View one or more days of all user logins and logouts. This log includes User IDs, Client IP addresses, login times and logout times. 

     
    Consider Auditing
    Part of any successful security strategy is auditing. PeopleTools provides two methods of auditing which you should review and consider using in your production system. For more information on the two alternatives, please see the following documentation:

    See Enterprise PeopleTools 8.49 PeopleBook: Data Management, "Employing Database Level Auditing."

    See Enterprise PeopleTools 8.49 PeopleBook: PeopleSoft Application Designer, "Creating Record Definitions," Creating User-Defined Audit Record Definitions.

SHARE

peoplesoft

  • Image
  • Image
  • Image
  • Image
  • Image
    Blogger Comment
    Facebook Comment

0 comments:

Post a Comment

Phaniraavi@gmail.com