IBM i Authority Manager Auditor and Screen Capture

IBM i Authority Manager supervises powerful users via flexible policies that automates auditing, screen captures, assigning a ticket number, controls all aspects of user elevated authority sessions and distributes job logs and detailed activity reports after completion. An Authority Manager policy can automatically grant a profile SWAP or ADOPT authorities based on specific conditions automatically or after an approval from an administrator or multiple administrators. All context of a user’s profile, job, task and other environmental details can be used to trigger an elevated authority policy, including day of week, date and time range, job name, IP Address, commands, application, connection type and many other flexible variables. If a user profile already has the special authority and all that is required is a detailed history of the user’s activities, an Authority Manager policy can simply enable the detailed auditing. User activity and audit reports include screen captures, job logs, events from QAUDJRN and DB2 journals and SQL statement reports, are all distributed via email once the session ends.

User profiles possessing unneeded special authorities can lead to unmanageable security risks, especially if there are a significant number of powerful profiles on the system. Special authorities should only be provided to a user profile that has to perform a job function the special authority provides. Even then, the user likely is not performing the specific job function every time the user logs onto the system, and therefore the special authority should only granted when needed. The IBM i Authority Manager enables administrators to reduce the number of powerful users on the AS400, and control granting elevated authorities on an as needed basis, via flexible, automated policies, that manages the entire process, from when and how a user can initiate elevated authorities, real-time alerts, and distribution of screen captures, job logs, SQL Statement and security audit reports when the user session ends.

Allowing users access with special authorities, unabated, leaves the security of your IBM i system and data exposed. In fact, security and compliance auditors prefer that IBM i users be given only the authorities required to perform their jobs, and that they be granted additional authority only when needed and only for the time required. It is important to regularly analyze profiles and determine if the special authorities they possess are required for their everyday tasks, and remove any special authorities that are not necessary. User profiles that require special authorities should have additional auditing enabled and these users’ actions should be closely monitored. You should also frequently identify users possessing special authorities that do not match the user class, if profiles have Special Authority set to *USRCLS. You should also know which users have access to IBM supplied profiles and associated Group Profiles, and monitor for changes to IBM supplied profiles.

Limiting the number of powerful user profiles on your IBM i, reduces many security risks and is a common first step in most compliance initiatives. Profiles using special authorities should always have stricter monitoring and controls in place to ensure confidentiality, integrity and compliance. Without additional safeguards and oversight, there is no telling what powerful users are doing on your system. Take the time to regularly investigate the user profiles on your system, and take steps to improve the security posture of your system.

Assess which User Profiles have unnecessary Special Authorities, and ensure required User and Object Auditing is enabled:
SELECT USER_NAME, TEXT, STATUS, USRCLS, SPCAUT, AUDLVL, OBJAUD FROM QSYS2/USER_INFO WHERE SPCAUT <> '*NONE' ORDER BY USER_NAME

User Profiles with Special Authorities not Matching User Class:
SELECT USER_NAME, TEXT, STATUS, USRCLS, SPCAUT FROM QSYS2/USER_INFO WHERE ((USRCLS = '*PGMR' OR USRCLS = '*USER') AND (SPCAUT <> '*NONE')) OR ((USRCLS = '*SECADM') AND (SPCAUT <> '*SECADM')) OR ((USRCLS = '*SYSOPR') AND (SPCAUT <> '*JOBCTL *SAVSYS')) OR ((USRCLS = '*SECOFR') AND (SPCAUT <> '*ALLOBJ *SECADM *JOBCTL *SPLCTL *SAVSYS *SERVICE *AUDIT *IOSYSCFG')) ORDER BY USER_NAME

User Profiles with Command Line
SELECT USER_NAME, STATUS, LMTCPB FROM QSYS2/USER_INFO WHERE (LMTCPB <> '*YES') ORDER BY USER_NAME

User Profiles with Password same as User Profile Name (Default)
SELECT ALL USER_NAME, STATUS, DFTPWD, PWDEXP FROM QSYS2/USER_INFO WHERE DFTPWD = 'YES' ORDER BY USER_NAME

User Profiles that never change their Password
SELECT ALL USER_NAME, STATUS, PWDEXPITV, LASTUSED FROM QSYS2/USER_INFO WHERE PWDEXPITV = -1 AND NOPWD ='NO' ORDER BY USER_NAME

These are only a few common sense quick assessments you should review on an ongoing basis that will help improve the security of your system and protect your data. Contact us for assistance with running these reports either from a command line or via an automated tool that assesses AS400 security risks and generates a detailed report with findings and recommendations for remediation. The SQL scripts for reports are provided at no cost, and the AS400 risk assessment is also provided at no charge for 7 days, and is a great way to help improve the security posture of your system using industry best practices. In addition, ask us about using our security and audit tools on an ongoing basis, which automate the monitoring, reporting and remediation of the common vulnerabilities on your IBM i using best practices.

Summary
Real-time monitoring enable extensive auditing and reporting, using many different types of sources, including job logs, screen captures, and system and database journal reports to create a complete audit trail of user activities, and are distributed automatically via email. If a user needs additional authority for a specific action, they can ask for elevated authority of another profile from within their current job. Administrators can then accept the user’s elevated authority requests, or requests can be automatically granted according to the rule being used. Every IBM I Authority Manager rule consists of a profile pairing, a ‘from’ and ‘to’ profile, which can be based on group profiles, supplemental groups, lists of users and command line access. Tickets can be automatically generated using the built-in ticketing system or integrate with external ticketing systems. Each IBM Authority Manager rule contains the selection criteria that determines which rules a user may use, as well as other limitations that control the users’ adopted authority or profile swap session.

Features
Provide users a quick and simple process for requesting authority
Grant elevated authority requests manually or automatically
Flexible controls to allow source profiles to SWAP or ADOPT target profiles based on group profiles, supplemental groups, lists of users and command line access
Flexible controls to determine when request can be granted, including day of the week, date range, time range, job name, IP address, IASP and more
Extend rules to external processes for users need to connect via ODBC, JDBC, DRDA and FTP
Maintain detailed audit trail of activities including job logs, screen captures, SQL statements, QAUDJRN system and database journals
Send events and alerts to email, SIEM or SYSLOG Server
Produces reports in PDF, XLS or CSV formats
Integrate with external helpdesk solutions for ticket management or use built-in ticketing capabilities.