IBM i (AS/400) Security Best Practice: Limit Users with *ALLOBJ

IT professionals require special authorities to manage servers. In addition to changing system configuration, these authorities may permit the ability to view or change financial applications, customer credit card data, and confidential employee files. 

There are many legitimate business reasons why an IT team member needs more authority than the average system user, but special privileges are rarely necessary 24/7. In careless, misguided, or malicious hands, these IBM i special authorities can cause serious damage. Recent data shows that data breaches caused by insiders are increasing in both frequency and cost.

So, how can an organization balance security controls with IT productivity? 

Keep reading for the lastest data on IBM i special authorities and IBM i (AS/400) security best practices.

How many IBM i users have superpowers

A user who intentionally exposes corporate data to take revenge on a previous employer is very different from a user who unwittingly clicks on a phishing email, but the result is the same: private data exposed to unauthorized parties.

Special authorities always pose a security risk, so auditors require you to limit the users who have these special authorities and carefully monitor and audit their use. After all, not every user on the system has a business need to access, change, or delete mission-critical data.

Of the IBM i special authorities, *ALLOBJ is the one providing users with the unrestricted ability to view, change, and delete every file and program on the system. As shown in Figure 2, this authority is granted to users in unacceptably high numbers.

Image

Only three of the systems reviewed in the State of IBM i Security Study had 10 or fewer users with *ALLOBJ authority. In addition to All Object, the most frequently granted special authorities were Job Control (*JOBCTL) and Spool Control (*SPLCTL), which were granted to 44 percent and 24 percent of users, respectively. Job Control provides the capability to change the priority of jobs and printing, or even terminate subsystems in some cases. Spool Control enables users to fully access any spooled file in any output queue, regardless of imposed spool restrictions.

Many organizations embrace a role-based access control (RBAC) model in an attempt to standardize the user configuration. This is typically implemented on IBM i using a mechanism known as Group Profiles. In the latest State of IBM i Security Study, 95 percent of the servers had one or more group profiles defined and 47 percent had 10 or more of them. Of all the group profiles, 89 percent were passing special authorities down to their members, an inheritance that is sometimes overlooked during a review of user permissions.

AS/400 security best practices for special authorities

IBM does not publish any documentation for the functions available with each of the special authorities, which leads to resistance by IT to remove authorities for fear of “breaking” existing operations.

While it is difficult to create a hard and fast rule for all environments, IBM i security experts agree that the number of users with special authorities should be kept to the barest minimum. This is known as the principle of least privilege.

In general, it’s a good security practice to keep the number of users with special authority to fewer than 10.

Here are some IBM i (AS/400) security best practices for powerful users:

• Document and enforce separation of duties for powerful users. 
• Avoid having any all-powerful users, all the time.
• Monitor, log, and report on the use of powerful authorities.
• Be prepared to justify the use of powerful authorities to auditors and managers.

To make the work of monitoring and documenting user privileges easier, a solution like Powertech Authority Broker can automatically monitor, control and audit users who need to access higher levels of authority. Powertech Command Security is an effective way to prevent unauthorized users from executing a monitored command.