Carol provides the first part of a two-part article on the security enhancements introduced in V7R2.

Each new release of IBM i provides some enhancements, but this version provides a plethora of security-related enhancements—so many that I need two articles to cover them all! I'll start with the areas that have been "tidied up."

Have you ever looked around your house and realized that several rooms or appliances could use updating? Perhaps your furnace is below the current building codes for efficiency. It's functional but not up-to-date. Several enhancements in V7R2 fall under this category:

• Cipher algorithms used for SSL have been brought up to industry standards. Older algorithms have been removed, and the order in which the algorithms are negotiated on a connection have been adjusted. You can see these changes by displaying the QSSLCSL system value.
• A new version of Java has been included.
• Web servers have been brought up-to-date, including new authentication methods, updated encryption support, and the ability to run two websites on the same server—each with their own digital certificate (rather than having to use the same certificate for both).
• Portable Application Solutions Environment (PASE) has been updated to run the most current AIX version (V7.1).
• The OpenSSL version in use within PASE is now V1.01g. Don't worry; this is not the version with the Heartbleed bug!
• If you're using the IBM i VPN feature, IKEv2 NAT (Network Address Translation) support is now available as well as advanced Internet Key Exchange (IKE) and Internet Protocol security (IPsec) encryption algorithms. 

Changes to User Profiles

Create/Change/Display User Profile commands have a new parameter to support the new maximum storage allowed for a user profile. I'm sure the limit was being reached for application profiles owning terabytes of data when a value was specified. The new parameter is Maximum Storage Large (MAXSTGLRG). Note: if the value in the current Maximum Storage (MAXSTG) parameter is *NOMAX, no changes are required. However, if you are using the Retrieve User Profile command or API to retrieve the storage used, you may want to change to retrieve the MAXSTGLRG attribute rather than the MAXSTG attribute.

The next enhancement is not to the profile itself but has an effect when creating or changing user profiles. A new value was added to the list that can be specified for the QPWDRULES (password rules) system value. This value, introduced in V6R1, provides more options for specifying password composition rules and replaces some of the system values that require you to specify password composition rules individually—for example, you can use the *MAXLENx and *MINLENx values in QPWDRULES to replace the QPWDMAXLEN and QPWDMINLEN system values. While the QPWDRULES system value and its options were introduced to provide the ability to more easily match the password requirements of your network or other corporate password rules, the new value introduced in V7R2 has meaning only in the IBM i world. The new value is *ALLCRTCHG, and it means that all passwords—even those specified when creating a user profile or changing a user profile—have to meet the password composition rules. This means that if you specify *ALLCRTCHG along with *LMTPRFNAME, no profiles can be created or changed to have a default password! Hallelujah! But wait. Before we celebrate too much, there are a couple of issues that need consideration. First, vendors take note! If you are creating a profile when you install your software, you'll no longer be able to create it with a default password. Leaving it at the default will cause the profile creation to fail. So create your profiles without a password (that is, set the password parameter to *NONE) and you'll be good to go. While all of us (with the possible exception of the vendors) are thrilled by the prospect of eliminating vendor profiles with default passwords, there are potential side effects that you'll want to think through. Consider your user profile creation process. You'll no longer be able to create a profile with a default password. You'll have to come up with a password that meets the password criteria and communicate that to the person for whom you're creating the profile. You'll still want to require the users to change their passwords the first time they log on, but the initial process of creating the profile and communicating the password might have to be altered. Second are password resets. The typical scenario is that the users forget their passwords, attempt to sign on until the profile is disabled, and then call the help desk to get a password reset. The process is typically that the profile is enabled, the password is set to something simple, and the indicator is set so the user will have to change it when signing on. That part about setting the profile to something simple will have to be modified. The password will have to match all composition rules. So while I'm thrilled with this enhancement to QPWDRULES and will be recommending its use to our customers, it will come with the warning that user profile processes first be reviewed and updated if necessary.

A side note about QPWDRULES: once you add a value to QPWDRULES, the system values that let you define individual rules are ignored; therefore, you must add all of your composition rules to the list in QPWDRULEs.

Auditing Updates

Several changes have been made to the IBM i auditing features.

Two new values are available to specify for action auditing in the QAUDLVL system value. These are *PTFOBJ (Changes to PTF objects) and *PTFOPR (PTF operations). The reports you can generate from these values will be great as proof of compliance to your auditors or other regulatory agencies that want to see the implementation of your "patch strategy" or, in IBM i terms, your strategy for when you apply PTFs.

New audit journal entry types have been added: AX (Row and Column Access Control, which will be discussed next month), PF and PU (to support the new PTF values described above), and X2 (Query Manager Profile changes.)

Several existing audit journal entries have been enhanced to provide the "before" values for security attribute changes. Some audit entries, such as the SV (system value) entries and the OW (ownership change) entries already include the previous values. In V7R2, the following entries also include the previous setting:

• AD—Auditing value changes
• AU—Attribute changes
• CA—Authority changes
• CP—User profile changes (Note: only the previous special authority values have been added)
• DI—Directory server
• GR—Generic record (added changes to the function usage (Application Administration) settings)
• PA—Program adopt
• PG—Primary group changes
• RA—Restore object authority changes (added the name of the authorization list)
• RJ—Restore job description (added name that had been specified in the job description)
• RO—Ownership changes for restored objects
• RZ—Primary group changes for restored objects

The ST entry had information added for when storage gets modified through the use of service tools. And finally, other audit entries have been taken out of commission. They were for some APPN functions that are no longer supported.

For details of these updates, see Appendix F in the IBM i Security Reference manual.

Miscellaneous Enhancements

You have long been able to use Kerberos as an authentication method to Telnet from your PC to an IBM i session. (Kerberos is the authentication method used when implementing Single Sign-on on IBM i.) What's been missing is the ability to Telnet from one IBM i to another using Kerberos. That functionality was added in V7R2. Another piece that was missing was the ability to use Kerberos to initiate an FTP session. That ability is now also available, both for the FTP client and the FTP server running on IBM i.

Work with Objects by Owner (WRKOBJOWN), Work with Objects by Primary Group (WRKOBJPGP), and Work with Objects by Private Authorities (WRKOBJPVT) now have an object type parameter so you can narrow the scope of objects you're working with.

Transport Layer Security (TLS) versions 1.1 (TLSv1.1) and 1.2 (TLSv1.2) are now available.

Online Certificate Status Protocol (OCSP) is now supported. OCSP provides a method for determining when a digital certificate has been revoked. For example, when a Certificate Authority (CA) is compromised, both the CA's certificate and certificates issued by that CA may be added to a revocation list.

Digital Certificate Manager (DCM) has been enhanced to provide configuration options for SSL for existing applications as well as the ability to assign multiple certificates to the same server.

In addition to bringing the SSL algorithms up-to-date, encryption operations using the AES and SHA-2 algorithms will see a performance boost on POWER8 hardware. These gains will manifest themselves in applications using the crypto services APIs, software tape encryption, and system-provided SSL and VPN connections. Note that this is a crypto accelerator and is not a replacement for the hardware encryption card, which provides encryption key storage.

The Best for Last

While some of the enhancements I've discussed here are genuinely welcome, I have definitely saved the best and most exciting enhancements for next month's column. Until then, I'll let you gain an understanding of these enhancements. Read about these and other changes in the Memo to Users and start your plans for upgrading to V7R2.