IBM i Privileged Access Management (PAM) Specifications

IBM i Privileged Access Management (PAM) solutions have various levels of flexibility for implementation and integration with existing applications and ticketing systems that need to be considered before purchasing. Assessing your IBM i Security requirements for implementation will be key to ensuring the IBM i PAM solution you choose meets your all your use cases, as well as environmental and compliance requirements.

First note, Privileged Access Management (PAM) terminology used by most technology sectors and compliance regulations refer to processes more commonly known on the IBM i (iSeries AS400) platform as Profile Swapping and Adopted Authority procedures. Terminology aside, the goal of PAM is to limit the number of powerful profiles (user IDs with excessive special authorities, powerful user classes and users with no or partial capability limits) on the IBM i to a bare minimum, and only temporarily grant elevated authorities (privileges) to user profiles with a specific need (use case) to complete a task or provide access to sensitive data which is outside their normal duties in a controlled, permissions based manner. Other companies start using PAM simply because they want to stop wasting time giving out passwords for powerful profiles on a regular basis. There are a number of ways to grant privileged access authority for IBM i users which are much more granular than Open platforms, and each PAM solution has different capabilities that will determine the success of your implementation.

In general, all IBM i PAM solutions should be able to control which menus and commands users can access, as well as which actions they can take for specific objects or files. When a user is performing a profile swap or adopted authority, an extensive audit trail should be captured in the system journal, as well as possibly screen captures in some instances. Ideally, Privileged Access Management functions should be automated, seamlessly integrate with both internal and external applications, and without disrupting to existing processes.

You should always do a trial or POC of the PAM solution before you purchase to ensure it will deliver the functionality you need for successful implementation and features work as advertised. IBM i Privileged Access Management (PAM) specifications to consider for a successful Implementation may include the ability to:

• Integrate with Ticketing Systems, enabling end to end management
• Integrate with SIEM and SYSLOG Servers
• Invoke a *SWAP and/or *ADOPT
• Control access to menus
• Control commands that can be run
• Control actions Users can take
• Control network application servers like ODBC, JDBC, DRDA and FTP (exit points)
• Control amount of time elevated authorities may be used
• Automate rules based on source User ID’s group profile, supplemental group, special authorities, using list of users and command line access
• Automate rules based on day of the week, date range, time range, job name, IP address, IASP, Program
• Provide user initiated, on demand emergency access, commonly referred to as “Firecall”
• Initiate *JOB option to log all user activity without changing the user’s authorities
• User reason for using elevated authority
• Capture complete audit trail: job logs, screen captures, exit points, system journal, database journals, SQL Statements, etc.
• Integrate with Multi-Factor Authentication (MFA)
• Reports and automated distribution
• Customizable Alerts

Note: Some environments may require the use of Multi-Factor Authentication (MFA), and for a small handful of environments (where access is most sensitive in nature), the “Four Eyes” principle may be required for supervised changes.

Profiles that are good candidates for limiting authorities likely include User IDs with the following Special Authorities:

*ALLOBJ - Access to all IBM i resources, and authority to all functions on the system.
*SECADM - Able to create, change and delete user profiles. Users with *SECADM and *ALLOBJ can give *SECADM to another user.
*JOBCTL - Stop subsystems and perform an initial program load (IPL).
*SPLCTL - Can perform any operation on spool files.
*SAVSYS - Can save, restore and free storage for all objects on system.
*SERVICE - Can display and change sensitive data, use service tools, debug programs with only *USE authority and alter service functions.
*AUDIT - Can stop auditing on the system and for users.
*IOSYSCFG - Can change system configuration, add or remove communication configurations and TCP/IP servers.

Your users should *ADOPT the minimum authority required by the application to perform their job functions. Adopting the authority of an application owner is more secure than adopting the authority of a user with powerful special authorities. Many companies without compliance requirements like SOX, PCI-DSS, HIPAA and GDPR are still implementing PAM due to auditor recommendations to minimize the number of powerful profiles on the system. Special authorities should only be provided on a “as needed” basis, or at a minimum based on requirements defined by the individual’s role and tasks they will perform on the system on a regular basis.

Almost every user profile on the system should have user class *USER, unless their role at the company dictates otherwise. Even then, it is highly unlikely any user on the system requires powerful special authorities provided by the user class on a full time basis. IBM’s defaults for User Class Special Authorities differ depending on the security level on the system, and many (if not most) systems have user’s with special authorities that do not match their user class. Likewise, Limit Capabilities values of both *PARTIAL and *NO should only be given “as needed, otherwise these users can change their initial program, initial menu, library, run commands and by-pass other system controls you likely do not want to permit.