Security Assessment of the IBM i (AS 400) System

A few months back, I was asked to perform a security assessment of the core banking setup for a bank. The core banking application was hosted on the IBM AS/400 mainframe system As part of my research on the subject, I gathered material related to IBM AS400 (also known as IBM i) and realized that:

1. While, there was a lot of material available online, but fragmentation was high & getting the required results were quite tedious.
2. IBM has its own set of Redbooks; however, they are written from an admin perspective. Albeit, there are some dedicated books for hacking IBM i, these were not adequate from a security audit point of view.
3. It is not that easy to get access to super expensive machines like IBM i for practice.

This article is a series of blog posts covering the key security aspects of IBM i mainframes and how a security audit may be conducted. I will also share an updated security checklist with you.

Introduction to the IBM i and Power Systems

The IBM i is a modern, proprietary operating system that evolved from the line of IBM’s older, business-oriented operating systems such as i5/OS, OS/400, etc. It resides on IBM Power Systems. People interchangeably refer to this platform as Application System 400 (AS/400), IBM i, iSeries, System i, etc. For the sake of convenience, I’ll call this platform as IBM i.

Unlike IBM Z mainframe systems, Power System machines are:

1. Standalone
2. Used by mid-range organization
3. Relatively newer than Mainframes

Their internal architecture and business use cases are also different from “Big Iron” mainframes. Collectively, IBM Power Systems are called Mid-range servers.

Refer to this for more details.

Features

IBM i is popular among industries like banking, manufacturing, etc. for its

• Stability (Fewer application crashes, can run for multiple years without S/W or H/W problems)
• High Performance (Handles millions of transactions parallelly)
• Low latency (low response time)
• Security (Multiple in-built security mechanisms. Which we will be exploring in this blog)
• Cost-effectiveness (Relatively cheaper than Mainframe)
• RISC Architecture (Less complex machine instructions, which means faster computing)

Refer here to some case studies.

IBM i Architecture in brief

We are not going to deep dive into the architecture of IBM i, as it will be way beyond the scope of this article. Instead, we will try to look at high-level components. Unfortunately, I was unable to find an architecture diagram for the latest IBM i (v7r4) but found this old diagram on the techtarget.com page, which gives us a fair idea.

As we can see, IBM i has the following components:

1. Integrated DB2 implementation (which can be used by applications)
2. Various service programs (used by applications, admin, etc.)
3. Stored Procedures for communicating with DB2
4. WebServices (These APIs are for web applications)

In addition to this, the latest version of IBM i has modules such as the IBM WebSphere, etc. (Full list of applications: https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_74/rzahc/rzahcswslpsze.htm)

The “Green Screen” mentioned in the above diagram is the user interface used by the system administrator and other system users. It looks like this:

Now before starting with actual assessment, we must understand a couple of things like,

• Important concepts of the IBM i System
• Where to get access to an IBM i System
• Internal Security Mechanisms

Important concepts of the IBM i

• Initial Program Load (IPL): Basically, it is a startup sequence for IBM i (and Mainframes as well). Sometimes, when configuration changes (such as hardware or software upgrade) are introduced to the system, it needs to shut down and boot up for the changes to be implemented. This process is called the Initial Program Load or simply IPL. Quite rarely, there might be a chance that due to some malfunction (such as power failure, hardware failure, OS crash, etc.) IPL-ing needs to be done.

IPLs need to be managed and scheduled carefully, as it affects the system’s availability.

• Logical Partition (LPAR): Generally, mid-range servers (and mainframes too) can have several sets of resources such as multiple processors, NIC cards, Storage, etc. We can logically group them and create a new system. For example, the Power System has 1TB memory, 32 TB Storage, 16 Processors, 16 NICs, etc. We can create a logical system of 256GB Memory, 2TB storage, 4 Processors and 4 NICs, and so on. Such grouping is called LPAR.

LPARs are fully independent systems. One physical system can have multiple LPARs in it as per requirements.

• DB2 for i: DB2 for i is a tightly integrated RDBMS solution inside IBM i. Many iSeries applications use this database by default. Although the basic functionality remains the same, DB2 for i is different than DB2 for LUW (Linux, Unix and Windows) versions, from a management perspective. So, there is a chance that some commands for DB2 for LUW editions won’t work on the DB2 for I database.

• Messages: Method of communication among users, jobs, operating systems, or applications.

• Objects: Everything on the IBM i is an object. Data files, programs, libraries queues, user profiles, and device descriptions, etc. are different types of objects. Each object has its unique properties. By considering everything as an object, it is easier to manage system functions by providing them an interface for user actions. Rather in IBM i, finding a correct object and performing operations on it is called System Operations.

One of the most important types of Objects is the Library. Libraries are containers or organizational structures for other objects on the system. Libraries may contain many objects and can be associated with different users/groups/applications. QSYS is the only library in the system which contains other libraries.

• Access Authority: Depending on the security level and other security settings, the user might be given several levels of access to objects on the system.

Table 1: Level of accessing authority

This access authority can be defined at a more granular level. We will be discussing these authorities in the audit part.

• User Profiles: A user profile contains most of the authorizations and preferences for individuals or groups. This information helps the OS to allow users to sign on to a system to access their customized sessions including their messages and output queue and to access functions and objects to which they have been granted authority.  

The user profile includes:

• System user profile name
• User’s privileges and limitations
• List of objects the user own or is authorized to use
• A reference to the message queue
• A reference to the output queue
• Information about which groups the user is member of
• Information about user’s last sign-on
• Job attributes, such as description and priority, the initial program to call, and the initial library list.
• National language setting
• Other attributes, such as user ID (UID), group ID (GID) and home directory

• Authorization List: Authorization lists consist of users or groups, the type of authority (use, change and exclude) for each user or group, and list of objects to which this list provides access. Authorization list is an easier way to provide bulk authorization to multiple users, rather than individually assigning authorization.

• Security Levels: These are pre-determined security levels. These levels affect how the user will get access to system objects. These levels are as follow:

• Level 20 (Password Security Level): This is the lowest security level. At this level, users must have a username and password for authentication. The system administrator creates these credentials.
  At this level, all users on the system have total authority on the system and its objects. This level is suitable for small organizations with “Security as a low priority.” It’s a big no-no for large organizations.
• Security policies of business limit level 30 (Resource Security Level): This level is like Level 20, except for user access. It’s suitable for small organizations only.
• Level 40 (System Integrity Security Level): At this level, the system itself is protected against users. User-written programs cannot directly access internal control blocks through pointer manipulation. It is a default level for every new installation.
• Level 50 (Enhanced System Integrity Security Level): This is the highest level of security in IBM i. In this level, not only user-written programs are restricted, users themselves can access only necessary data. The information on the rest of the environment is hidden. So, reconciliation becomes difficult at this level.

• Files and File systems: IBM i has an Integrated File System (IFS). The File is another type of object. Each file has a description that describes characteristics and how data associated with a file is organized. OS uses this description for processing the file. To access the file system, we need to use System i Navigator.

• Spooled files: Spooling is a system function that saves data in a database file later processing or printing. With spooled file data files on the attached devices, such as a diskette or printer, can be managed.

• Jobs: A job is a unit of work done by an OS. Complicated activities are divided into multiple jobs. A job typically includes all the information that the system requires for completing a specific task. It might be data files, programs and instructions for processing & tracking jobs throughout the processing. Jobs can be as simple as printing a file to as complex as generating a report based on the information distributed across the system.

• Logs and Journals: A Log is a database file that contains a history of backup, archive, recovery and media management operations. It also contains information about jobs, system information and problems.

Table 2: Type of Logs in IBM i

Journal is a system object that contains information about changes made in other system objects. Journals are useful while recovering database files, data areas, data queues, and IFS objects. It is recommended to enable journaling in IBM i.

1. Service Tools: System tools are used for various activities such as diagnosing system problems, managing disk units, and managing system security. These service tools are accessible via dedicated service tools (DST) or System service tools (SST).

Please note that all the above concepts will be very important while performing a security audit.

Where to get access to an IBM i System?

Pub400.com: As I mentioned earlier, IBM i is a very costly system and has very limited availability online. If you want to get free access, pub400.com is a website that provides a limited access user account for free.

Now, when I say a limited account, that is the Programmer privilege account, which is the lowest privilege account. For security audits, the Programmer account is not useful. For that, we need a user with a Security Admin privilege.

(Note: We will discuss user-privileges in detail)

IBM CECC: Another way to get free access to IBM i is with IBM Client Experience Customers Cloud (IBM CECC). This program is for IBM’s partners and customers. In this IBM provides an ID key to customers, which will provide access to proprietary IBM infrastructure to users for free.

IBM CECC login. On this portal, you can choose the target machine with the required configuration and checkout. Within 48 hours, you’ll receive the details of the allotted environment.

To get the “Green Screen” UI, the IBM i Access application needs to be downloaded and installed. Reference. We will be using this during the assessment.

Internal Security Mechanisms

IBM i, being very popular among critical businesses, has many in-built security mechanisms. We have already seen some mechanisms such as Security Levels, Access Authority List, Access List, Logging, etc. Let’s look at some more:

1. Password Policies: IBM i has multiple password validation policies in it. Based on the requirement, the system admin can set those. They are listed as below:

As we can see, using these configurations, we can configure fairly complex password policies for users.

• Lockable security system values: Security Admin can prevent other users (including users with *SECADM & *ALLOBJ authority) from changing of system values by CHGSYSVAL command. Sec Admin can also prevent users from adding a digital certificate to digital certificate stores with the help of an ‘Add Verifier API’ and restrict password resetting on digital certificate stores. Similar restrictions can be applied to SST and DST security attributes.

• Object signing and signature verification: A digital certificate’s private key to sign an object, and certificate to verify the digital signature. The digital signature provides proof of both the authenticity and integrity of time and data.

• Intrusion Detection Mechanism (IDS): IBM i has an in-built intrusion detection and prevention mechanism. IDS mechanism monitors TCP/IP network for spoofed packets; high volume traffics etc. Intrusion monitor record to the audit journal, and optionally send notifications to message queues and e-mail.

• Secure Perspective: IBM Secure Perspective for i5/OS (5733-PS1) is the licensed program that helps to create and implement policies that can handle large amounts of data, prove security compliance in audit, and close the gap of design and implementation.

• IP Filtering & Network Address Translation (NAT): IP Filtering provides control over incoming and outgoing network connections. NAT allows hiding Private IP behind a set of registered IP addresses. We can consider it a primary firewall mechanism.

With all this information, we are almost ready to start the assessment. In the next blog, we shall cover some important tools for assessment and security aspects to be considered during an IBM i assessment. We will also create a checklist and demonstrate how best to carry out a manual assessment.

References:

• IBM i v7r4 documentation
• Public AS400 Server
• IBM CECC Portal