The Four Hundred

Most iSeries shops run some kind of purchased software package from the wide array of independent software vendors with applications designed specifically for the OS/400 operating system. Virtually every iSeries machine runs purchased packaged software, whether it's an ERP or CRM system that is core to your business operations or a nuts-and-bolts accounting package or maybe just an operations utility that helps you manage your machine better.

One of the things that makes the iSeries (or any hardware platform) so great is the rich variety of software applications that can be bought right off the shelf and used to run your business better. These software packages are typically written by experts in their field. Whether it's customer management, human resources, or forms printing, companies purchase these packages to gain the application-specific expertise of the software authors, at a fraction of the cost of keeping such folks on staff.

Unfortunately, many of these authors have limited experience outside their core expertise. Ask a general-ledger-application specialist what he knows about security, and you're likely to get a shrug. Ask the payroll specialist what protects your data from prying eyes, and he may be able to speak about some limits that are enforced within the application package, but typically will not recognize the exposures that come from users who can access data from outside of the package.

When the application security is faulty or incomplete, as it is on so many purchased application packages, your business information is at risk. Not surprisingly, software vendors of many different stripes often commit the same kinds of security gaffes. Fortunately for you, this commonality makes it easier to find, and then fix, these security problems. This article, like the COMMON presentation that it is modeled after, details some of the most common and most pernicious problems that application software developers typically design into their packages. In an article of this length, I can only touch on the high points. For a more thorough coverage of the topic, stop by the COMMON security focus.

The most common and troubling problem is the legacy technique of having a group profile own the data in an application. (This also spawns several other problems, covered later in this article.) A good security model is one in which one profile owns all of the data objects in an application. It is also beneficial to have one profile act as a group profile for all users of the application. By setting up a group profile for all users, the administrator need only describe the authority settings for the group, and avoid repeating the same step for each user. If the owner profile and the group profile are two distinct profiles, all is well. But if the owner profile and the group profile are the same (which is true of most purchased applications packages), a number of serious security exposures are introduced.

Here's why: An owner of an object will always have complete rights over that object. In the case of a data file, the owner has the rights to read, change, update, or delete every record in a file, as well as clear the file, move the file, or just outright delete the file. It's all a natural part of being the file's owner. Meanwhile, group profiles are designed to confer all of their rights to the members of their group. It naturally follows that if a user belongs to a group, and that group is the owner of the file, the user has ownership rights to the entire file. Multiply this exposure by the number of users who belong to your application-owning group profiles (hundreds? thousands?), and you have a problem. On systems using this kind of application security, any user can read, change, or delete any object in the application, provided the user has some method of getting at the data other than a 5250 green-screen sign-on.

But here's the rub: The menu systems that these applications use were designed to control users who were logged on to a twinax-attached dumb terminal, and I'll bet you a cookie that over 95 percent of your users use PCs instead of those old dinosaurs. And as we have all surely seen by now, PCs come equipped with robust data transfer tools like FTP, ODBC, Client Access, Remote Command entry and similar tools. These tools provide the capability to move data up to and down from your iSeries machine without consulting your menu security system. The group profile membership outlined above is typically all that is required to move data using these kinds of PC tools.

There are a number of solutions that can be deployed to address this problem. You can put pressure on your software vendor to address the concern, though this isn't often a rapid or satisfactory route. You can redesign the security system of your purchased software application to eliminate the dual role of the owner and group profile, taking into account that your new scheme must work with future releases of the vendor's software, or you can implement exit programs that guard the access routes of FTP, ODBC, and Client Access. Exit programs can be difficult to write, though, and harder to debug and test on a production machine. Ironically, a purchased exit point application may be a better option.

Many purchased software packages provide users with OS/400 special authorities, often not because the user needs the special authority, but rather in an attempt to minimize the support calls that a vendor might have to field because of security problems. The most cynical of vendors prescribe *ALLOBJ authority (often through QSECURITY level-20 settings) to all users, so that they never have to try to figure out why a particular user is not allowed to update a certain file. But OS/400 special authorities are not to be handed out lightly.

The whole purpose of special authorities is to allow a user to bypass the regular object-level authorities that OS/400 enforces so well. Hence, a user with *ALLOBJ authority really does have the capability to read, change, or delete every object on the system, and a user with *SPLCTL can do the same for every job queue entry and spool file on the system. That's certainly not the kind of power you want to hand over to application users. Even *JOBCTL special authority gives users the capability to see most other users' report data, as well as to stop, start, and hold their active jobs.

In a well-managed environment, you'll want to limit the number of users who have these special authorities to a select few, and most of those users should have their actions audited. Vendors hand out these authorities to make their jobs easier, not yours. It's in your best interest to reign in this special authority before it creates a business problem. And if the vendor tells you that it can't be done, have it explain why, in language that you can understand. It's a rare user who needs any kind of special authority.

One of the nice things about OS/400 security is that it is extraordinarily difficult to gain access to the system without a proper user ID and password. This means that if someone is bent on gaining access to your machine, he'll first need to sign on, preferably with a powerful user profile. Good user ID naming policies and password protection policies lower the risk that an outside interloper can sign on to your machine, but the possibility cannot be eliminated as long as you have users who are careless with their user IDs and passwords. A common attack method is to gain access as any user (even the lowliest user will do) and then use that access as a launching point for further attack. This method is made easier by applications that do use group profiles to own data (as described in Problem 1 above) and also by packages that do not secure their user IDs.

In OS/400, any user can assume (or hijack, if you will) the identity of another user if he has at least *USE rights to the target user profile: No Password Required! This can be disconcerting to system administrators when they discover that all of user profiles in their application give either *ALL authority to the group profile or *USE authority to *PUBLIC. The notion of personal accountability takes a big dive on a system configured this way, because virtually any user can assume the identity of any other user. If you find that user profiles are not secured on your system, you can see this exposure for yourself by specifying the name of an unsecured user profile in the USRPRF parameter of the Submit Job (SBMJOB) command. Your submitted job will run as someone other than yourself.

The fix on this front is less complicated than the first two problems. In most cases, you can simply remove any public or group authority to the data without having an adverse effect on your application. But a good scour of the Security Audit Journal (QAUDJRN) will let you know for sure.

John Earl is vice president and chief technology officer of PowerTech Group. John has published numerous security-related articles and is a subject matter expert on security for COMMON. E-mail: johnearl@powertechgroup.com