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.