V5R4 Security: Rochester Rests Not on Its Laurels,

Part 2

A few weeks ago, I walked you through some of the major security enhancements that IBM has woven into the i5/OS V5R4 release for the System i5 servers. Back, by popular demand, is more insight into the new security enhancements, which Big Blue is hoping you will put into practice to make your i5/OS platforms even more secure than the legendary security of the OS/400 platform.

One key area of improvement found within V5R4 includes a new set of APIs to help in the management of encryption capabilities and the cryptographic keys themselves. With V5R4, the Cryptographic Access Provider (5722-AC3) requirement for SSL, VPN, DCM (Digital Certificate Manager), and the cryptographic services APIs has been withdrawn and the functions have been included in the base operating system. Similarly, the Client Encryption product (5722-CE3) is no longer available in V5R4 but is included in the base code of iSeries Access for Windows.

Also, the management of encryption keys is more important than ever for many i5 shops these days, since the myriad regulatory requirements specifically require the use of encryption for sensitive data. If you can’t protect the encryption keys, then you most certainly can’t properly protect the data that is encrypted with them. Fortunately, V5R4 helps to address typical key management problems, since up to eight master keys can be created and stored securely within the LIC, and yet they can still be accessed without manual intervention using system-supplied APIs. These master keys cannot be directly modified by the user (including QSECOFR) and they are encrypted using 256-bit AES (Advanced Encryption Standard–FIPS PUB 197).

At the system value level, there is a new parameter of QAUDLVL called *NOTAVL whose main purpose is to prevent the display of audit attributes by an end user. Why? As you may have heard over the years, 80 percent or more of all security breaches come from inside the organization by trusted users. Well, your typical “trusted” user is often smarter than the average bear and, as such, will likely take a few moments to poke around the system to “see what they can see” regarding audit and security settings BEFORE they decide what nefarious activities they will undertake. The bottom line for someone that is snooping around is that the OS code that supports the different interfaces checks to see if the user has *ALLOBJ or *AUDIT special authority, and if they don’t, the system won’t display the audit information on the interface.

This will mask the auditing values returned by some system APIs, in some output files, on some screens, and on some user interface panels. The new value *NOTAVL (not available), or some other appropriate replacement value, will be displayed instead, which effectively obscures sensitive system audit settings from those prying eyes. Common interfaces affected by this change include the WRKLNK command, the DSPOBJD and RTVOBJD commands, and the Retrieve Object Description (QUSROBJD) API, among others. Also, message CPF180F is sent to QHST instead of message CPF1806 when system values QAUDCTL, QAUDENDACN, QAUDFRCLVL, QAUDLVL, QAUDLVL2, and QCRTOBJAUD are changed. The new CPF180F message description does not include the previous and new values in the message variables, so that “sensitive” information is not exposed in the history log either. These changes were also provided in V5R3 via PTFs, so they might not appear if you haven’t applied those PTFs on your system.

Virtual Private Networking (VPN)

Network Address Translation (NAT) allows the hiding of unregistered private IP addresses behind the registered IP addresses. This helps protect the internal network from outside networks. The problem with VPN and NAT is that conventional NAT does not work on IPSec packets. When a packet goes through a NAT device, the source address in the packet changes. This address change invalidates the packet. Thus, the receiving end of the VPN connection drops the packet and the VPN connection negotiations fail.

The solution to the NAT problem with IPSec is UDP encapsulation (also known as NAT friendly IPSec or NAT traversal support). UDP stands for User Datagram Protocol. DNS (Domain Name Service) is an example of an application-layer protocol that used UDP. UDP encapsulation allows IPSec traffic to pass through a conventional NAT device. It wraps an IPSec packet inside a new, but duplicate, IP/UDP header. The address in the new IP header is translated through NAT and when the packet reaches its destination, the additional header is stripped off, leaving the original IPSec packet and passing all other validations. V5R4 offers complete NAT traversal support (UDP encapsulation), including the responder side, whereas V5R2 supported only UDP encapsulation when the iSeries was the initiator of a VPN connection.

To improve packet-level security, Traffic Flow Control (or Confidentiality in some abbreviations) allows you to conceal the actual length of data packets transferred over a VPN connection. This provides extra security against attackers who may discover the type of data being sent over a VPN just from the length of the data packet. The extra security is achieved by padding the packets being sent with dummy packets of different lengths and at random intervals in order to conceal the actual length.

Single Sign-On–Network Authentication Service Changes

According to Thomas Barlen of IBM Germany, “In V5R3, the Kerberos server was included as part of the 5722-AC3 product. In V5R4, the 5722-AC3 product is no longer available. The Kerberos server is now shipped in the Network Authentication Enablement (5722-NAE) product. If V5R4 is installed over V5R3, and the 5722-AC3 product is currently installed, then the 5722-NAE product is automatically installed to ensure that the Kerberos server that was part of the 5722-AC3 product is installed. If V5R4 is installed over V5R2, and the 5722-AC3 product is currently installed, then the 5722-NAE product is not automatically installed, since the Kerberos server was not part of 5722-AC3 in V5R2.” Got that?

Single Sign-On–Enterprise Identity Mapping (EIM)

Again, according to Barlen, “V5R4 introduces group registries to potentially lower administration efforts for managing EIM user associations. Logically grouping the registry definitions allows you to reduce the amount of work that you must perform to configure EIM mapping. You can manage a group registry definition similarly to the way that you manage an individual registry definition now. All members of the group registry definition typically contain at least one common user identity to which you want to create a target or source association. By grouping members together you are able to create only one association, rather than multiple associations, to the group registry definition and user identity.”

Some Other Command-Level Enhancements

The new Copy Audit Journal Entry command (CPYAUDJRNE) has been added, providing a very simple way to create output files with specified journal entry types only. The old way required you to first find the correct template output file, copy it to a library, and then copy the journal entries with the DSPJRN command to the new file. This involved a lot of manual work and, quite often, a lot of digging into the iSeries Security Reference. The CPYAUDJRNE command also allows you to specify an eight-character prefix for the output file name and a two-character suffix indicating the journal entry type is automatically added. This makes it much easier to analyze audit journal entries.

Last, but certainly not least, is the new Work with Object Private Authorities (WRKOBJPVT) command. How many times have wished you could list the authorities that an individual user profile actually has, instead of having to list object authorities and find the ones your target user was authorized to by digging through a huge report or output file? This new command does just that by allowing you to display directory-based and library-based private authorities for a specific user!

OK, I’m not supposed to be writing a book here, just a two-part article, and most of you don’t need me to provide the details of every single security enhancement anyway. I’m sure you’ll squeeze as much value as you can out of these new features once you get your hands on V5R4, which is precisely why the folks in Rochester can’t rest on their laurels. They know that we “system and security administrator-types” will dig deep and pound on the i5’s capabilities as hard as possible, all in the name of ensuring that the platform retains its solid reputation for strong security.

Steve Martinson is a senior consultant and manager of the iSeries Security Practice for Servique, LLC. Martinson’s primary focus is on enterprise implementations of NetIQ Security Solutions for iSeries (NSSi) for key NetIQ accounts, starting at the planning stage and helping customers move through assessment, design and implementation.

RELATED STORIES

Part 1

System i5 Security: What’s New, and What the Future Holds