SecureState Blog

Read SecureState's award winning blog.

In 1988, the IBM AS400 platform was introduced as a mid-range small business processing solution. The AS400 later became known as the iSeries. There are more than 30,000 applications for the I-SERIES, many of which are programmed in RPG III. It is used in a variety of networking configurations, including as a host or intermediate node to other I-SERIES systems, as a remote to mainframe networks, and as a network server to network workstations. The I-SERIES can support many networks, each with hundreds of clients.

There is continued use of this platform in both small and medium sized companies. Hackers continue to have an interest in medium size companies, as reported in this USA Today article – http://usat.ly/iuAeiM. To protect your network, security must also be applied to the I-SERIES platforms.  So we start with the basic controls, the first steps to securing your I-series platform. 

Understand and document all methods used to access the I-SERIES platform; users may have unauthorized access to the environment through an alternative access method.  Policies and procedures should be fully documented for adding users and granting access, handling of terminated user accounts, as well as changes to existing access.

Obtain a listing of all user profiles on the system by user and group profile. Verify that all user IDs are for valid current employees. There are many system account IDs which start with Q, (e.g., QLPAUTO, QLPINSTALL, QSPL, QRJE, QFNC, QGATE, QPGMR, QSRVBAS). These should all be set to NONE or the vendor supplied passwords should have been changed. Two additional system IDs which carry significant authorities are: QSECOFR and QSYSOPR and should have the passwords changed as well. Also determine which user profiles have been granted special authorities, which are QSECOFR, ALLOBJ, SECADM, SAVSYS, JOBCTL, SERVICE, SPLCTL, and AUDIT. Special authorities should only be granted to system or security administrators. If normal users require special authorities for job related functions, the need should be reviewed closely and approved by management.

It is also important to know which users have object authority to the sensitive system commands. Some examples of these commands would be: ADDAUTLE, CHGAUTLE, CHGDTA, CHGNETA, CHGOBJOWN, CHGSYSVAL. A complete listing of these commands can be found in your system documentation.

In conclusion, it is impossible to prove that a platform or program has no bugs; however, if you take the time to reasonably test and find the obvious vulnerabilities and remediate them, and challenge the access which your user community has been granted, you stand a better chance of not being compromised.