The Four Hundred

Chances are you don't know OS/400 security like this man. Few people do. Wayne O. Evans is one of the best-known names in AS/400 and iSeries security. In 1991, after working at the IBM Rochester, Minnesota, development lab for 27 years (including six years designing security features for the AS/400), Evans retired and began a second career in speaking and teaching about AS/400 security.

Between sessions at the iSeries and AS/400 Technical Conference, I asked Evans about his experiences with OS/400 security and the facts and misconceptions about the iSeries and AS/400.

I'm sure you have seen some examples of horrendously lax security during on-site security reviews at AS/400 shops. Give me some examples of security exposures you've seen.

I was brought into a large international bank to conduct a security review. As part of the review, I sat down at a workstation and typed in the user profile test, and then typed in the password test. This allowed me to quickly get into the bank's international fund transfer system, complete with PIN numbers. Anyone could have used those user IDs and user passwords to transfer money. It's a trivial problem, but it crops up in many different businesses. No amount of security software will save a company from this type of mistake.

Within OS/400's security toolkit exists a simple interface that checks whether user profile names are the same as the password. If you run it, it identifies the problem and it can be changed. I find this problem on at least 30 percent of the machines where I do security reviews. That's the sad thing. The most obvious exposure exists on way too many machines.

In another example, the company was a manufacturer. They were concerned because the security officer was leaving. They decided they were going to change the password of all user profiles. They made the user passwords so similar that once you knew your password, you could easily figure out every other one, as well. So in their attempt to secure the machine from the security officer who was leaving the company, they opened their AS/400 up to all the users.

I also know of a company that hired an outside contractor to write their payroll system. Inside an RPG program he created a logic bomb that randomly deleted data. The company ran the application for weeks, knowing something was going wrong, but not knowing what was causing it. In that case, they did not have good change procedures in place. No security software is going to catch something like that.

Based on your experiences, would you say there are misconceptions regarding the security reputation of the AS/400 and iSeries servers?

To begin with, the OS/400 operating system is the commercial system that can be configured for the absolute best security. But just like you can have the best locks on the doors of your house, if you don't use them, you're not secure. OS/400 can be totally secure, but I generally find that people fail to use, or incorrectly use, the locks that are available.

To some extent it is a misconception that the OS/400 is a secure platform. Users get a false sense of security, because the AS/400 is widely publicized as being secure. Users know that the object architecture in OS/400 makes viruses almost unknown. The OS/400 platform--unlike others, particularly the Windows platform--has not had a rash of security bugs that need to be fixed immediately.

The typical hacker is not familiar with the OS/400. The system is foreign to them and is priced out of the hacker's marketplace. The hackers don't have a lot of experience with the OS/400. That doesn't mean there aren't people who try to hack the OS/400, but for the most part the hacker community focuses on the Intel platform.

So the reputation of the box and the fact that there is not a lot of press talking about break-ins on the AS/400 leads to a false sense of security. What is the reality?

One of the most common security exposures to the AS/400 happens when attaching PCs. The 5250 applications written for the green screens did not allow users to do anything that wasn't on their menu. With PCs attached to the AS/400, the PC user can upload and download data files from the AS/400, if they have authorization.

Frequently, users are authorized to access production data files simply because they are running other OS/400 applications that need access to those files. Because those PC users have access, they can use things like FTP or Client Access file transfer to retrieve the file, alter the file, and then upload it back to the AS/400. If they use the Integrated File System to store PC files, they can get PC viruses in the IFS.

PC programs are stored as files, and you can use file I/O to modify a program. On the AS/400, programs are not stored as files, but as program objects, and you cannot modify a program object. You can compile a new one, but you cannot go in and alter the instructions inside of a program. There is no instruction interface. That's what keeps the OS/400 virus-free.

What do you recommend regarding the security risk that comes from PC users gaining authorization privileges?

OS/400 has functionality that is referred to as "exit programs." What that means is, when a request comes in from a PC, before the OS/400 server processes the request, it calls a user program and it either allows or denies this transaction. Through the use of exit programs, installations can screen the requests.

You can write exit programs, or you can purchase them from third-party vendors. I do not recommend that end users write their own exit programs. It can be done, but it is complex. It is very involved, and there is a big learning curve.

Third-party vendors put a lot more functionality in their exit programs. Most of the customer-written programs are the trivial examples. The sophistication of the vendor products deal with group profiles and supplemental group profiles. They deal with access by time of day or day of the week. For the users to code this functionality themselves is almost prohibitive. With third-party exit programs, you are buying the vendor's expertise. There are at least 20 different vendors around the world.

I tend to think that all the exit programs will provide the functionality that the user needs. Some vendors have only exit program solutions. Others have exit program solutions as part of a larger package.

Some vendors want to keep the performance of their exit programs highly tuned; to actually determine whether the user is downloading this file out of this library requires that you break apart an SQL statement--parse the statement--that takes some time. Some vendors elect not to do that and don't give you the actual object name that you're going after.

I like to get the name of objects when I'm dealing with security. It is easier to put the blocks in that only allow people to upload or download against a specific library or against selected files, rather than allowing certain transactions and then relying on OS/400 security by swapping user profiles and things of that nature.

Most vendor packages cover all of the critical exit points for file transfer and remote commands and file upload and downloading. As I've looked at packages, the coverage is relatively complete.

Is there a misconception that once you have exit point security you are safe?

Failure to use exit point security stems from the lack of knowledge of the exposure or lack of knowledge regarding how to repair the exposure. Many systems administrators say, "Oh, my users don't know how to do things that lead to security exposures. Therefore it is not a problem." Those administrators are fooling themselves. Ignorance of security is not security; it is just ignorance. You can't rely on your users being dumb. In today's environment there are kids coming out of high school who know more about PCs than many professionals.

Exit program security blocks the exposure from the remote user. There are other common security exposures--trivial things--but a recurring theme.

One thing I often find when I do a security audit is user accounts for users who have never used the machine or the user hasn't accessed the AS/400 for maybe a year, yet they have an active account. Some users may have been terminated from the company.

When unused user IDs are not cleaned up, it is an obvious exposure. Clean up is a big step forward. OS/400 has functionality in the security tool kit that is part of the operating system. For instance, it can be set up so that when a user profile has not been used for a specified number of days (your choice), then that user profile is automatically disabled.

A similar shortcut is the concept of a group profile. People in a department may become the owner of production data. Therefore all the users are authorized to that data.

So is failure to implement exit point software the biggest concern when it comes to security issues on the iSeries?

I think the most common security failing is that many AS/400 installations don't have a company security policy.

Compare it to the policy for programmers. Management tells programmers, for instance, "I want you to write an accounts receivable program. Here's what the input looks like. Here's what the output looks like." But often the security officer doesn't get a lot of direction regarding the rules for the system. Therefore, the policy is sort of made up by the security officer and is often not documented. The lack of a written security document means you don't have a long-term plan.

Security is a management decision. How tight are you going to lock up your data depends upon your company. Are there highly classified formulas for your product?

People hack into AS/400s because of simple security weaknesses. In other words, if you leave your back door open, people are liable to wander in. Most security hacks are because of administrative failures. They fail to use all the features that were available to them.

I have heard there are security concerns pertaining to the Operations Navigator functionality in OS/400. Can you shed some light on that?

Operations Navigator introduces a whole new realm of security exposures. Essentially, OpsNav gives users a graphical interface to look at objects, to delete objects, and to look at database files. Unless you have very good OS/400 security, the traditional exit program support doesn't do an adequate job. OpsNav is too complex for the exit programs. The user doesn't know what internal calls it is making to perform certain functions, so the user can't implement the right exit programs.

However, OS/400 has something called Application Administration, which allows you to restrict that function, through Operations Navigator, so that the end users don't delete objects on the AS/400.

Application Administration was introduced on V4R5, but it was significantly enhanced with V5R1. It's a strong motivation to get to V5R1, because I wouldn't rely solely on exit programs to take care of all security exposures.

Wayne O. Evans lives in Tucson, Arizona, and can be reached at woevans@aol.com. Security articles authored by Wayne O. Evans can be found on his Web site, at www.woevans.com.