5 Things You Can Do Today To Secure Your PeopleSoft System - Part 1


I recently gave a presentation at the Pathlock Innovation Series entitled 5 Things You Can Do Today To Secure Your PeopleSoft System and I thought I'd follow up with a blog series on each thing.

The team at Pathlock (formerly Appsian, formerly Grey Heller) have some great products for PeopleSoft that can help improve the security posture of your system (SSO, MFA, Application Firewall logging and payload monitoring, etc).  I'm not on commission - I just really like the solid engineering behind their products and that they solve real world problems.

Thing #1 - Secure PeopleSoft System Accounts

In no particular order, THING #1 is to Secure Your PeopleSoft System Accounts.  These are the database users and PeopleSoft users that make your PeopleSoft system function.

There are a number of System Accounts and I've listed a few common ones here.  This is not a complete list but these are the ones I covered in my presentation.


Some security suggestions for these accounts below...

ACCESS ID

Don't give this high permission user to a human.  It's designed to allow the process scheduler and application server domains to connect to your database.  If a human logs in with the user then we have no idea who they are!   

  • Choose a strong password. Long passwords are much more secure than short obscure strings. (for example "mydoghasnonosebutstillsmells" is more secure than gibberish like "P#2q?f7".  A human eye thinks the one with special characters is more secure but to a computer a # or ? is no more complex than the letter "a" or "b".  Connect ID and Access ID lengths can be 32 characters according to MOS Doc ID 1345034.1
  • Create named database accounts for users who need direct database access.
  • Audit access id logins and report anything that's not a PeopleSoft service (ie did not come from an Application Server or Process Scheduler)

CONNECT ID

This has always been thought of as a low permission user. It's got access to just enough information to authenticate a user.  But, it also can expose every userid, user name, employee id and email address!  That's a lot of valuable information.

  • Don't use people for your Connect ID. Don't make this easy for a hacker.
  • Use long password (see above)... if you need convincing to use long vs short complex then read this and learn how to use words like entropy, hash, algorithm and troubador :-)

PTWEBSERVER User

This PeopleSoft user is used to read the Web Profile when the PIA boots up.  PeopleBooks link here and a useful Doc ID 622346.1

  • Change the default password (and make it long.... of course!)
  • Make sure it only has 1 role, "PeopleTools Web Server" (or PTPT1500 Permission List).   

App/Prcs Domain User

Used to start and run the Application Server and Process Scheduler domains.  

  • Long password.
  • Don't give this to a human.  They will only get the password wrong and lock the account. If the USERID locks then the App and Process scheduler domains will continue working until the PSAPPSRVs recycle or the domains are stopped and started and then they'll fail and no one will be able to login.
  • Don't use VP1 or PS. Way too obvious.
  • It doesn't need any Page or WebLib permissions but must have a Permission List which has the "Can Start Application Server" ticked ON.
     
  • Monitor wrong password attempts. You don't want this account to lock as you'll end up with a successful denial of service attack.

I hope this has been useful.  No one measure will secure your PeopleSoft system but maybe some of these thoughts will prompt you to implement some additional control, monitoring or audit measure.  

Greg Kelly (Product Strategy Director - Security, Oracle) recently posted a compilation of handy security references for delivered Roles.

Comments below are welcome and remember, these are just my views and opinions.  Would love to hear yours too.

Comments