Archive for April, 2010

IBM Enhances Security Functions in IBM i

Posted in Security on April 29th, 2010 by Christopher – Be the first to comment

By Robin Tatam, Director of Security Technologies, PowerTech Group

IBM recently began General Availability (GA) shipping of V7R1 of the IBM i operating system. Although IBM introduced numerous security enhancements in V5R4 and V6R1, they gave most of their attention to other areas of the operating system in the latest release.

We brought in Jeff Uehling of IBM Rochester (home of the “AS/400″) to speak to our advisory board and internal staff, and he provided some new details about V7R1. Jeff is the technology architect responsible for System i security at IBM. He has more than 20 years experience developing security function, initially for the IBM S/38 and AS/400 servers, and now for IBM i .

If you are contemplating an upgrade to either V6R1 or V7R1, this article reviews some of the security enhancements introduced in these releases.

A recap of V6R1 security enhancements

New System Values

QPWDRULES  (Password Rules)
Trying to establish complex password rules can be frustrating. Rather than introducing more and more system values pertaining to passwords, IBM created a single repository that allows all of the rules to be centrally defined. Additional rules may be added in the future creating new system values.

Note: This system value is mutually exclusive to the legacy QPWDxxxx password rule system values. If the new QPWDRULES system value is set to anything other than *NONE, the old QPWDxxxx rules are ignored.

The configurable rules include:

  • Require special character
  • Require mixed case
  • Prevent all numeric password
  • Require x number of digits
  • Require x number of letters
  • Require x number of special characters

QPWDEXPWRN (Password Expiration Warning)
Originally IBM hardwired this as a 7-day warning, but in V6R1, IBM allowed security administrators to define how many days to warn users of a pending password change requirement. The default is set to 7 days for backwards compatibility, but allowable values range from 1 to 99 days.

QPWDBLKCHG (Block Password Changes)
Although the operating system provides a restriction that a password cannot be reused immediately, some users realized they could repeatedly change their password to circle back to their favorite one. Use the block password change system value to establish a time restriction between 1 and 99 hours. This restriction is not applicable to the “set password to expired” option or to a manual password override by a security administrator.

Changed System Value

QLMTDEVSSN (Limit Device Sessions)
Prior to V6R1, the Limit Device Sessions (QLMTDEVSSN) system value provided limited functionality. The system administrator could limit a user to a single 5250 session or allow them to have unlimited sessions. With V6R1, this value allows the administrator to specify the actual number of sessions between 1 and 9.

New/Changed User Profile Parameters

LMDEVSSN (Limit Device Sessions)
As with the QLMTDEVSSN system value, this user profile setting allows the administrator to more accurately restrict the number of concurrent 5250 sessions that users can run. This value overrides the QLMTDEVSSN system value.

PWDBLKCHG (Block Password Changes)
This profile setting overrides the QPWDBLKCHG system value and allows the administrator to set the number of hours that a user must wait between password changes.

Password Rule Checking

If users changes their passwords by using either the Change Password (CHGPWD) command or the QSYCHGPW API, the operating system enforces the password syntax rules. This includes when a password expires, or is manually set to expire by a security administrator.

If a security administrator assigns or changes a password via the Create or Change User Profile (CRT/CHGUSRPRF) commands, the operating system does not enforce password syntax rules. However in V6R1, the operating system indicates if the password did not satisfy the password rules by creating a “CP” entry in the security audit journal (provided you are auditing *SECURITY events for the system, or for that particular administrator).

Intrusion Detection

Originally introduced in V5R4, IBM added a number of enhancements to the Intrusion Detection System in V6R1:

  • Real-time notification capabilities to ensure timely visibility of events. Integrated e-mails plus message support for integration with popular ISV messaging tools, such as Robot/ALERT from Help/Systems or Messenger Plus from Bytware.
  • Detection of additional event types, including well-known attack types such as “smurf,” “fraggle,” ACK storms, address poisoning, and “ping-of-death.”
  • Support for extrusion event detection, where your own server is being used to attack, scan, or create traffic anomalies.
  • Removed dependency on the Quality of Service (QoS) server.
  • Now supports IPv6.
  • A GUI in iNAV to perform IDS policy configuration (V5R4 required manual editing of the configuration file) and display intrusion events (in addition to the “IM” events written to the security audit journal.)

Encryption Support

Encryption became a popular option in V5R3 with the introduction of a set of IBM APIs to encrypt data. It was enhanced in V5R4 with additional APIs to address key management.

In V6R1, IBM added a GUI in iNAV to make the creation and management of the master and data encryption keys a simpler task. These keys are stored in the System Licensed Internal Code (LIC). The Keystore files are configurable via the GUI.

Support was added in V6R1 for encryption of Auxiliary Storage Pools (ASPs). Only new ASPs can be encrypted at this release and should not be used to protect data from unapproved access because all interfaces present a plain-text view of the data. This change is designed to help meet regulatory requirements and to protect the system from data loss due to the removal of disk units, or when data travels in a Storage Area Network (SAN), or cross-site mirroring environment.

Encrypted backups are supported. If you use BRMS, this is a chargeable option that can be added to the “Advanced” feature to support any tape drive. There are significant performance and size considerations for this software-based encryption, so some saves may not be feasible.  Help/Systems’ Robot/SAVE also supports software encryption.

For more information on encryption support for database objects, review the Redbook IBM System i Security: Protecting i5/OS Data with Encryption (SG24-7399-00).

Miscellaneous Enhancements

  • Private authorities can be saved and restored with the objects. (Traditionally private authorities are only saved and restored with user profiles.)
  • You can now display System Service Tools (SST) user profile information using the DSPSSTUSR command. The information displayed includes the functional privileges associated with each profile.

Introducing V7R1 security enhancements

New User Profile Parameters

USREXPDATE (User Expiration Date)
The user profile definition now supports a date when the profile will automatically become disabled.

USREXPITV (User Expiration Interval)
If you prefer, the profile can be disabled after a specified number of days. The allowable range is from 1 to 365 days.

In the past, you could access some of this functionality in several commands that were part of GO SECTOOLS, but they were never really integrated into the operating system. The old commands have been updated to make them compatible with the new parameters as part of the operating system.

Encryption Support

Recognizing a growing need for encryption technology support, IBM continued to give it attention in V7R1. The enhancements include:

  • ASP encryption can now be turned on—and off—for existing ASPs, even while the system is active. You can also change ASP encryption keys, which supports the periodic rotation of keys often required for regulatory compliance.
  • Total disk encryption support has been added for DS5000 and DS8000 storage devices.

DB2 Field Procedures

One of the biggest security-related announcements in V7R1 is the introduction of a field-level exit point, called a “field procedure.” When a field or column is read, added, or updated, the field procedure comes into play. It is similar to a trigger, but unlike most exit programs registered via the system registry (WRKREGINF), the registration of the field procedure is performed in an SQL ALTER TABLE instruction.

User-written field procedures can perform many functions, including encryption and decryption operations. One of the biggest benefits is that the field attributes of a file don’t need to be changed—both length and data type changes are handled internally by the database. In the past, to encrypt data you needed to create a longer, alphanumeric field containing the data. Since this couldn’t be handled easily by existing database structures, programmers sometimes created a “shadow file” that linked to the original file but housed the encrypted information. Field procedures negate the need for this workaround and simplify application modifications.

Another advantage is selective decryption operations. For example, if a user requests a file that contains credit card information and the system determines that the user is not be authorized to view credit card information, the program can return the data to the application in a masked format.

Miscellaneous Enhancements

  • The TELNET client function within IBM i now supports SSL connections.
  • The accept, connect, and listen Socket APIs now support exit programs, which enable additional network security capabilities.

For additional reading on security in V6R1 and V7R1, please refer to IBM’s online information center at