IBM ships several tools to make securing the system easier…but are you using them? Carol describes the tools’ features and explains how to use them.

I’m still surprised when I describe commands or features of IBM i that assist with securing the system or managing security settings and people aren’t aware of them or aren’t using them. So today I’d like to describe some of these commands and features and, hopefully, you’ll find something that will help make your security life easier.

Security Tools

While I was still team leader for the security team at IBM, we developed a set of tools and reports. They are accessible by typing GO SECTOOLS, which will take you to the Security Tools menu. Many of the menu options are various reports that list the security attributes of various object types. For example, you can run Print User Profile (PRTUSRPRF) and get a spooled file of all the user profiles on the system or Print Queue Authority (PRTQAUT) to see the attributes of outqs and jobq. One of my favorite reports in this set is Print Private Authority (PRTPVTAUT). Running PRTPVTAUT OBJTYPE(*DIR) DIR('/') produces a report of the authorities to all of the directories under the root (/) directory. This allows me to get a sense as to whether an organization has done any work to secure the Integrated File System (IFS).

Another command that I find helpful is Analyze Default Password (ANZDFTPWD). As the name implies, it lists all profiles that have a default password—that is, a password that is the same as the user profile name. Even though you can now prevent profiles from being created with or changed to have a default password by specifying *LMTPRFNAME and *ALLCRTCHG in the QPWDRULES system value, I still see many organizations with profiles that have a default password. This report allows organizations to identify profiles with a default password so that they can be changed and not remain a vulnerability.

Two commands address audit settings. One, Change Security Auditing (CHGSECAUD), assists organizations that have never previously configured auditing. The command creates the QAUDJRN journal, an audit journal receiver, and attaches it to QAUDJRN and sets the QAUDCTL and QAUDLVL system values. The other command, Display Security Auditing (DSPSECAUD), displays the current audit settings, including the name of the currently attached receiver. I use this command to determine the naming convention of the audit journal receivers.

The final commands I’ll describe allow organizations to manage inactive profiles. Options 2–4 on the SECTOOLS menu allow you to define the number of days a profile is to be inactive before being set to status of *DISABLED as well as profiles you want to eliminate from this analysis. IBM has already omitted the IBM-supplied profiles, but organizations may want to eliminate service accounts or other profiles that they want to make sure are never set to *DISABLED. Once you specify the number of days using option 4, a job is scheduled that runs shortly after midnight to look for inactive profiles. The dates in the user profile that are used to determine inactivity are last used date; if that is blank, the creation date; and then the restore date.

Check Object Integrity

The command Check Object Integrity (CHKOBJITG) is a “self-check” for the operating system. At a minimum, you want to specify to check all of the objects owned by the profile QSYS. When you do that, it will validate the digital signatures of the operating system objects, verifying they’ve been shipped by IBM and not modified since installation as well as check to make sure no programs are masquerading as IBM programs. Read the command’s help text to find out the type of results you may receive. When in doubt, contact IBM to verify whether you’ve got an issue. Don’t panic if the results identify some “suspicious” objects. Issues may be raised if the object is too old for the check to assess it accurately. Note: CHKOBJITG can be a bit compute-intensive, so schedule it and run it with low priority if your system is CPU-constrained.

Group Profiles

I’m still surprised by the number of organizations that don’t use group profiles. Group profiles allow you to more easily manage users who need the same set of authorities—perhaps a department or a specific role, such as programmers or operators. I am a big fan of using group profiles to implement role-based access. Put special authorities and any private authorities at the group level, and all members will have that authority, rather than granting the authority to each individual user. Group profiles also help preserve authorities if a user profile must be quickly removed from the system, such as when a user is dismissed from the organization. If authorities are granted to the group rather than the individual, deleting the individual profile can easily be accomplished. Then, when the role is filled again, all you have to do is put the user in the group and the user will have the access required to perform the job function.

Authorization Lists

Authorization lists allow an administrator to manage a set of objects to which certain users need the same authority. Rather than grant authority directly to an object, you grant the user or group authority to the authorization list. Then, whatever authority the user (or group) has to the authorization list is the authority they have to every object attached to the list. I find that authorities to authorization lists are easier to review than lots of private authorities granted to individual objects. Also, the more private authorities you have, the longer your Save Security Data (SAVSECDTA) takes, so using authorization lists has the benefit of reducing the time of your SAVSECDTA.

FIELDPROC

FIELDPROC was added in V7R1 and provides the ability to configure a field to be encrypted. That part is free. Full disclosure: What isn’t free is the encryption product that you’ll need to “plug in” for the encryption/decryption part of this feature. But more on that in a minute. What’s so cool about this feature is that IBM has hidden the storage of the encrypted data in the internal portion of the file. What this means is that you no longer have to rewrite your application when you want to encrypt a field. Prior to FIELDPROC, you had to accommodate the encrypted value yourself, which meant that you had to either increase the size of the original field to hold the encrypted value or move the value to a new field. Both techniques caused any program using the file to be recompiled. That was in addition to having to call the encryption and decryption routines at the appropriate places in the application. Now, the encryption/decryption routines are automatically called when the field is accessed. This is where the not-free portion comes in. While you could write the encryption and decryption routines yourself, I highly recommend that you investigate a third-party solution such as Powertech Encryption for IBM i instead. Far more difficult than the actual encryption/decryption routines is the key management aspect of encrypting data. Let someone else who has experience with encryption do that work for you. If you mess up the encryption keys, you won’t have any data to decrypt! So it’s important that key management is implemented correctly and securely and with the features you may require to comply with various laws and regulations (such as split knowledge of keys, key rotation, etc.).

Why am I mentioning FIELDPROC in this article about free features? Because I see increasing interest by organizations to encrypt their sensitive and confidential data, but they’re not familiar with FIELDPROC. Therefore, I’ve included it here so you know about this important feature of the operating system.

RCAC

Row and Column Access Control (RCAC) was added in V7R2. Row access control allows you to define SQL permissions to limit what records users or groups are allowed to see. You can use a traditional model to show only records associated with a particular value in a field, such as a department or location number. Or you can be more creative and limit access to fields during specific times, such as evening hours or weekends. The column permissions allow you to mask data. For example, if you don’t want testers to see full customer addresses, you can mask the address field for all users in the TEST group.

Now while this is a powerful function, if your requirement is to encrypt data, this will not satisfy that requirement. The data is in cleartext on the disk. And using the masking function along with full disk encryption on IBM i will also not comply with encryption requirements. That’s because the only time the data will stay encrypted is when the IBM i disk is removed from the disk array. Otherwise, accessing the data automatically decrypts the data. That said, this feature may be useful when encryption isn’t technically feasible, such as when a field containing Personally Identifiable Information (PII) data has been defined as a key field (since you can’t encrypt a key field). For a good description of RCAC, see the Redbook Row and Column Access Support in DB2 for IBM i.

Application Administration

Usually, when you want to restrict access to say, a database file, you simply exclude the user or *PUBLIC. The premise behind Application Administration is that it provides you with a method of restricting access when there’s no object to secure.

Application Administration is divided into three sections. The first allows you to restrict which Navigator for i features users are allowed to see. The second allows you to restrict access to features of Access Client Solutions (ACS), and the third restricts access to various functions on IBM i. While the first two are definitely useful, it’s the third that I think provides the most value. My favorite features are the ability to allow a user with *JOBCTL special authority to view the joblog of an *ALLOBJ user. This has helped many organizations remove the requirement for developers to have *ALLOBJ on production systems because it allows the developers to debug production jobs that are running as a profile that has *ALLOBJ. Other favorite features include the ability to shut off users from using FTP, ODBC, and DDM/DRDA. Now if you’re looking for detailed logging of access or the ability to configure usage to be granular (for example, users can download all files except for FILE_X or upload only from a specific IP address), you’ll need to explore an exit point solution. However, while this feature is not a substitute for a full-featured exit point solution, it does the trick when all you want to do is completely shut off access for selected users.

Authority Collection

Introduced in V7R3, Authority Collection allows you to know exactly what authority is required for each object a user is accessing. In V7R4, Authority Collection was enhanced to allow you to collect information on which profiles are accessing a specific object (regardless of whether it’s in a library or a directory) and, again, know exactly what authority each user requires to the object. You no longer have to guess what authority is required. For examples, see my previous articles on the topic “Three Ways to Use IBM i Authority Collection” and “New Release! What New Security Features Does IBM i V7R4 Bring Us?”

Summary

IBM provides many opportunities to ensure that your data stored on IBM i is able to be secured and that you can manage your security configuration. While these tools may be rudimentary and there are definitely vendor tools that are more thoroughly implemented and easier to use, these tools are free. If you have no budget to purchase a vendor solution and are looking for ways to simplify the administration of security on your system, check out these features.