The World's Easiest IBM i Heist?

By Robin Tatam

I anticipated that they'd conduct a background check when I applied for the job at the bank; however, I only had to submit to a common drug test. I may be a lot of things, but a "doper" isn't one of them. Fortunately, it didn't expose that I'd been fired from my previous three jobs for helping myself to money in the register. I requested access to the walk-in safe after I had been working at the bank for a few days. Interestingly, it turns out my front door passkey was duplicated from someone who had already been granted access so I am already set up. Of course, if I ever forget my key, there are quite a few spares still lying around from employees that no longer work here.

There are solid locks on the outside doors to keep the public out when we're closed, but no one worries too much about employees (I assume they're all employees) coming and going as most of them don't know much about the "behind the scenes" movement of the money. Besides, most employees have been around for years and no one thinks that they'll ever do anything bad. Surveillance cameras are mounted on the ceiling, although none of them are anywhere near the back door; an entry that's accessible to all of us with a passkey. The funniest part is that I found out that the bank doesn't even bother to use any of these cameras! At one time a few were hooked up, but the video tapes were reused after only one day and I heard that some got accidentally thrown away by the janitor. I figured no one was reviewing them anyway as there's no screen on the VCR that's there to record the video stream.

I was quickly discovering that this job would be far more profitable than I'd imagined . . .

Okay, it probably sounds like I'm setting the scene for the world's easiest bank heist. I certainly wouldn't invest a dime of my hard-earned money with an institution that overlooked security like this one does, but you might be surprised to know just how many organizations approach IBM i security in a similar lackadaisical fashion.

Many companies do require potential hires to submit to a drug test. While this is certainly commendable, it obviously won't identify anything other than substance abuse. Investigating an applicant's work history won't help because many employers are too concerned with the legality of disclosing private information to release anything more than the dates of employment. That privacy concern even exists when—or perhaps especially—if the employee's departure was due to misconduct. When a business uncovers illegal or unethical activity such as fraud, theft, and even workplace harassment or violence, it's not uncommon to simply fire the employee to avoid embarrassment and further scrutiny. Without insight into an applicant's work history, it's quite possible that undesirable traits will remain hidden throughout the hiring process.

Under IBM i, new user profiles are rarely created from scratch. Typically, copies are made from a "similar" profile which may lead to inconsistencies regarding the authorities that the employee obtains. Copying (and later copying that copy) frequently results in the over-assignment of authority, especially when the source profile belongs to a more tenured user. This is the equivalent of duplicating the passkey that inadvertently authorized the nefarious employee's access to the safe!

In my fictitious bank scenario, the availability of spare passkeys constitutes an obvious vulnerability. This type of risk is also common in the IBM i world. Many organizations maintain large numbers of profiles that are no longer required. Temporary profiles, profiles associated with unused applications, and profiles for departed—sometimes even deceased—employees often remain on the system for years. This can be the result of not having a clear plan for the transference of object ownership, or simply because no one is overseeing the cleanup task.

Profiles often begin life with a password that matches the name of the profile; this is the default IBM i setting for a new profile. When profiles retain this configuration, there's high risk that access will occur without proof of the true identity of the employee (or intruder) signing on. This risk is closely related to the common practice of sharing profiles amongst multiple users.

Compliance mandates - and security best practices demand - that a unique profile should exist for each individual user. An initial password should be assigned randomly (or as *NONE) until server sign on is necessary. This eliminates the risk that an unused profile will be accessed by an unauthorized user. The presence of a profile with a default password must be reported on a frequent basis, and violations mitigated immediately. A policy should be implemented to address the timely disablement and deletion of profiles that are no longer required. An audit report should provide the name and configuration settings of profiles that have not been recently used; perhaps for 30 days for more.

Most organizations deploy perimeter firewalls to prevent unauthorized entities from accessing the trusted network. However, once a user is provided with credentials, we do little to control their access. This begins with a unique IBM i concept known as *PUBLIC. This designation applies to any user who does not have explicit access (granted or restricted) to an object. The IBM i operating system ships with a default *PUBLIC authority of *CHANGE which is sufficient for file data records to be read, updated, and deleted. Many organizations do not modify this default, relinquishing the ability to control users who have command line access or PC data access tools.

The concept of least privilege mandates that access granted to the general user population (*PUBLIC) should be the most restrictive—ideally *EXCLUDE. Command line restrictions and menu security is only guaranteed to be effective for "green screen" users and should not be solely relied upon. Users with a business requirement to access applications and data should be granted explicit access to the applicable libraries and resources.

IBM i doesn't impose many restrictions on powerful users who have command line access. For example, an administrator who is authorized to IPL (reboot) the server during a scheduled maintenance window can also accidentally IPL at 10am on a busy Monday morning. Commands should be audited and controlled to ensure appropriate usage—even by authorized users.

An integrated audit facility in IBM i acts much like the surveillance cameras available in our bank, recording the actions of anyone who enters the premises. Despite the fact that this comprehensive function is available on all servers running IBM i (including OS/400 and i5/OS), PowerTech's annual State of IBM i Security study, reports that it remains grossly underutilized. Even if auditing is turned on, event logs are often not analyzed and may be purged too quickly to provide any reasonable audit value. This is similar to the bank opting not yo use the cameras, and not reviewing the logs even when they do. Logs should be placed into secured libraries where they can't be "thrown away" accidentally by a passing employee.

As with the back door at the bank, it's important to recognize that the integrated audit facility does not have visibility to all of the activities of a user. Using their normal credentials, a user can often log in to an alternate interface such as FTP or ODBC, possibly enabling them to transfer data and run server commands. These actions will not generate a detailed audit trail. Organizations are responsible for installing their own "cameras" to secure (and control) these interfaces, although IBM i includes the infrastructure needed to support them. Fortunately, this enhancement can easily be accomplished by purchasing a commercial exit program solution.

While there are numerous aspects of IBM i security configuration, many servers are just as unsecured as the bank that I described at the beginning of this piece. Fortunately, with help from a trusted security expert, the situation can be rectified.

About the Author


Robin Tatam is the Director of Security Technologies for PowerTech, a leading provider of security solutions for IBM i. Robin is a subject matter expert for COMMON and a frequent speaker on security topics.