Unless you work at Fort Knox, the most valuable asset in your company could well be your data. Although data has no monetary value on a balance sheet, IT departments invest a lot of time and money in protecting and backing up data. The value of data is understood by those in IT, and IT professionals spend a lot of time worrying if the data is secure enough and if it can be restored easily in the event of disaster, mischief, or foolishness. Consequently, IT professionals know that prevention is the best medicine. There are few things more stressful than keeping the business on hold for half a day while you restore data that was wiped out by a careless or spiteful user.

You probably know the risks by now: The AS/400 was originally designed for clients with dumb terminals. Software vendors relied on menu security. Even if users had *ALLOBJ authority, they could be restricted from command-line access, and your data would be pretty safe as long as users couldn’t access an AS/400 menu from the vendor’s software. (I know of one case when this happened with a user on a terminal in a warehouse. At the time, users in this company still had *ALLOBJ. This particular user found himself at an AS/400 menu and eventually came to a menu with an option to power down the system. He dutifully took that option, claiming later that he thought “the system” was his terminal.)

New Tools, New Problems

With the advent of PCs, however, a whole new scenario has developed. Although useful, productivity tools such as TCP/IP, Client Access, and ODBC have opened more avenues to your data. Menu-security vendor packages, which have been working well for years, have continued to implement security much as they have. But the risks introduced by TCP/IP, Client Access, and ODBC have become evident. Many IT departments have held off implementing system-wide security upgrades because of the perceived complexity or risk of the undertaking. The default install of Client Access, for example, includes data transfer—both ways. The install also includes ODBC, and that is the straw that broke the camel’s back with me. At my last job, my department and I were implementing System Software Associates’ BPCS ERP. We had contractors coming and going, and one hired contractor was particularly keen on Microsoft Access. Although I asked this person not to use Microsoft Access to alter any data on the AS/400, I listened in dismay one day as he proceeded, step by step, to explain to a user what a link file was and how MS Access could

be used to modify live data in the ERP. It was then that my long-awaited application- security plan was pushed to the fore.

The key to my security plan is to secure the data itself, rather than the means of getting to it. Once you know data can’t be modified without proper authority, your worries about FTP, Client Access, and other data-access methods greatly diminish. You should be able to execute this security plan transparently. Securing the data is actually a surprisingly simple seven-step process. This simplicity is important because many smaller shops don’t have the time to buy or code a package that monitors exit points. This plan also leaves an escape route in case you need to restore your old security setup quickly.

Before I outline my plan, you should know that I am making some assumptions. The first assumption is that your users don’t already have *ALLOBJ authority, either as individuals or inherited from their group profile. My recommendation here is to do some testing then proceed cautiously to get all of your users to a state where they have no special authorities. When making changes to user authority, start out on the path of least resistance. I say that for political more than technical reasons. The second assumption is that your users do not belong to any more than 15 group profiles (i.e., 1 Primary and 15 secondary). If your users do belong to the maximum number of group profiles, stop reading this article and go clean up your system. Although OS/400 lets a user belong to one primary and 15 supplemental group profiles, that would amount to quite a cumbersome security matrix to maintain since the user would inherit the authority of each of the groups he or she belongs to. The user finally ends up collecting all of the authorities he or she is granted by each of the groups. Needless to say, this is a security exposure since maintaining 16 groups introduces room for error.

The Seven Steps to Security

Assume that you have a group profile on your AS/400 named OLDGRP, and that OLDGRP owns all (or at least most) of the objects in a particular application. Assume also that all of your users belong to this group. When a group profile owns all of the objects in an application, the group profile will have *ALL authority to the programs, files, and the other objects that came with your packaged software. To make matters worse, the OLDGRP group profile confers that *ALL authority to all members of its group, and this is the crux of the problem. Here’s how to fix that problem.

1. Let the OLDGRP group profile continue to have *ALL authority to its objects. You may be tempted to change this since you’re on a security mission, but don’t. Not changing this authority could play an important role later if you have to back out of the implementation in a hurry.

2. Create a new group profile and name it NEWGRP. This new group profile will be the replacement for OLDGRP when you go live later.

3. Make sure NEWGRP has *USE authority to all the application programs in your software package. This probably won’t be a problem since the AS/400 ships with the system value Create Authority (QCRTAUT) set at *CHANGE. However, you could tighten the screws a little more by granting the NEWGRP profile *USE authority only to your program objects. *USE authority is all the authority a user needs to call a program.

4. To continue with minimal effort, make sure all of your application programs adopt the authority of OLDGRP. This means that when the programs run, they will still have *ALL authority to your files and their data. This approach works, but it’s not the best way to solve the problem.

The recommended approach in this step is to examine how your software works. Are there a handful of key programs that needs to adopt authority to the OLDGRP group profile? Perhaps. Keep an eye out for main menus and especially batch programs that need to adopt authority. Also keep an eye out for programs that submit other programs to batch for execution. That is the only glitch in my implementation. All of my batch programs run fine (please note I took the lazy approach), but some of my financial jobs submit a second batch program. The second submittal runs into authority problems and sits on a message to that effect. Fortunately, one of the options is a retry, so, after some remedial authority work, the message answers and the program completes normally.

You should also be on the lookout for any programs that require special authority to run. Perhaps your software has a few programs that do need extra authority. You could use the Print Adopting Objects (PRTADPOBJ) command, or take option 1 off the SECBATCH menu to run the report in batch. The output lists all the programs that adopt authority. It is sorted by library, so you should be able to quickly isolate the programs belonging to your particular software package.

5. Change the public authority on your application’s data files to *USE for files that users should be allowed to look at or *EXCLUDE for those files that are expected to be kept private. This hits the real authority problem right on its head. But be wary of excluding users from your data. Unless you have the payroll file or some other very sensitive information on your system, *USE will be enough to protect your files from unauthorized changes. Why? Because your users may be query composers. If the file is completely off limits, you can count on some controversy, and you want to avoid that. The object of this security plan is to protect your data from accidental or malicious damage, not cause more problems.

6. Make all of your users members of the NEWGRP group profile. Figure 1 (page 83) shows you the sample CL code you can use to accomplish this. You’ll need to have *ALLOBJ and *SECADM authorities in your user profile to run the program shown in Figure 1. You can download the code at www.midrangecomputing.com/mc. What that program does is change the group profile parameter of the user profile on your AS/400 to NEWGRP and relegate OLDGRP to be a supplemental group. Everything will work normally at this stage. Users will continue to adopt the authorities of all of their groups, and, since OLDGRP is still part of the users’ profiles, nothing has changed.

Up until this point, you have been creating a new group, granting authorities, and your users have had no idea what has been going on behind the scenes with your security upgrade. Before you proceed any farther, you should create a test user profile to test the new authority setup. Remove the OLDGRP group profile from your test user’s group profile. Then run extensive testing. You could mimic the processing flow through your system. Enter a customer order, for example. Change it, delete it, enter another order, pick it, pack it, back-order it, invoice it, reprint the invoice, and perform every conceivable act on this order that you can. If you work in a larger, more complex environment, keep an eye out for any client/server or Web-based applications that you can test too. You may have developed some Visual Basic programs using ODBC to change records somewhere in your database. You may also have jumped on the intranet bandwagon and have programs maintaining records using Java applets, servlets, RPG or C CGI programs, and others. The key here is to test, test, test. If any pain can be inflicted upon your organization, ferret it out now

7. Remove the OLDGRP group profile from your users’ profiles. If you want to take a more cautious approach, perform the replacement on only a few of your user profiles at a time and then monitor the situation. If you make the change and the implementation goes awry, use the CL program shown in Figure 1 again. Using the CL program will put your

users back as members of the OLDGRP profile. If you are forced to fall back to your original security model, some research and troubleshooting are obviously in order.

Are You Ready?

After reading through the seven steps I described and doing some research on your system, you should be ready to make the change. Proceed cautiously, do plenty of testing, and be sure to leave yourself a good escape route. If my plan works, you will have accomplished a major security overhaul in a fairly straightforward way and in a manner transparent to your users.

/*****************************************************************************/

/* To compile: */
/* */

/* CRTCLPGM PGM(xxx/CHG001C) SRCFILE(XXX/QCLSRC) */
/* */

/* */

/* CHG001C - Change Group Profile */
/* */

/* */

/* CPP FOR CHGGRPPRF COMMAND */
/* */

/* Authority: You need at least *ALLOBJ and *SECADM to run this program */
/* */

/*****************************************************************************/

PGM PARM(&OLDGRP &NEWGRP)

DCL &OLDGRP *CHAR 10 /* Old group profile */

DCL &NEWGRP *CHAR 10 /* New group profile */

DCLF QTEMP/ALLUSERS /* Output file with list of users */

/* Create outfile with all users */

DSPUSRPRF *ALL OUTPUT(*OUTFILE) OUTFILE(QTEMP/ALLUSERS)

LOOP: RCVF

MONMSG CPF0864 EXEC(GOTO END)

IF COND(&UPGRPF *EQ &OLDGRP) THEN(DO)

CHGUSRPRF USRPRF(&UPUPRF) GRPPRF(&NEWGRP)

ENDDO

CHGVAR &UPUPRF VALUE(‘ ‘)

GOTO LOOP

END: RETURN

ENDPGM

Figure 1: Change group profiles en masse with this CL program.