Originally offered as a free PRPQ, the Security Toolkit has now been integrated into OS/400 to provide powerful administrative capabilities as well as a full-featured security reporting facility. With these tools, you can maximize native OS/400 security and use AS/400 security functions more effectively.

The AS/400 and its predecessor, the S/38, have a well-deserved reputation for having extremely potent integrated system security. In the S/38 days, much of the power of the security features was the result of the proprietary, closed nature of CPF, the operating system. As the AS/400 has moved to an open, standards-based architecture, the old proprietary safeguards have become less effective in preventing unauthorized system access. Administrators are constantly facing new security challenges as new doorways open into the previously closed world of the AS/400. In this article, I discuss some of the major challenges facing AS/400 security administrators today and give you an overview of the tools used to thwart system misuse. Then, I show you how to use the AS/400 Security Tools to keep track of possible security breaches and how to minimize your exposure to unauthorized system access.

Walls Around the Castle

Computer security is a convoluted subject. The goal of computer security is to protect the data that resides on the computer, utilizing both physical and software walls. We must first build physical walls around the actual device to protect the data from external access and damage by natural causes. While these physical walls are needed to keep our data intact, the internal software walls we erect around our data to protect sensitive information from unauthorized access are even more important. A well-run installation

should be able to recover from hardware failures or even a natural disaster, but allowing vital data to be accessed unnoticed by an interloper who finds a way into your system can be far more dangerous to the health of a business than an obvious physical problem with the machine. Unfortunately, walls not only keep criminals at bay but also can inadvertently keep authorized individuals from accessing the data they need to do their jobs. As the role of business computing has changed from a centralized operation to a distributed network, the task of the security administrator has changed from building walls to building specialized bridges that only authorized individuals can access (see the sidebar “Version 4 Adds New Security Features to the AS/400”). The castle still needs to be protected, but more people need access to it from different routes than ever before.

Many protective layers must be erected to secure a computer. These layers can be broken into two general categories: internal and external controls. Internal security control involves a number of layers:

• Physical security, including actual access to the computer room
• High-level controls based on system values, including system security level (see “Password System Security Values Demystified,” in this issue of MC)

• Access control and identification controls, including passwords and user/group profiles
• Security auditing to uncover any possible security breaches Now that the AS/400 is being used in the modern networked world, external security layers have been added to OS/400’s internal controls:

• Exit programs to control client/access security
• Secure Web-serving capabilities, including encryption and firewalls
• New security APIs to help tighten the doorways into the AS/400 Both internal and external security controls are important to keep the walls around your data from being breached. In the rest of this article, I’ll show you how to use the IBM AS/400 Security Tools to make sure no cracks develop in the security walls you have erected to protect your data. I am at V4R2, so I’m using the integrated OS/400 toolkit, but if you have the toolkit installed in a lower release as a PRPQ, most of the features I describe should work in the same manner. To find information specific to your release level, check out the online IBM security manuals at http://as400bks. rochester.ibm.com/ bookmgr/home.htm.

Getting Ready to Use the Toolkit

The following guidelines as well as a detailed description of all Security Tools commands can be found in the Tips and Tools for Securing Your AS/400 Redbook that is available for a number of releases.

If you have the Security Toolkit PRPQ installed on your system and you upgrade to a new release with integrated Security Tools (V3R2 or later), you have to make a few minor changes to properly use the integrated version of the toolkit:

• Sign on with a user profile that has *ALLOBJ, *SECADM, and *JOBCTL authorities.

• Run a program to make corrections to job schedule entries to use new command names (CALL QSECFXUP).

• The PRPQ tools are located in a library called QSECLIB, and the integrated tools are located in QSYS. You may need to change any programs, job descriptions, or user profiles that reference the QSECLIB library.

• Since some security tool command names have changed, you’ll have to change any programs or commands that use the old names.

• The PRPQ tools use a print file called QPRPTFIL, but the integrated tools use QSYSPRT, so you will have to change any commands or programs using the old print file.

If you do not have the Security Tools PRPQ installed, you don’t have to do anything except install OS/400 to prepare the integrated Security Tools for use. However, you should follow a few simple rules to keep the security tools themselves secure. All security tool objects and the files they create (usually in the QUSRSYS library) are shipped with the public authority of *EXCLUDE. I suggest leaving the security tools authorities at the default settings. I also suggest running the tools only when signed on as Security Officer. To avoid unauthorized access to printed reports, reroute the reports to a secure output queue. If you follow these simple guidelines, you will have a powerful and secure group of tools to help manage your system.

As usual, you should make sure you use the Save System (SAVSYS) command to back up all system programs, including the security tool programs in QSYS. Also, make sure QUSRSYS is on the backup schedule, because it contains many system objects, including the security tool files.

Protecting the Castle Walls

Two menus are included with the Security Tools: the Security Tools (SECTOOLS) menu for running commands interactively and the Security Batch (SECBATCH) menu for running report programs in batch. Figure 1 shows the first page of the four-page SECTOOLS menu (it includes 52 options), which can be reached by typing GO SECTOOLS on any command line and pressing Enter. The menu is separated into several parts:

• The first section is designed to help manage user profiles.
• The second section allows you to work with security auditing.
• The third section deals with security reporting.
• The final section allows you to set up general system security parameters. Since one of the most useful functions of this menu is management of user profiles, it’s important to understand how user profiles work and how their authorities affect system security. User profiles (*USRPRF-type objects) provide one of the most important layers of OS/400 security. To get a basic understanding of user profiles and their intricate relationship to system security, see “Fundamentals of Security” in this issue of MC.

Keeping Users Honest

The first option on the Security Tools menu, Analyze default passwords (ANZDFTPWD), prints a report of all user profiles that have a password that matches the user profile name (see “Are Your AS/400 Passwords Really Secure?” in this issue for a discussion of password protection). This is an extremely important command only because IBM decided to make the default password the same as the user profile name when creating a new user profile. Although I suggest never allowing the password to default to the user profile name, it’s not uncommon for new or naïve operators to allow the Create User Profile (CRTUSRPRF) command to use the default password name. It is easy to use this technique to create new user profiles and then allow the user to change the password to a unique name, but it’s also important to find out if the user forgot to change the password; if a user doesn’t change his password, any enterprising hacker can easily find a user profile to sign on with. The ANZDFTPWD command allows you to take immediate action if it encounters any passwords that match user profiles:

• *DISABLE will disable the user profile, placing the *DISABLE keyword in the profile’s status field.

• *PWDEXP will set the password expired field in the user profile to *YES.
• *NONE will merely produce the report for you to peruse without taking immediate action.

You should run ANZDFTPWD regularly if there’s even a remote chance that a password might match the user profile name. One way around this problem is to set the password to EXPIRED(*YES) when creating the new profile. The user will then be forced to change the password on the first sign-on. Even though this technique should prevent this problem, I still recommend running the ANZDFTPWD report on a regular basis.

Options 2, 3, and 4 on the Security Tools menu work in tandem with each other to determine your strategy for dealing with inactive user profiles. If user profiles are not used for a long time, they probably either belong to an employee who has left the company or were created for a specific purpose and then forgotten about. In either case, they should be disabled to prevent unauthorized entry to your system.

The first step in the process of cleaning up old user profiles is to run the Analyze Profile Activity (ANZPRFACT) command by choosing option 4 from the menu. This command is similar to the QPWDEXPITV system value, which forces a user to change his password after a specified number of days, but this command works dynamically. It displays a screen in which you enter one value: either *NOMAX or the number of days a user profile can remain inactive before it’s automatically disabled (any number from 1 to
366). When you run this command and specify any value except *NOMAX, any user profile that has been inactive for the specified amount of time will be immediately disabled. In addition, the system will check each user profile daily to see if it has been inactive for the specified time and will disable any profile that reaches that time limit. The system sends a message to the user running the command to indicate which user profiles, if any, have been disabled. If you specify *NOMAX on this command, user profiles will never be considered to be inactive. Although you don’t have to run this command, if you don’t, user profiles will never be automatically disabled unless they reach the QPWDEXPITV limit, which is set to *NOMAX when shipped.

The Display Active Profile List (DSPACTPRFL) command and the Change Active Profile List (CHGACTPRFL) command are accessed by selecting options 2 and 3 respectively. These commands provide a flexible method of protecting important user profiles from being disabled by the ANZPRFACT command (there are 22 AS/400 system profiles, including QSECOFR, QSYS, and QSNADS, that are never considered inactive). For instance, Figure 2 shows the Display Active Profile List (DSPACTPRFL) display containing the profiles I don’t want disabled on my system. You can use the CHGACTPRFL command to add or remove user profiles from this list. These three user profile activity commands give you the power and flexibility to closely monitor user profile activity and to take appropriate action on profiles that are not being used.

Micromanaging User Control

The rest of the user profile options on the Security Tools menu allow you to either schedule user profiles for activation during particular time periods on designated days or schedule user profiles for expiration on a certain date. These options allow you to micromanage user profiles that should be active for designated time periods only:

• Option 5 controls the Display Activation Schedule (DSPACTSCD) command.
• Option 6 controls the Change Activation Schedule Entry (CHGACTSCDE) command, which allows you to add user profile activation schedules, as shown in Figure
3.

• Option 7 controls the Display Expiration Schedule (DSPEXPSCD) command, which displays the current expiration schedule.

• Option 8 controls the Change Expiration Schedule Entry (CHGEXPSCDE) command, which allows you to add user profiles to the expiration schedule, as shown in Figure 4. Notice that the CHGEXPSCDE command allows you to either delete a user profile or merely disable it (in case you might need it in the future).

These four commands give you the flexibility to control exactly when a user can access your system. For instance, if you need to let a consultant use your system for a short time, you can create a user profile that grants him just the authority needed to complete the job and create an activation schedule that allows him to use the system only during your normal business hours. Once you know when the consultant will finish the job, merely add his user profile to the expiration schedule to ensure that it will not remain on your system any longer than necessary. Using the activation and expiration schedules is a good way to avoid security holes caused by high employee turnover or the common technique of using consultants instead of full-time employees.

Use Security Auditing to Track Changes

Security auditing is an important aspect of keeping track of overall system security. Although I’m not going to discuss this issue in detail, I think every shop should be using the AS/400 security auditing feature, since it’s provided as a part of OS/400 at no charge, and it is essential to tracking detailed changes in system security.

Options 10 and 11 on the Security Tools menu allow you an easy way to display and change the system values Audit Control (QAUDCTL) and Audit Level (QAUDLVL) and also allow you to assign the initial journal receiver that will hold the security journal entries (Figure 5). You can set the two system values to audit only a few sensitive actions, such as object deletion and security functions, or you can audit almost every action that occurs on the system. If you’re not using a third-party auditing application, I suggest using the OS/400 auditing feature to keep a handle on at least the most important system events. Although security auditing does use some precious DASD, using this tool properly should help you track down any possible weaknesses in your overall security strategy.

Use Security Reporting Sparingly but Effectively

The AS/400 Security Tools menu offers 20 security reports included with this feature, but they can be run only interactively from the Security Tools menu. Each report is produced by an OS/400 command, and Option 20 provides a direct link to the SECBATCH menu shown in Figure 6 (you can also get there with the GO command), where you run the same reports in batch or schedule them to run periodically with the Add Job Schedule Entry (ADDJOBSCDE) command. These security reports will help you keep track of some of your most important security exposures.

Figure 7 shows a table of all Security Tools reports. The following are some of the most important report commands:

• The Print Adopting Objects (PRTADPOBJ) command prints a report showing objects that adopt authorities.

• The Display Audit Journal Entries (DSPAUDJRNE) command prints a report of designated audit entry types for selected user profiles.

• The Print Communications Security (PRTCMNSEC) command reports on the security of your communication configuration.

• The Print System Security Attributes (PRTSYSSECA) and Print Subsystem Description (PRTSBSDAUT) commands keep track of overall system security.

Other reports keep track of commands, documents, files, folders, libraries, objects, job descriptions, and user profiles.

Since the Security Tools include 20 reports that can be requested using a variety options and parameters, it’s important to use the reports conservatively, drilling down into problem areas without overburdening yourself with reams of paper.

Designing a Realistic but Effective Security Strategy

As I have mentioned, designing an overall system security strategy is a balancing act. You want to keep your system as secure as possible, but you also need to give users the authority they need to do their jobs efficiently. Every manager has to make decisions as far-reaching as setting the QSECURITY system value and as mundane as deciding how much authority to give a new data entry operator. The Security Tools menu contains three commands that can assist an administrator in quickly setting up an overall security strategy: The Configure System Security (CFGSYS-SEC) command (option 50) sets security-relevant system values to the IBM-recommended values, sets up security auditing, and sets some important IBM-supplied passwords to *NONE.

The Revoke Public Authority (RVKPUBAUT) command (option 51) sets public authority to security-related commands to *EXCLUDE, removing any chance that a user could accidentally change important security values.

The Check Object Integrity (CHKOBJ-ITG) command (option 52) check objects owned by a specified user profile for integrity violations and logs any objects that have been altered to a file that can be queried.

Using these three commands, you can quickly set your system to IBM’s recommended security levels. If you want to use different values than those suggested by IBM (the IBM-recommended values are listed in chapter 12 of Tips and Tools for Securing Your AS/400), you can retrieve and change the CL source used by these programs, inserting the values you desire.

The tools and reports that are included in the AS/400 Security Tools give you the power and flexibility to keep your system secure. It’s important to keep up with the constantly changing security needs as more doors are added to your system in this online, networked world. Intelligent use of the AS/400 Security Tools can help you design a well- balanced security strategy that will allow workers easy access to needed information while keeping the castle safe from marauders.

References

An Implementation Guide for AS/400 Security and Auditing, Redbook (GG24- 4200-00, CD-ROM GG244200)

Security—Basic V4R1 (SC41-5301-00, CD-ROM QB3ALB00) Security—Reference V4R1 (SC41-5302-00, CD-ROM QB3ALC00) Tips and Tools for Securing Your AS/400 V4R2, Redbook (SC41-5300-00)

Version 4 Adds New Security Features to the AS/400

Although the AS/400 certainly wasn’t originally designed with e-commerce in mind, IBM has inexorably moved this versatile machine in that direction. The company obviously saw a good match in the rapidly growing Internet and its premier midrange computer. Big Blue began directing the AS/400 toward e-commerce when it included an HTML (HTTP) server in V3R2 and V3R7. That enhancement, while not secure, set the stage for the Version 4 enhancements that included all the native tools (although not all free) that the AS/400 needs to become a full-fledged e-commerce server:

• Native support for Secure Sockets Layer (SSL), an industry-standard encryption standard

• The IBM Firewall for the AS/400 (although not required for secure network computing, I suggest one)
• A secure Web server
• Integrated Java support
• Net.Commerce functionality
• Improved TCP/IP support

The AS/400 has finally come of e-age! The Strategy Designing an Internet security strategy usually involves a combination of tools:
• Firewalls
• Encryption
• Authentication methods
• Antivirus software
• Intrusion detection tools

Since V4R1, a simple yet effective integrated native firewall has been available for the AS/400. It includes all of the technologies needed to keep your system secure:

• Packet filtering software to limit TCP/IP traffic
• Proxy and SOCKS servers to break TCP/IP connections
• Domain Name System (DNS) to hide address information
• Encrypted tunnels to provide secure communications outside firewalls

The IBM Firewall for AS/400 consists of software executing on an AS/400 Integrated PC Server (IPCS). One port is connected to the secure corporate network, and the other port is connected to the Internet. All communication between the corporate network and the Internet must pass through the firewall. The IBM Firewall for the AS/400 requires a RISC model, a dedicated IPCS with two communication ports, the IBM TCP/IP Connectivity Utilities for AS/400, and Integration Services for FSIOP. Since the IPCS is a separate dedicated processor, security functions are isolated from all business processes, ensuring maximum security with minimum performance degradation. Firewalls provide excellent protection from outside intrusion, but they still can’t stop the janitor from stealing information. Nor can they protect your data once it is out of your secure network and on the Internet. Keeping the Secret Once data is transmitted over the Internet, the only way to protect it is with some form of data encryption. There are many valid encryption schemes, all involving some sort of mathematical formula. The basic concepts are fairly simple to grasp. All messages (data) start out as plain text or clear text, which is simply regular written language. The encryption process involves translating (encrypting) this plain text to cipher text to hide the original meaning. Finally, cipher text is decrypted back to plain text so the recipient can read the data.

Previous to V4R1, the only encryption options open to the AS/400 were third-party solutions. Now, an AS/400 running V4R1 or 2, IBM TCP/IP Connectivity Utilities for the AS/400, and Internet Connection Secure Server can use the industry standard Secure Sockets Layer (SSL) protocol to provide data encryption. SSL is a very secure method of encryption that combines public-key and symmetric-key cryptography to provide an efficient means of safe data communication.

Though the AS/400 is inherently secure, IBM offers many security products for the AS/400 through its SecureWay product family. The Common Cryptographic Architecture Services/400 (CCAS/400) PRPQ provides the AS/400 manager with the support necessary to use the IBM 4755 Cryptographic Adapter Card, which provides DES, RSA, and support for other encryption algorithms. It provides for encryption, decryption, key management, and Personal Identification Number (PIN) processing. This is a relatively new offering that is designed to support a common set of interfaces known as the Transaction Security System (TSS). The 4755 Cryptographic Adapter uses the Common Cryptographic Architecture (CCA) to support

interoperability across multiple workstation and host environments, including DOS, OS/2, and AIX. CCAS/400 also supports the IBM Personal Security card and other security interfaces. SSL and the new security features of V4R1 will eventually supercede this facility, but it will take time for most customers to complete the upgrade process. For more information on the IBM security product line, visit the security Web site for IBM: http://www.ibm.com/security. —DG

Figure 1: Security Tools menu

Figure 2: Display Active Profile list

Figure 5: Change security auditing

 Figure 6: Security Tools batch menu

Also Read

IBM i Security Essentials: 4 Components for an Effective Strategy

New IBM i Security Features and a Farewell

Securing IBM i: A Dual Responsibility