Top 3 New Security Features in IBM i V7R4
IBM just announced the release of V7R4, and it includes some new integrated security features. Let's take a look at the top three.
Service Tool Commands
IBM has externalized some of the system configuration options found in System Service Tools (SST) as well as the service tool ID configuration options by making them CL commands. This is in direct response to requests from organizations running large numbers of IBM i partitions that need to perform remote management rather than having to sign in to each instance separately.
You can now Create, Change, and Delete a Service Tool ID using the appropriate command (CRT/CHG/DLTSSTUSR). Using the Display or Change SST Security Attributes (DSP/CHGSSTSECA) commands, you can display or modify the system configuration settings, such as the ability to lock system values, the password rules for the SST service tool ID, and more.
Before you ask whether this is opening up security for SST, never fear. You still have to have some special authority. The exact authority is documented in the Service tools command section in Appendix D of the V7R4 Security Reference manual. In addition, required parameters of the commands demand that you provide a valid service tool ID and password that has enough authority within service tools to perform the task.
TLS1.3
TLS1.3 was approved by the IETF last year, so it’s no surprise that this protocol was enabled in V7R4. In fact, it and TLS1.2 are the protocols that are enabled if you leave the QSSLPCL system value at the default value of *OPSYS. This means that when you upgrade and you’ve done nothing with this system value in a previous release, some of the protocols that may currently be in use on your system will be removed. For example, the protocols enabled when *OPSYS is specified in V7R2 are TLS1.0, TLS1.1, and TLS1.2. When upgrading from V7R2, TLS1.0 and TLS1.1 will be removed.
It’s been best practice on IBM i for several years to only enable TLS1.2, so that your encrypted sessions are running with the most secure encryption ciphers and to stop using the protocols with known vulnerabilities, but I know many organizations haven’t done that. Prior to upgrading to V7R4, I’d suggest that you make sure TLS1.0 and TLS1.1 and their corresponding encryption ciphers aren’t in use. To do that, you can enable counters within service tools to determine which protocols and ciphers are in use. IBM provides a thorough explanation of the process.
If you discover that the weaker protocols are in use, you can then run a trace to determine what process is using them. Instructions are available here.
If you find that a process is using TLS1.1 or TLS1.0, you can add the protocol back into the QSSLPCL system value, but I would encourage you not to do that. Both TLS1.0 and TLS1.1 have been deprecated, meaning that they’re not to be used. And rightly so … they’re OLD! TLS1.0 was approved in 1999 and TLS1.1 was approved in 2006. Lots of innovation and many vulnerabilities have come to light since these were acceptable technologies. If you have connections using TLS1.0 or TLS1.1, it’s time to move forward and use current technology.
Looking to implement the new security features in IBM V7R4? The HelpSystems Security Services team can help!