Home
 > Research and Reports > TEC Blog > The AS/400 Takes You Securely Where You Want to Go

The AS/400 Takes You Securely Where You Want to Go

Written By: Laura Taylor
Published On: June 20 2000

The The AS/400 Takes You Securely Where You Want to Go
L. Taylor - June 20, 2000

The following article appeared in Midrange Computing's Showcase Magazine, June 2000.

Note: For additional articles by Laura Taylor, click on the Security category in the Research Panels box on the TEC website home page.

Event Summary

An off-shoot of System/38, the AS/400 was originally going to be called the AS/40. However, purely for marketing purposes, IBM added an extra zero to the name to make it appear bigger, better, and smarter. In order to add substance and credibility to the additional zero, in a bold announcement, Steve Schwartz, the AS/400 division President, announced back in June of 1988 that the AS/400 could support 400 concurrent users. Analysts bought the story, and IT decision makers bought the box.

Withstanding the trials and tribulations of new technology and sophisticated application reengineering, the AS/400 deserves a medal for versatility and the ability to re-invent itself every few years in a an ever changing world of user requirements. One of the changes that the digital world and the AS/400 must cope with in the 21st century is the on-slaught of security intrusions. Not surprisingly, the media is hard-pressed for security incident reports involving AS/400s. Attacking and exploiting an AS/400 is much more difficult than attacking a UNIX or NT box.

Unlike many other computing platforms where security is built-in as an afterthought, security was built into the AS/400 from the get go, as part of the original design. The security smart IBM server uses industry standard network protocols, and can be protected by your corporate perimeter firewall, and guarded by your intrusion detection system, in the same manner as other networked multi-user systems. However, network security should never replace host security, and therefore how to implement sound host security on your AS/400 is something worth understanding.

You probably won't want to turn your AS/400 into a firewall, even though an add-on package exists for doing so. As well, you're not going to want to use IBM's SecureWay firewall since it was recently announced that the SecureWay's development will be discontinued. Though firewalls are not IBM's forte, mid-range host security is something that they took time to think about. Typically security incidents can be attributed to either problems in the system's architecture, programming bugs in the systems operating system, or configuration errors. In the IBM AS/400, you won't find any of the former two. It is far more complex to attack an AS/400 than to attack a UNIX, NT, or Netware server.

Built-in Encryption

To start with, the AS/400's crypto engine is built into the hardware. The 4758 PCI card, which is a common hardware solution across IBM server platforms, has built-in support for IBM's Common Cryptographic Architecture (CCA), and includes APIs that offer unique support for financial packages. Designed to meet the Federal Information Processing key protection Standards (FIPS 140-1), the 4758 is of particular interest for on-line banking and payment gateways that span International networks or networks that are part of Federal Agencies.

To complement the hardware encryption engine, there is a 40 bit, 56 bit, and a 128 bit encryption add-on software access provider product that can be installed in the AS/400 to enable the secure sockets layer (SSL) function. Due to export laws, the 128bit encryption add-on is available only in the U.S. and Canada.

AS/400 Server SSL Add-On Encryption Modules

Size of Crypto Access Provider Product Name
40 bits 5769-AC1
56 bits 5769-AC2
128 bits 5769-AC3

Client encryption products also exist so that AS/400 clients can security access encrypted information on AS/400 servers.

AS/400 Client SSL Add-On Encryption Modules

Size of Crypto Access Provider Product Name
40 bits 5769-CE1
56 bits 5769-CE1
128 bits 5769-CE3

IP-Masquerading through NAT

For added security, the AS/400 is able to perform IP-masquerading through Network Address Translation (NAT). NAT hides the real IP address of outbound packets, assigning them a single public IP address. This type of IP proxying secures the internal network by not broadcasting the real IP addresses making an AS/400 network less vulnerable to IP spoofing and being used a launch point for Denial of Service attacks.

The Security Wizard

The AS/400 Windows-like Security Wizard guides you through the security configuration process asking questions about the base AS/400 and making recommendations regarding configuration options. The Security Wizard can also generate separate administrator and user reports containing the security configuration status of password management rules, job time-out intervals, remote service attributes, object ownership changes, user profile changes, authority changes, and a whole lot more.

HTTP and Internet Connection Server

The AS/400 comes with an HTTP Server, which was previously branded as the Internet Connection Server. Add on IBM Websphere for a Java based Web application server, which comes pre-bundled with Java Security Extensions.

SET Internet Security Manager

The AS/400 comes bundled with the Secure Electronic Transaction (SET) protocol. SET is a protocol developed by Visa and Mastercard for payment systems, and has its own unique connection handshake. SET is a third party payment system which allows retailer to accept orders and send charges to the bank where card is registered. To use SET, the retailer does not have to handle the credit card. Due to the administrative overhead associated with it, SET has not caught on as well in the United States and Canada as it has among eCommerce vendors in Europe, however, that is likely to change as security engineers educate eCommerce vendors about the inherent weakness in Secure Sockets Layer (SSL). SSL only encrypts transactions in transit. Once a transaction has reached an Internet merchant, a user is placing an undue amount of trust into how well the merchant is securing their credit card data on their own internal infrastructure. Since SSL has no way of assuring that the merchant is authorized to accept credit card payments, there is no implied security verifiable with the merchant. A SET merchant needs to register with a financial institution and setup communications with a bank which does require additional overhead.

SET, like SSL, can slow down transactions, however, with multiple crypto accelerators on the market that can speed up transactions, what will separate true eCommerce vendors from eCommerce wannabes is whether they are using SET or SSL. Any service provider serious about security, e.g. online financial institutions, ought to be using SET not SSL. The fact that the AS/400 comes bundled with SET shows IBM's commitment and leadership when it comes to eCommerce security.

The IBM Payment Server supports SET, and with this additional software package installed on the AS/400, if configured correctly, there is the potential to have a truly secure eCommerce server that transfers money from a users digital eWallete through SET to a Payment Server, and then to your bank.

Security Levels

There are four systems parameters for configuring security that need to be set on the AS/400. These parameters are:

  • QSECURITY

  • QAUDJRL

  • QMAXSIGN

  • QRETSVRSEC

QSECURITY
QSECURITY is the security enforcer. The value of QSECURITY can be set to 10, 20, 30, 40, or 50. System/38, and the original AS/400 had only three levels of system security. A fourth level was added in V1, release 3, and a fifth level was added in V2, release 3.

A minimum security level of 40 is highly recommended.

Note that Machine Interface (MI) instructions are not available to programs authored by users regardless of the security level the system is running. As well, it is not possible for third-party programs to bypass object auditing.


QAUDJRL
QUADJRL turns on the security audit journal. The security audit journal can also run at various levels. The events that are logged by the security audit journal are determined by a combination of the level of QAUDJRL and QSECURITY. The events that can potentially be recorded include authorization failures, deleted objects, and identification of programs using restricted instructions. These logs should be reviewed on a regular schedule by a security engineer.


QMAXSIGN
The QMAXSIGN parameter is for specifying the number of sign-on attempts allowable for a particular user from a particular device. If the number of unsuccessful attempts to sign-on to the AS/400 exceeds this number, the device from which the user attempted access is disconnected.


QRETSVRSEC
The QRETSVRSEC parameter determines whether or not security authentication data needed by the AS/400 can be retained, or stored, on the client host system. If it is setup so that the authentication data cannot be retained on the client system, the AS/400 will prompt the user for an ID and password. A similar parameter exists for TCP/IP, IPX/SPX, and Lotus Notes networks called FFQRETSVRSEC.

Access User Classes

Every user client of an AS/400 has a profile. A user profile contains security fields that specify values for class, ownership, authority, scheduling priorities, device sessions, and privileged instructions. The values for a User Class can be any of the following:

  • Security Officer

  • Security Administrator

  • System Programmer

  • System Operator

  • Workstation User

The Security Officer is equivalent to root access in UNIX, or administrator access in NT. The Workstation User has the lowest level of security access. A user can be a member of more than one User Class.

Using the IOSYSCFG command, it is a good idea to restrict who has authority to configure TCP/IP using STRTCP (start TCP/IP) to the Security Officer and Security Administrator only.

Object Ownership and Authorization

Objects can be either owned, or authorized, by a user through the user profile. A user who creates an object is its owner by default. Authorization of objects is done through membership to a group. If a particular user is a member of a group, it is possible to specify in the profile that all objects created by the particular user also belong to that group. The owner of an object can grant other users private authority to an object, similar to how a UNIX owner can grant execute privileges, but not read or write privileges, to another user.

Each object can be characterized by eight potential authorities or permissions. The eight authorities are:

  • Operational authority

  • Management authority

  • Existence authority

  • List management Read authority

  • Add authority

  • Delete authority

  • Update authority

Attacks, Exploits, Viruses, and Vulnerabilities

Because security is object based, and is integrated throughout the hardware and operating system, instructions only work on objects that they are designed to work on. This makes it rather difficult to bypass security on an AS/400. If an AS/400 is subjected to a buffer overflow attack, an attack that often results in security breaches on UNIX and NT systems, it will simply close down the attacker's connection. As far as viruses go, because the AS/400 does not use PC instructions, it is extremely resistant to PC viruses.

The Ideal Webserver

The AS/400 was built with compiled C binaries with no interpreted scripts making it extremely resilient to CGI subversion, and ideal for webhosting. If configured correctly, from a security perspective you can't go wrong using AS/400s to build your eCommerce site. With the recent outbreaks of system security compromises, we expect the AS/400 to continue its strong showing in the world of Internet commerce.

 
comments powered by Disqus

Recent Searches
Others A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

©2014 Technology Evaluation Centers Inc. All rights reserved.