Controlling IBM i Access With Exit Points

March 29, 2021 Bill Hammond

Today, the job of managing security on IBM i can be complicated, requiring dynamic technologies and processes that can respond quickly to ever-evolving threats and new regulations. Ransomware and other malware can, and has, infected IBM i systems and effective access control is a major weapon in the battle to secure your IBM i. There are many different approaches and technologies you can use to keep your IBM i secure.

Using the exit points provided by the IBM i operating system can be a powerful tool to monitor and secure four important levels of access within the IBM i:

Networks
Communication Ports
Databases
Commands

What Are Exit Points?

IBM introduced exit points to the AS/400 in 1994 with OS/400 V3R1, which provided administrators and developers with “hooks” that could be used to invoke one or more user-written programs – called exit programs – during a wide variety of operations. An exit program can be created and “registered” to the exit point for a particular network-access protocol. For example, an exit point program could be written that not only monitors and keeps logs of all FTP activity, but also allows or denies specific users the ability to transfer a file based on many parameters, such as user profile settings, IP addresses, object permissions, time/date windows, etc.

Because a wide variety of information can be passed to the exit program and the exit program can often be designed with a very granular, rules-based logic, it is possible to allow or disallow a specific type of activity under very specific circumstances. This kind of control provides the ability to implement a powerful and effective approach to securing access. It’s important to keep in mind that exit programs are always invoked by the OS prior to the consideration of object-level security. This means that when exit programs are properly created, they can control the conditions of access for even powerful users.

Sounds good right? Well, the challenge of exit programs is that they can be laborious to create and difficult to manage. This is why third-party solutions exist and they can significantly streamline the process. Let’s look at the four levels of access that exit programs help to secure.

Securing Network Access

Network 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. This provides great convenience for users who want to use data in spreadsheets, business intelligence applications, and development environments. However, these protocols, if not properly controlled, open the systems to potential hackers or, more commonly, to internal users who may intentionally or unintentionally create problems.

IBM provides dozens of exit points that cover most network access protocols, which means that exit programs can be created and assigned to these exit points, not only to monitor and log activity but, most importantly, to control access by a variety of criteria. When access is controlled through network exit programs, only the specific operations defined by the exit program can occur.

Securing Communication Port Access

There are a handful of network protocols that don’t have their own exit points and thus can’t be protected in the same way as protocols that have specific exit points. These network protocols include SSH, SFTP, SMTP, and others. In addition, organizations may need to control communication access in a way network or other types of exit points cannot because it is not possible to specify a port number in these other types of exit points. For example, it may be important for a specific type of network connection to be able to use only one or more secured ports.

IBM provides socket exit points that make it possible to develop exit programs for securing connections to your IBM i by specific ports and/or IP addresses. This covers part of the gap caused by the lack of protocol-specific exit points for SSH, SFTP, SMTP, and others, but it is important to keep in mind there are some limitations in terms of how socket exit programs can function. For instance, the socket exit program that controls inbound communications is limited in that it can only be defined to allow or disallow communication on specific ports and/or IP addresses, while providing some other parameters such as day and time. By contrast, the socket exit program that controls outbound communication can be defined with rules that cover various user parameters in addition to ports and IP addresses. All of this aside, socket exit points can provide a necessary level of protection, especially when paired with the other types of exit point access-control methods available on IBM i.

Securing Database Access

Standard object-level security only goes so far in controlling access to sensitive data. There can be many different situations in which you need a more granular approach to whether access to data is allowed or denied. One area of vulnerability is the increasing use of open-source protocols that access data, such as JSON, Node.js, Python, Ruby and many other open-source protocols. Certainly, these provide innovative ways to integrate the IBM i to other IT processes and are being used with increasing frequency; however, these protocols don’t have their own exit points and therefore can’t be protected in the same way as network protocols. Without properly securing database access, problems could easily occur, whether it’s a user who accidently corrupts data or worse, an internal or external actor who commits fraud or steals sensitive data.

One particularly powerful exit point is called Open Database File, and it allows development of exit programs that protect sensitive data from any kind of access. The added layer of security this exit point provides is significant because of its ability to invoke an exit program whenever a specified file on the system is opened, whether it’s a physical file, logical file, SQL table, or SQL view. As with other exit points, your exit program can be defined to audit all activity, such as the user, the method of access, the date/time, and the operation (read, update, add, or delete). Plus, the exit program can contain a granular set of rules that control under what conditions the file can be accessed and by whom.

Securing Command Access

No matter if accidental or deliberate, the incorrect use of commands by users can cause considerable damage, whether it’s deleting files, restoring libraries, ending processes, or worse. Certainly, access to commands can be controlled to some extent through user profiles and object-level security, but organizations often need a more refined approach to allowing or disallowing commands, particularly for users with powerful profiles.

IBM provides exit points that cover the use of commands, thus making it possible to develop exit programs that allow or disallow access to any command within very specific circumstances, regardless of whether the access attempt comes from a user performing a command-line function directly within the IBM i, through network access, or otherwise. Because command exit programs supersede normal object-level security, they add an additional, very useful layer of security that can control the use of commands even for users with powerful authorities such as *ALLOBJ or *SECADM. As with other types of exit points, command exit programs can be defined in such a way that each command can have its own specific rules of usage, while providing logging of any activity.

Exit Programs: Do It Yourself Versus Third-Party Solutions

Now that you know how exit points and exit programs can control access in so many powerful ways, the next step is to start creating your own exit programs. However, it can be challenging for many IBM i shops to develop and manage their own exit programs. It is a time-consuming, complex, and error-prone process to create, properly test, and maintain exit programs. Additionally, when new PTFs or updates to the OS are needed, exit programs often need to be updated accordingly. Finally, system performance can suffer if exit programs aren’t designed correctly – this is particularly the case with high-volume ODBC/JDBC applications

Fortunately, third-party solutions exist and can make it easy for you to create, deploy, and manage exit programs even if you don’t have any knowledge of programming.

Precisely Can Help

Assure System Access Manager, a feature of Assure Security and part of its Assure Access Control feature bundle, is a access control platform with a flexible, powerful, data-centric approach to securing access to your IBM i. Using IBM i exit point technology, Assure System Access Manager gives you control of a wide range of system and data access points. Find out more at https://www.precisely.com/product/precisely-assure/assure-security

This content is sponsored by Precisely.

Bill Hammond is product marketing director at Precisely. Bill has over 25 years of product marketing and product management experience with enterprise software products. He has been responsible for the messaging, positioning and launching of products in a broad range of disciplines from business intelligence to eDiscovery to storage management. At Precisely, Bill covers the IBM infrastructure products which includes the Assure product family for IBM i and the Syncsort family of IBM mainframe solutions.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search