The Case For Implementing Exit Points

By Rich Loeber

Someone recently asked me if there was someplace on the Internet where they could see a case made for implementing exit points on their IBM i system. I was at a loss for a comprehensive source and this got me thinking that it might be a good idea to just create one here.

Security exit points on the IBM i (and its predecessor OS/400) have been in existence since the mid 1990's. When the system was opened up to network access, the need for additional security over and above the standard IBM i OS security was apparent. IBM's solution was to let their customers solve the issues on their own by giving them access to specific decision points in the various network server functions that were being rolled out. Server functions were being added to the IBM i OS to support network access to the system like FTP, ODBC, SQL, mapped drives in the IFS, file upload and download, remote command calls and a lot more. Since that time, even more network functions have been added along with related new exit points.

To be fair and above board, I must also disclose here that my company, Kisco Information Systems, jumped on the exit point bandwagon right away when the exit points were initially rolled out. Since 1996 we have been selling a comprehensive general use exit point solution called SafeNet/i, now in its 11th release.

The question I was asked was "Why does my shop need to implement exit point controls?". That is what I want to address here. I will do so by describing several cases where additional security is needed over and above the already excellent security features that are built into the IBM i OS.

Case #1:

The classic case for exit point implementation comes from the 5250 terminal application days. If you have a Payroll Application that runs on your IBM i and is maintained by one or more clerks, OS security has to give access to the payroll files for those clerks, but the application and terminal menu system can easily be used to restrict what operations they can do on the payroll master files. That access will probably grant then *USE access so they can update files and generate payroll checks and reports.

The above scenario is secure from an application perspective, but you would never want your payroll clerk to be able to download the payroll master files and take them home on a USB drive, would you? An exit point implementation can prevent this access. The exit point process runs on top of the IBM i OS and can be used to restrict server functions by user profile, source IP address and even by objects accessed. This leaves the IBM i OS security in tact for the 5250 terminal application and also prevents unauthorized access via the network connection.

Case #2:

Many IBM i shops have one or more "regular users" defined with *ALLOBJ access in their user profile. This can happen for lots of reasons and in many cases, it would take a very long time to correct. I never recommend granting *ALLOBJ access to regular users, but if your system has evolved with this issue, it cannot be fixed overnight. In many cases, the application itself is providing the security. The issue, however, is that these users literally have access to ALL OBJECTS on your system. With network access to your system, one of these users could easily download sensitive data from your system, including credit card information and customer identity information, and hide it on a USB drive and walk out the front door and nobody would be the wiser.

An exit point implementation can address this issue. Using exit points, you can restrict object access by user profile even though the user is set up with *ALLOBJ. In fact, object access can even be restricted for the QSECOFR security user profile. This can help to protect your system from abuse by a user profile that has been granted more access rights than they really need.

Case #3:

Since the TCP/IP communications utility FTP was added to the IBM i OS, a very easy to use network application lets users interact with the IBM i system without using a 5250 interface. The FTP user can browse objects on your system and upload or download them. A talented FTP user and even execute IBM i commands through FTP. For some shops, you want a user to have these capabilities, but you wouldn't want them granted on a broad basis.

Exit points can help with this too. First, you can easily restrict which user profiles are allowed to use FTP. Then, you can further restrict which FTP commands they are allowed to use letting them do a PUT, for example, but disallowing a GET. Then, you can even give the user contextual access rights by only allowing an FTP connection from a known and trusted IP address, such as an internal IP address. Then, if the user's credentials are compromised, the FTP connection will still have to be established from a trusted source.

To sum up:

These are just a few examples of why IBM i shops should consider exit point implementation for additional security on your IBM i system. There are literally dozens of additional scenarios that can be described, but these should get you started on making a case for exit points. It is my belief that every IBM i shop should have some form of exit point controls in place in order to be secure. If you are interested, I can heartily recommend Kisco's SafeNet/i software if you want to jump in and get started.

If you have questions about details of this tip, feel free to contact me directly by email: rich at kisco.com.