Carol discusses things that are a bit puzzling when it comes to IBM i security settings.
I wish I could link to a video of my 20-month-old niece putting her chubby little index finger on her chin, cocking her head slightly, and saying “Hmm.” So cute but so darn accurate for this article. Here are some configuration settings examples that have seriously made me say, “Hmm…what was the administrator thinking when they did this? This makes no sense.”
Misconfiguration occurs, I believe, due to ignorance or lack of understanding about how things really work. So I thought I’d share some of these settings incidents that puzzled me in hopes that, if you’ve also made these mistakes, you can gain understanding and correct the misconfiguration.
Password Expiration Interval
The password expiration interval is controlled first at the system-value level and second at the user profile. Whatever is specified in the user profile overrides the value specified in the QPWDEXPITV system value. What I find puzzling is when the system value is set to *NOMAX, meaning that the password never expires, and then overridden in all user profiles with the actual expiration interval—typically, 90 (days).
While, in theory, this works, there are risks associated when creating a profile regularly used for sign-on (versus a service account) with a non-expiring password. In addition, any auditor who knows anything about IBM i knows to examine the system-value settings. They will quickly identify that the setting for the QPWDEXPITV system value means that no profiles have to change their password. Now you’re forced to take time to explain to your auditor that no, in reality, profiles do have to change their password. Why put yourself into this position? I recommend that the system value be set to the organization’s password expiration interval and then the exceptions set in the user profile. And while I was already planning on including this example anyway, this exact scenario was described to me by one of the clients I worked with this past week!
Modifying User Profile Authorities
When a profile is created, the *PUBLIC authority is set to *EXCLUDE and the profile is granted authority to itself—*CHANGE and *OBJMGT to be exact. In addition, if the profile is a member of a group, the member is granted *OBJOPR, *OBJMGT, *READ, *ADD, *UPD, *DLT to the group profile. These authorities should be left as is and not modified. Each is required for normal operations. Several scenarios surrounding these settings make me say “Hmm.”
First, I’ve seen organizations remove the profile’s authority to itself. Now I said that these authorities are required for normal operations. If you remove a profile’s authority to itself, the profile cannot be used for signon. So how is their configuration working? The profile is owned by the profile’s group; therefore, it has sufficient authority through itself (through its group.) But why? Why change the authority? I’ve never been able to come up with a legitimate reason for doing this, and it can definitely be problematic. For example, when the user’s group changes but the ownership of the profile doesn’t, the profile—suddenly—can’t be used for signon.
Another profile authority modification I see is granting a member *EXECUTE authority to the user’s group profile in addition to the authority already granted. Granting *EXECUTE means that the member has *USE authority to their group and therefore can submit jobs and run as their group rather than themselves. This practice makes you lose accountability. That is, you cannot determine who is actually performing a task. Again, it’s not required by the system and is obviously problematic; therefore, it should be avoided.
Granting Profiles with *ALLOBJ Private Authorities
Two scenarios under this category make me say “Hmm.”
The first scenario is caused, I believe, because people don’t understand the order in which IBM i checks authority. What I often see is a private authority of *EXCLUDE granted to a profile that has *ALLOBJ. This is a waste of time because, when the system checks authority, the first thing that’s checked is to see if the user has *ALLOBJ. If they do, access is granted and the algorithm ends. Any private authorities the user or their group(s) has is never checked.
The other scenario that really makes me go “Hmm” is when a profile with *ALLOBJ is granted a private authority of *ALL, especially when the profile is QSECOFR. Why anyone would ever think that QSECOFR needs any additional authority is truly beyond me. Again, it’s a waste of time to grant these authorities! Also, these private authorities only slow down your Save Security Data (SAVSECDTA) process unnecessarily.
Authorities to Authorization Lists
Two scenarios with authorization lists also make me say “Hmm.”
The first authorization list scenario is when an object is secured with an authorization list, but the *PUBLIC authority of that object has not been pointed to the list. In other words, the *PUBLIC authority of the object has not been set to *AUTL. It’s not as confusing if the *PUBLIC authority of the object and the list is the same. But when it’s different, I have to wonder which one the administrator meant to be in effect. In this case, the setting on the object will be the *PUBLIC authority used. To avoid confusion, I recommend that, when securing an object with an authorization list, you set the *PUBLIC authority of the object to be *AUTL so that the *PUBLIC authority comes from the authorization list.
The second scenario when working with authorization lists is when the *PUBLIC authority of the list is something other than *EXCLUDE—say, *USE or *CHANGE—and individuals or groups are granted *EXCLUDE to the list. If there are users who shouldn’t have access to the objects secured by the list, why isn’t the list set to *PUBLIC *EXCLUDE and users or groups granted access? When I see this scenario, the authorities always seem backward to me. Why would you want to put yourself in the position of having to remember to exclude certain users/groups if not all profiles on the system should have access to these objects?
Profiles Set to PASSWORD(*NONE)
What makes me say “Hmm” when a profile doesn’t have a password (that is, the password is set to *NONE) is when the password expiration interval is set to *NOMAX. What you do by using this configuration is unnecessarily cause the profile to show up on the list of profiles with non-expiring passwords. And now you have to explain to your auditors that there’s actually no danger because the profile doesn’t have a password. Since the profile doesn’t have a password, the expiration interval is never examined; therefore, you should leave the password expiration interval at *SYSVAL.
Private Authorities Granted to Commands and APIs
One of the services the Professional Security Services team at HelpSystems does is perform Risk Assessments. Our Risk Assessor product is used to help us gather data reports on the authorities of several commands and APIs for which you may want to restrict access. Periodically, I’ll see an operator or developer group or an individual that’s been granted authority to every command and API that we list in this report. When I see this, it’s quite likely that they’ve been granted authority to every command and API in the library QSYS. The puzzling aspects of this scenario is why was this done and how it’s accomplished each upgrade. Why would an administrator think that operators need authority to all commands? Did a developer slyly add granting themselves authority to all commands when writing a program to run after each upgrade, perhaps to set command default that the organization changes to meet their needs? I’ve never heard a legitimate reason for this, and when it’s brought to the security administrator’s attention, the authorities are typically removed.
Summary
I hope you’ve enjoyed this discussion on these security configuration settings that are puzzling to me. If there’s a setting I mentioned that you recognize—that is, it’s configured that way on your system—I encourage you to take the time to re-work the misconfiguration.
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, 3rd 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
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online