In this article, Carol describes the system values, user profile attributes, and access control settings she'd recommend that auditors pay attention to.

I’m dedicating this article to auditors. I’ve found that many auditors have either never heard of IBM i or, if they have, don’t know how to audit it properly—that is, they miss key elements, or they use checklists developed 10 or more years ago, and the settings to be compared are often irrelevant or inaccurate. The capabilities of this operating system are vast, and the need to ensure the security principles of confidentiality, availability, and integrity apply just as they do on other operating systems. Let's take a look.

What Should You Be Examining?

There are key areas of the system that need to be examined. I’m not going to explain the details of each as that’s been done in other parts of this book, but here’s the list that I’d suggest you examine to ensure they’re set to best practices:

System Values

• QSECURITY
• QPWDLVL
• QPWDRULES or the other, individual system values that define password composition
• QPWDEXPITV
• QMAXSIGN
• QAUDCTL and QAUDLVL
• QSSL*—Specifically QSSLPCL to ensure only strong protocols are in use
• QCRTAUT—Ensure it’s never set to *ALL, meaning all newly created objects are created with the default (*PUBLIC) authority set to *ALL

While there are many other security-related system values, these are the ones that are critical to ensuring a secure system. For example, if QSECURITY is set to level 20 or 30, users can easily elevate their own privileges at will and neither operating system nor data integrity is guaranteed. If you are going to state that the audit of your client includes data integrity and/or confidentiality, the partition must be running at level 40 or 50. Period.

User Profile Attributes

• Passwords
  • Default Passwords—No valid excuse exists for profiles having a default password (a password that’s the same as the user profile name).
  • PASSWORD(*NONE)—Note that this is actually a good security measure and is not a vulnerability on IBM i (as it is on some operating systems). Profiles without a password cannot be used for signon or a connection to the system.
• Special Authorities—The capabilities provided by each special authority are described in Chapter 4. Assignment of each special authority needs careful examination. A special authority should not be assigned unless that user’s job function requires it. Most organizations have not implemented role-based access; therefore, many special authorities have been over-assigned. Often this occurs because an existing user’s profile is copied, rather than copying a “template” that has been configured with least privilege access and then modifying the profile accordingly.

Obviously, *ALLOBJ special authority is the capability to be scrutinized most. That’s because it provides *ALL authority to every object (file, command, program, library, directory, etc.) on the system. Considering least-privilege access, the only roles that should have *ALLOBJ are that of the system and security administrators. And please note, you must allow some profiles to have this authority! *ALLOBJ cannot be removed from all profiles. The OS requires the profile running some administrative tasks to have this special authority. And while there are vendor products that allow one to elevate one’s privileges—eliminating the need to have *ALLOBJ assigned to some profiles—they only work well in the “green-screen” environment. IBM ships some features that are available only in the Access Client Solutions (ACS) or Navigator for i browser interfaces; therefore, *ALLOBJ must be assigned directly to the profiles using these interfaces. If you insist on having *ALLOBJ removed, system administrators either will not be able to perform their jobs or will be forced into using the system-supplied, all-powerful profile QSECOFR, and that is not appropriate. QSECOFR should not be used for routine tasks. It should be used only to upgrade the operating system. Bottom line is that a small number of user profiles will need to have *ALLOBJ directly assigned to their profile to allow them to perform their system administrative duties.  

• Group and Supplemental Groups—Don’t just look at the capabilities of the profile named as a user’s group profile. Make sure to also look at the profiles named in the supplemental group attribute. You must sum up the capabilities given to all of a user’s groups to determine the full capabilities granted to that user. Remember that special authorities assigned to the group(s) filter down to all of the members. For example, *ALLOBJ special authority assigned at the group, is, in effect, given to all members of that group. The same with private authorities and object ownership. If the group owns an object, all members, in effect, own the object and therefore have all rights to the object.
• Limited Capability—Most users should be set to LMTCPB(*YES), meaning that if they can get to a command line, they can run only the commands that are allowed to be run by a limited user. By default, only a handful of commands are shipped with this configuration—commands such as SIGNOFF, Display Message (DSPMSG), etc. My goal with our clients is to have no more than 100 profiles set to LMTCPB(*YES) on their production partitions (this number includes IBM-supplied as well as vendor profiles). Development and QA partitions typically have more, and that’s usually appropriate for that type of system. This number may also be inflated if the organization has hired an outside vendor to help them manage their system. Each vendor profile will typically have administrator rights (i.e., *ALLOBJ special authority) as well as be set to limited *NO so they can manage the system.
• Password Expiration Interval—This is one of the attributes that can be overridden at the user profile level. On occasion, I see a reasonable expiration interval set at the system value (QPWDEXPITV) but all user profiles set to *NOMAX, meaning that the user’s password never expires and, therefore, never has to be changed. More frequently, I see administrators set their own profiles to have a non-expiring password. The only profiles that should have a non-expiring password are those that are considered a “service account”—that is, a profile that is used to make connections to the system and for which a regularly expiring password could cause significant disruption in the business process associated with the profile.

Note that I have mentioned nothing about the User class attribute of the user profile. I see way too many auditors focus on this attribute when it is absolutely meaningless as an indicator of a user’s capability. It is never used by the system to check authority—in other words, it is never used to determine if a user can access an object or perform a task. User class is a way for administrators to initially configure which special authorities the user is granted, but after that, it is virtually meaningless. If you are looking at the user class attribute and assuming that because all profiles are set to *USER they have no special authorities, you couldn’t be more wrong. Even as the profile is created, you can set the user class to *USER and grant the profile all special authorities, including *ALLOBJ. Conversely, I could create a profile in the *SECOFR user class and grant them no special authorities. Stop looking at the User class! Forget about User class and examine the special authority attributes to ensure you have an accurate picture of users’ capabilities.

While there are other attributes of the user profile that you may want to examine (except for User class!), the ones I’ve described here are the primary attributes that define users’ capabilities.

Authority to Data

While most auditors do a great job of evaluating user profile capabilities, I’ve seen very few correctly assess access to data. I understand that it depends on the scope of the audit as to what database files need to be examined. But if you need to evaluate who has access to specific data—whether it’s financial, healthcare, PCI, or PII—you need to look beyond the application settings—that is, beyond the menu options users have been granted. To accurately evaluate who has access to the data, you must look at the object authorities and ownership of the database(s). Many administrators will tell you that “users only have access to data via the menu options provided to them.” And there is some truth to that statement. It’s true in the context of when the user accesses the application interfaces—for example, through a green-screen menu or via a browser interface. But unless a deny by default access control setting has been implemented, users can gain access through other interfaces outside of the application interfaces using protocols such as ODBC, FTP, or SSH, for example, or users with command line access (those configured as limited *NO or *PARTIAL) can read or modify the file through any number of vendor- or system-supplied commands.

To fully assess users’ access to data, you must look at the *PUBLIC authority setting, the list of any private authorities granted as well as the primary group if one has been assigned, along with the users and groups authorized to the authorization list if the object is secured by one. In addition, you must look at the object’s owner. If the owner is a group profile, every member owns that file—in other words, has *ALL authority to the file. If all application users are a member of that group, then all application users have *ALL authority to all data in the application; they are not simply only authorized to the menu options assigned. They have full authority to the entire application! And, unfortunately, this is the way many application vendors configure their applications—that is, they require application users to be a member of the profile that owns the application. In addition, as the system ships, the default *PUBLIC authority when an object is created is *CHANGE. So, unless changed, database files by default are created with a default access control setting (*CHANGE) that allows the files to be read or modified by any profile on the system. It goes without saying that this scenario poses a significant risk to the confidentiality and integrity of the data.

Summary

While not a comprehensive list of all areas that need to be audited, I hope that you’ve found this discussion of the most critical to be useful. I’m passionate about the need to adequately and correctly audit this system because it contains many organizations’ valuable data. If this helps one of you perform a more thorough or accurate audit of the system, then I’ve done my job.

 

Carol Woodbury is IBM i Security SME and Senior Advisor to Kisco Systems, a firm focused on providing IBM i security solutions. Carol has over 30 years’ experience with IBM i security, starting her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies: SkyView Partners and DXR Security. Her practical experience and her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known worldwide as an author and award-winning speaker on security technology, specializing in IBM i security topics. She has written seven books on IBM i security, including her two current books, IBM i Security Administration and Compliance, 3^rd Edition and Mastering IBM i Security, A Modern, Step-by-Step Approach. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.

---

MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

		IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
		Mastering IBM i Security Get the must-have guide by the industry’s #1 security authority. List Price $49.95 Now On Sale

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