The latest announcements from IBM contained many security enhancements and changes. Carol describes her faves.
An IBM announcement hasn’t contained this many security enhancements and changes to IBM i security in many years. You can find information on all enhancements and previous supported releases here.
QSECURITY Level 20 Cannot Be Specified
At IBM i 7.5, 20 is no longer a value that can be specified for the QSECURITY system value. The behavior is the same as when we took away the ability to specify level 10 when I was the IBM i Security Team Leader. If the system is at level 20 and is upgraded to IBM i 7.5, the system will remain at 20. But if you try to restore a system that was saved at level 20, the QSECURITY system value will remain at the value prior to the restore. For example, if the system was at the default value of 40, the QSECURITY system value will remain at 40 even though the saved value of QSECURITY was 20.
Unfortunately, numerous organizations still have systems running at level 20. I’m hoping this change will motivate those organizations to pay closer attention to security sooner rather than waiting to address it when they upgrade.
New Password Level (QPWDLVL)
IBM i 7.5 provides us with a new password level. Over the years, the strength of encryption algorithms has increased, and that’s what password level 4 provides us: a hash that’s been generated using a stronger encryption algorithm. At password level 4, the only hash that is stored is the one created with the stronger algorithm.
Now remember, the IBM i passwords aren’t actually stored. They’re used as input to a one-way encryption algorithm that results in a hashed value. It’s the hashed value that is stored. When you provide a user profile name and password, the same algorithm is run and the hashed values are compared to determine if you have provided the correct password.
Another enhancement for the password levels is that the old LanMan password that was stored at password levels 0 and 2 is removed when upgrading to IBM i 7.5. This is an awesome step IBM has taken. That password was used only when a user mapped a drive to the system via a file share from a workstation running Windows 95, 98, or ME or Windows 2000 Server. I have long recommended to my clients that they move to a level that doesn’t store this vulnerable hash (that is, password levels 1 and 3). I’m hoping that IBM’s removal of these old hashes will give more organizations the confidence to move to one of these levels now if they can’t upgrade to IBM i 7.5 in the near future.
Secure Shares with an Authorization List
One of the most significant enhancements of the 7.5 release is the ability to associate an authorization list with the NetServer itself as well as individual file shares. This enhancement will allow organizations to more easily take control of who can connect to the system via a file share. Those users with authority to the authorization list associated with the NetServer can use file shares. No authority? Attempts to use a file share will fail.
Authority to an authorization list that’s been associated with a specific file share is a bit more meaningful. If a profile has *USE authority, they will be able to map a drive as a Read-only share. *CHANGE or greater authority will allow the user to connect with Read/Write privileges (assuming that the file share itself has been created as a Read/Write share). Why is this enhancement so important? Because file shares are the gateway that ransomware and other malware uses to gain access to the system. If organizations adopt a very restrictive policy for who can access the system via file shares, the risk of malware infection will be lowered. The risk will be reduced to just the profiles with authority to use the shares and have authority to the object being shared. Remember, however, that any profile with *ALLOBJ has authority to all authorization lists associated with the NetServer and file shares as well as the objects shared. In other words, any profile assigned *ALLOBJ has access, so don’t bother attempting to control access via this new feature; this method won’t stop them.
More Audit Journal Entry Table Functions
Once again, IBM has provided us with more table functions that parse out the details of the audit journal. I’ve written about these in prior articles and can’t emphasize enough how much easier it is to get the information out of the audit journal using these table functions rather than using the traditional method of running the Copy Audit Journal Entry (CPYAUDJRNE) command and then using either a query or SQL to find the information you’re looking for. The following table functions are available with IBM i 7.5, IBM i 7.4 TR6, and IBM i 7.3 TR12:
- JS – Job Start (SYSTOOLS.AUDIT_JOURNAL_JS)
- ST – Use of Service Tools (SYSTOOLS.AUDIT_JOURNAL_ST)
- OM – Object Management (SYSTOOLS.AUDIT_JOURNAL_OM)
Details about all available table functions can be found here.
Audit Journal Entries in New Nav
Because of these audit journal table functions, New Nav can provide a graphical view of audit journal entries! This is a first and a very important enhancement for the Navigator interface. You can chart the number of entries over time for a specific type (for example, invalid signon attempts), enabling you to easily spot peaks in activity. Or you can see the list of detailed entries, easily selecting the fields that are most important and using filters on the columns to get to the entries you’re interested in. To try this new interface, log into New Nav, click on the padlock icon and choose Audit Journal Entries.
There’s a lot of useful information in the audit journal that people either forget about or are unaware is available. I’m hoping that by providing a graphical interface to the audit journal more people will be able to make use of this valuable information.
Mastering IBM i Security
I’m very excited to announce the release of my new book: Mastering IBM i Security. This is a how-to book that provides practical examples of using modern interfaces—SQL Services, Authority Collection, New Nav, and the Audit Journal—for implementing and managing IBM i security. Also included are discussions and examples of how to use the new IBM i 7.5 features, such as the ability to associate an authorization list with a file share. In addition, I’ve documented steps for processes that I’ve used with my clients throughout the years—such as moving to a higher password level and moving from QSECURITY level 20 to 40 and 30 to 40, to name a few. These are tips that aren’t documented anywhere else. SQL files containing all of the examples in the book are available for download so you can easily use and customize the SQL for your own use.
Mastering IBM i Security is a companion book to my other book IBM i Security Administration and Compliance, Third Edition. This other book provides a thorough explanation of how IBM i security works as well as discussions of security best practices. Mastering IBM i Security builds on this foundation to provide you with examples to more easily implement the concepts. I’m very excited about this pair of books and hope you will be too. Click here to order.
I have described only a few of the enhancements and changes in this release. Be sure to go to the link provided above to read the full list. The fact that IBM has put so much emphasis on security in this release is a testament to the fact that IBM “gets” the importance of protecting our data. We should be grateful that IBM pays attention and responds to the latest threats, customer compliance requirements, and the need to make managing security easier to accomplish. I hope your organization is able to upgrade soon so that you can take advantage of these important enhancements.