Blog > Data Security > Using Exit Points to Fortify Your IBM i Security

Using Exit Points to Fortify Your IBM i Security

Authors Photo Bill Rice | December 4, 2019

In the early days of the AS/400 and iSeries, the job of protecting the system was often as simple as managing user authorities and securing user access through menus. This is certainly no longer the case with today’s IBM i environments. Fully open to communicate with other systems across internal and external networks, and accessible by partners and customers, the job of securing the IBM i can be challenging to say the least—particularly in light of rapidly changing threats and new compliance regulations. One powerful way to strengthen IBM i security is to utilize exit points to control user access.

Leveraging exit points for IBM i security

Exit points, provided by the IBM i OS, can invoke one or more user-written programs – called exit programs – during a wide variety of OS-related operations. These exit programs can be designed to allow or disallow access to various IBM i functions in very specific ways, due to their ability to take information that is passed to it from the OS and put it through granular, rules-based logic.

For example, a network protocol like FTP has its own exit point. That means an exit program that allows or denies specific users the ability to transfer a file can be created and “registered” to this exit point. Whether or not the transfer is allowed can be based on administrator-defined rules such as user profile settings, IP addresses, object permissions, time/date windows, and more. The exit program can also log all FTP activity for monitoring and auditing purposes.

The challenge of exit programs is that they can be time-consuming to create, a headache to manage, and could have an adverse effect on system performance if designed incorrectly. That’s why third-party solutions are available from various vendors, including Precisely, that significantly streamline the process. Using a third-party vendor ensures not only are exit programs created in ways that minimize performance impact, but these critical programs are kept up to date as new PTFs and updates to the OS come along. In addition, third-party solutions make it possible for IT departments to maintain a critical separation of duties, required by various compliance regulations, in order to show that the development of software used for controlling security functions wasn’t done by the same party who is responsible for managing the system and its data.

Read our white paper

Four Powerful Ways to Use Exit Points for Securing IBM i Access

There are many approaches and technologies you can use to keep your IBM i secure. Download this white paper to learn the security challenges of each level of access and how exit programs help remediate the threat.

4 ways they can help control access

There are four functional areas on the IBM i in which exit points can be utilized to control access:

  1. Networks – Protocols such as FTP, ODBC, JDBC, DDM, DRDA, NetServer, and others make it possible for users to connect directly to backend databases on the IBM i, which is a great convenience but can cause real problems if not properly controlled. Utilizing the exit point associated with each network protocol makes it possible to control network access in very specific ways.
  2. Communication Ports – There are some network protocols that don’t have their own exit points, including SSH, SFTP, SMTP, and others. In addition, companies may want to control communication access in a way network or other types of exit points cannot. For this reason, IBM provides socket exit points that make it possible to secure connections to your IBM i by specific ports and/or IP addresses.
  3. Databases – IBM provides an exit point called Open Database File that can be used to protect sensitive data from any kind of access, including through open-source protocols such as JSON, Node.js, Python, Ruby, and others that don’t have their own exit points. The added layer of security this exit point enables is significant because it can be invoked whenever a specified file on the system is opened, whether it’s a physical file, logical file, SQL table, or SQL view.
  4. Commands – When it comes to controlling the use of commands, user profiles and object-level security only go so far. Command-specific exit points supersede normal object-level security making it possible to create exit programs that limit the use of commands in very granular ways, even for users that possess powerful authorities such as *ALLOBJ or *SECADM.

As you can see, exit points can protect your IBM i system and its data in powerful ways. There is much more to learn about this important topic in the Precisely white paper: Four Powerful Ways to Use Exit Points to Secure IBM i Access