V5R4 Security: Rochester Rests Not on Its

Laurels, Part 1

We’ve all heard it time and again. You know, how i5/OS security (and OS/400 before that) is better than all of the other widely used platforms or, better yet, how some folks consider this particular IBM operating system to be “bulletproof.” Of course, no system is completely secure, but those of you who have been around this system for any length of time know that i5/OS can most certainly provide a very secure environment for hosting and conducting critical business operations.

According to Jeff Uehling, the chief technical engineering manager for System i5 security, and Paul Godtland, of IBM‘s Licensed Internal Code development team, the system integrity enhancements embedded within V5R4 add even more protection to security features that were started way back when V1R3 was released. (Yes, I said V1R3!)

“The system has always had good protection for objects, and in a well-controlled environment, users could always implement a strong security program,” Uehling says. “However, customers may not always be sophisticated enough to fully understand the value that the built-in integrity enhancements have provided over the years.”

To refresh your memory, the release of V1R3 was when program validation was introduced in order to determine whether a program object has been modified in unsupported ways, which might include the use of Machine Interface (MI) instructions that are restricted to operating system use or sequences of hardware instructions that are valid in other combinations, but not when modified within an altered program. In other words, the hardware instructions generated for a program help enforce MI semantics. Unsupported changes could attempt to avoid such MI integrity checking.

With V2R3, Level 50 security was added to OS/400’s QSECURITY system value, which enabled the system to meet C2 security requirements as defined by the U.S. Department of Defense. Over the years in subsequent OS releases, other integrity related system values were added, including: QALWOBJRST, which determines whether security-sensitive objects can be restored to the system; QFRCCNVRST, which determines if objects being restored should be converted (retranslated by your system’s trusted translator) prior to restore; and QVFYOBJRST, which controls the verification of digital signatures on objects.

Properly configured, the security features available before V5R4 perform admirably in maintaining the confidentiality and integrity of the i5 system (or AS/400 or iSeries, depending on the year), but users should not be lulled into a false sense of security through their interpretation of what they read and hear about i5 security. There was a time when security Level 30, where authority checking to objects is performed, was considered acceptable. The system would run the required authority checks, ensuring that *USE authority was present for the DSPDTAARA command or that *CHANGE authority was verified prior to executing the CHGDTAARA command, for example. The problem at Level 30 is that a user written program can gain access and write to a space with only *USE authority and potentially change that *DTAARA object. Similarly, Level 30 security allows access to objects regardless of their domain attribute (*SYSTEM or *USER), whereas Levels 40 and 50 enforce proper domain checking, thus enforcing the fact that a *USER state program can access only *USER domain objects. Because of these differences in access enforcement, best practice recommendations have pushed the accepted QSECURITY setting for i5/OS to Level 40 at a minimum.

New hardware-based storage protection capabilities in V5R4 are the true fulfillment of object integrity for System i5. With Hardware Storage Protection (HSP), the program state is compared against the object HSP attribute to determine if access is allowed. The object HSP attribute can enforce read-only access from user state or system state programs, no access for user state programs, or allow access from either state, for example. Thus, direct access by user programs to system objects is not allowed at Security levels 40 and 50.

The enhanced HSP in V5R4 reinforces MI encapsulation by generally allowing no access from either system or user state programs (a few areas of encapsulated objects are treated as read-only). Only Licensed Internal Code can access those objects, which is how those objects are normally accessed anyway in code produced by the trusted translator. Thus, programs that have been modified in unsupported ways are thwarted by the use of enhanced HSP. Godtland reiterates that the “enhanced hardware storage protection prevents access to objects in these unsupported ways” and that the enhanced HSP “applies at all security levels running on V5R4,” not just Level 40 or Level 50. Program alterations would include modifying the program to run in a system state, modifying the program instruction stream, or modifying the program validation value. A common method used to facilitate these types of program alterations is through the use of System Service Tools. This is yet another very important reason that helps to reiterate the criticality of consistent customer control of service tool profiles.

So why should you care about system state “user” programs in the first place? Why are they a threat? These altered programs can access system objects and change data, even at security Level 40 and 50, and they run with the same capability as other OS programs. The potential problems created by a system state “user” program are many, and they include deliberate system crashes, objects changed so that not even the OS can recognize them, the bypassing of authority checking and the writing of system audit journal entries, and various other attacks on the system’s integrity. As previously mentioned, the good news is that V5R4’s enhanced HSP applies at all security levels, so if a customer has not had the opportunity to move up to Level 40 or higher, or is restricted from doing so for some reason, they will still benefit from the integrity protection afforded by this release. As mentioned in a prior IBM public V5R4 announcement, “nothing changes for valid programs because LIC already accesses MI objects on their behalf. In contrast, now even altered programs are denied back-door access.” The team in Rochester is working hard so that “in some future release,” says Uehling, “i5/OS will prevent the distribution of system state programs that are not provided by IBM, thereby preventing programs from modifying i5/OS structures, period.”

Beyond the system integrity enhancements, there are many other key improvements in V5R4 that bolster the security posture of the i5. The feature that has likely garnered the most attention in the short tenure of this release from most platform veterans is the new TCP/IP stack based intrusion detection system (IDS). In our conversation at this spring’s COMMON user conference in Minneapolis, Uehling noted that “the support for this functionality has been lacking, but it has been considered for a number of years.” The System i5 security development team was finally able to bring those considerations to fruition with this release. The IDS support enables the monitoring of numerous intrusion events, including port scans, fragmented and malformed data packets, and DoS (Denial of Service) attacks.

I’m sure many of you are thinking to yourselves, “What good is an i5 IDS when we already have a firewall keeping the bad stuff out of our internal network anyway?” Don’t forget one important thing about your external-facing firewalls: they cannot detect intrusions on the inside! More and more in these highly interconnected times we live in, multiple IDS implementations (or firewalls) exist that work in conjunction with each other in order to form a more effective implementation of security policy for both external and internal-only IP traffic.

The management flow for this new IDS support starts with the definition of intrusions in a policy file via the green screen interface. Once the policy is defined, any traffic flow that contradicts the policy is detected by the TCP/IP stack, the IDS is notified and, here’s the good part, these intrusion events are now logged to the system security audit journal as new IM entry types. Enabling the IDS requires enabling Quality of Service (QoS) in the TCP attributes, ensuring that auditing is turned on (QAUDCTL), adding the new *ATNEVT value to the QAUDLVL system value, configuring and verifying your IDS policy file (/qibm/userdata/os400/qos/etc/idspolicy.conf), and starting the QoS server. For reporting of intrusion events, all that is required is that the IM audit records be extracted for analysis. IBM has stated that they won’t offer a GUI utility for this, but it is likely that a number of ISVs will jump on this and quickly bring client interfaces to market. Even so, a moderately skilled developer can create their own utility that monitors the audit journal for IM records, extracts those records, and parses them in order to display them in a readable format based on the fields selected.

The future of IDS may include a separation of IDS from the QoS server, an IBM-supplied GUI interface for the management of the IDS policy file, and the ability to detect other types of intrusions. Other enhancements could include the ability to send an email to the system administrator or a message to the QSYSOPR message queue, the addition and enabling of IDS-specific exit points that can be managed by the many exit program ISVs, as well as the addition of IP filtering for blocking unwanted interfaces, facilitated through Java programs.

There are a few other V5R4 security enhancements worth noting, and I will cover them in a future edition of this newsletter.

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.