On today's more open iSeries-AS/400 system, the Save/Restore function can be used to transfer critical files and programs between systems. With this comes the specter of data and program theft, so it is important to make sure that this avenue of data transfer is secure.
Most iSeries-AS/400 installations run a scheduled save of their system to transfer files, programs and other objects to tape for safekeeping. Saving the system on a scheduled basis is just good practice, since the catastrophic loss of a single disk unit on your system can mean that you loose everything on your system. Since introduction, IBM has hounded its customers (and rightly so) to do a regular save on your system. Once objects have been saved, you can also use OS/400 functions to restore objects from tape. This can be part of either a full system restore or to recover objects that get damaged or corrupted in any number of ways.
The problem from a security viewpoint is that once data and programs have been saved to tape, they can then be transported to another system and restored. Mission-critical information, then, must be guarded to prevent theft from occurring. Physical security on the tapes is critical for this, but I want to talk more about securing the Save/Restore function on your system.
Today, with the more open TCP/IP world in which we work, you can save a critical file to a save file and then FTP or SNDNETF it to any system in the world. iSeries software developers regularly use the FTP save file to transfer program updates onto customer systems. With the ease of data transfer that this provides, restricting the use of the Save/Restore functions on your system is more critical than ever.
The first line of defense for this is found in the user profile. Before someone can use the Save/Restore commands in OS/400, they must have *SAVSYS special authority in their user profile. If you have not done so, you should review your user profile base to find out which user profiles have *SAVSYS configured and make sure that they have a real business reason for it. Certainly, your operator(s) will need this authority, as will anyone who runs the scheduled backup or restore functions. But I would be hard pressed to think of any other users in a regular environment (including programmers) who really need to have this ability. I know some programmers are going to howl at this, but they will have to be able to make their business case before you give them these keys to the kingdom, so to speak. You can always look at granting them this authority on an as-needed basis, revoking it once the task to be done has been completed.
The next place to look for restricting Save/Restore use on your system is the OS/400 authority setup for the the RSTxxx and SAVxxx commands. The RSTxxx commands are shipped from IBM with public *EXCLUDE, but the SAVxxx commands have a public setting of *USE. You might want to consider setting up an authorization list for these commands and then listing the user that you want to be able to use them in the list. Once the list is built, associate it to the commands and then change the SAVxxx commands to be public *EXCLUDE. (You can also do this with direct authority, but having the authorization list will make OS/400 upgrades easier to implement.)
There are several system values that you should take a look at, too. The QALWOBJRST value lets you restrict certain objects at restore time. These include system-state programs, programs that adopt authority and objects with validation errors. QVFYOBJRST controls restoring signed objects. QFRCCVNRST will force object recreation on certain objects at restore time. Lastly, you can specify *SAVRST in the QAUDLVL command to audit save restore operations on your system.
If you have any questions about anything in this tip, just ask me and I'll give you my best shot. My email address is rich@kisco.com.
---------------------------
About the author:Rich Loeber is president of Kisco Information Systems, Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries-AS/400 market.
