The solution to the above situation is fairly simple. Set the public authority to the AS/400 database files to EXCLUDE and have the ODBC application call a stored procedure (described in Chapter 6) in the AS/400 that adopts authority to perform the functions on the files. And other techniques can be used to further control who can do what using ODBC. I should point out that using ODBC is not the only exposed interface to the AS/400. TCP/IP File Transfer Protocol (FTP), Client Access file transfer, and DDM are but a few other examples of remote interfaces to the AS/400 that have the same potential security risks. The point here is that many client/server applications, including some from ISVs, are written without security implications in mind, which can result in a false sense of security about the safety of business-critical data.

The key to protecting AS/400 data is to ensure that any code that enforces access restrictions runs on a secured system. For AS/400 customers, this usually means setting the system security level at least to resource security (level 30) and paying close attention to security considerations when developing or buying a client/server application.

Recently, a great deal of interest has developed in many AS/400 installations related to using Network Computers (NCs) instead of PCs. An NC has many of the benefits of a PC without some of the costs and potential headaches. In some situations, NCs also can offer greatly improved security. We investigate NCs further in Chapter 11.

Viruses, Worms, Trojan Horses, and Other Nasty Critters

Viruses are so commonplace in PCs that no one today should seriously consider using any PC in business without at least some virus-detection software. New viruses are created every day, which means that virus-scanning software must be continuously updated. Unix systems and even mainframes also have been infected with viruses. All of these systems are susceptible to viruses because they provide some form of system programming capability. To infect a system, a virus must be able to copy itself into or attach itself to some executable code at the binary machine level. The fact that so little of the AS/400’s internals are visible makes it far more difficult to create an AS/400 virus. It is, however, possible to introduce some form of a virus into an AS/400 if the system is not properly secured.

The best way to guard against viruses in an AS/400 is to protect program objects and commands. For example, a system user can change a command, using the CHGCMD (Change Command) command, if (s)he has object-management authority. One way to prevent this is to use the RVKOBJAUT (Revoke Object Authority) command to revoke all unnecessary access to commands. You might even revoke, or at least monitor, all accesses to the CHGCMD command itself. Because only a few tools and commands in the AS/400 can be used by a hacker to patch or create executable programs, it is also possible to restrict access to those tools and commands. If unauthorized program creation and program object changes are eliminated, the capability to introduce a virus is almost nil. The AS/400’s capability to monitor, through its security-auditing features, who uses these commands and who changes programs, also makes it difficult for someone to make changes without being detected.

Worms are similar to viruses, but they do not infect other programs the way viruses do. Instead, worms continuously replicate themselves and tie up system resources. For example, a worm program in an AS/400 could be a program that continuously submits itself as a job. It may not cause damage, but it could cripple the system by usurping much of the system’s resources. The prevention here is to restrict access to commands that change the job or the class and to set the job-queue maximums to some limited number of concurrent active jobs (we discuss jobs, job queues, and classes further in Chapter 9). To eliminate some of these possibilities, as of V3R7, IBM changed the public authority to most of these work-management commands that are shipped with the system from USE to EXCLUDE. The public authority to many job descriptions was also changed from CHANGE or USE to EXCLUDE in this same release.

Like the story of the ancient Greeks entering Troy by hiding their soldiers in a giant wooden horse and then presenting the horse to the Trojans as a gift, the computer version of the Trojan horse tries to enter your system undetected. A Trojan-horse program usually has the same name as a legitimate program. A user may attempt to put a Trojan horse somewhere in the system where it will execute at a higher level of authority than the user has been given to the legitimate program. The easiest place to put the Trojan-horse program is in a library.

In Chapter 5, we discussed library lists and said that the system searches through the libraries on the list one at a time until the desired object is found. If someone placed a Trojan-horse program in a library preceding the library that contains the legitimate program of the same name, the Trojan horse would be found first and the user could be into the system at a higher level of authority.

To illustrate how this might work, consider an IBM-supplied library called QUSRSYS that was shipped with the system with public authority set to CHANGE. The system searches this library before it searches other user libraries on the library list for a job. A call to a user library would invoke a similarly named Trojan-horse program if a hacker had first put one in QUSRSYS. Notice I said, “was shipped.” As of V3R7, QUSRSYS and other IBM-supplied libraries are now shipped with public access of USE to prevent Trojan horses in these libraries. At the same time, other changes were made in the area of special authorities for the various user classes, to tighten security in the system and to make unauthorized access to system resources more difficult.

Unlike PCs and Unix systems, the means to secure an AS/400 from the critters we have just discussed is already available in the system itself. In recent releases, we have changed the default security parameters to make it easier to secure the system, but the customer still must take actions to use many of the built-in security measures. No security measure is effective unless it is used. With a little planning and forethought, you can ensure that an AS/400 is a very secure system.