Today's end users have more ways to access IBM i data than ever before, but that access has risks. Read on to learn how network interfaces make it easy for users to bypass standard security controls and access sensitive data without any accountability.
Cybersecurity used to be quite simple. In the early days of IBM i (then known as AS/400), dumb terminals ruled the computing kingdom, and subfile displays were considered to be on the cutting edge of programming design. We relied on application menus to insulate the user from the backend database—heck, most people didn’t even recognize that there was a backend database.
Security-conscious administrators could setup a profile to limit a user’s capabilities, permitting the execution of only a few basic commands—provided the user could even get to a command line in the first place.
Then things started to get complicated: dumb terminals fought for respect in a new era of political correctness, and were renamed to “non-programmable workstations,” although their capabilities remained just as limited. Those limitations ultimately led to their demise, as we flocked unanimously to programmable workstations, more commonly known as the Personal Computer (PC).
Business software developed rapidly, and new spreadsheet applications growled for data to be fed to them. With our core line-of-business applications still running on the AS/400, simple file transfers quickly became commonplace. No one thought too much about the security ramifications of this type of activity, but it was like opening Pandora’s Box!
IBM Brings FTP Access to IBM i
A few years later, IBM responded to market demands for open access to the database by building TCP connectivity into the AS/400, now re-branded as the iSeries. In addition to the traditional 5250-based green screen applications, the server could now be accessed by numerous powerful interfaces. The most popular of these interfaces included File Transfer Protocol (FTP), Open Database Connectivity (ODBC), and Distributed Data Management (DDM).
As an integral part of the operating system, resource security is recommended for the core layer of object protection. Unfortunately it is a one-size-fits-all mechanism, and the operating system does not distinguish between the different interfaces that the user might leverage to access the data. If you do implement the best practice recommendation of "deny by default" for green-screen access, you are not able to use legitimate PC tools to gain access to the backend data.
Arguably worse, a user granted change-level access to data for a green screen application will have that same level of access using powerful SQL-based applications, FTP, DDM, etc.—something that could be devastatingly inappropriate.
Fast forward through the years, and through a couple of additional server name changes, to the current day…
A commonality of the numerous services that facilitate data access is that they all connect to the database directly. In other words, the menus that historically restricted and controlled green screen users are not effective for users leveraging these interfaces. The underlying fabric of our defense is gone, and we are completely reliant on resource security to protect the data.
While resource security, also known as object security, is rock-solid and applicable to every interface that the server supports, the annual State of IBM i Security Study has reported year after year that resource security is rarely fully implemented, and is easily circumvented by overly powerful user profiles. Perhaps it comes as no surprise that most industry studies of lost, stolen, or corrupt data point to internal corporate users as the most common culprit.
IBM i End Users Might Be Savvier Than You Expect
If you don’t believe a user would know how to exploit these authorities, you may wish to reconsider. An FTP program can provide full graphical access to any authorized or unsecured library, or IFS directory. FTP programs are common, cheap (or free!), and easy to use. If your users don't already know how to, internet search results have all the answers they need.
If that were not enough to raise an auditor’s eyebrows, several of these network interfaces also permit host commands to be submitted and executed. While resource security is still in effect for the command itself, as well as any object that the command touches, it is important to understand that a profile’s “limited capabilities” setting commonly used to restrict command line functionality is not guaranteed to be honored outside of the green screen. In fact, on different releases of the operating system, the FTP server has toggled between observing the setting, and subsequently ignoring it.
Finally, network requests are not logged or audited by the operating system, regardless of any auditing controls that you establish. While more customers are now auditing user and system events via the QAUDxxx system values, network activities do not come under the watchful eye of these values. The best you can hope for is to know when a file is opened, but not what type of request was made of its data.
Implementing a Security Plan
So, now that we are aware of the danger of access via network interfaces, can we still leverage them for legitimate business reasons? And if so, how do we control them? Well the good news is that the answer is a resounding "yes!" Several methods are available to help with the security—each with its own pros and cons. Fortunately, you can implement a security plan that layers a combination of them to meet your needs.
- Some services can be prevented from starting up, a task performed from the GO TCPADM command menu, or via Navigator for i. Of course, making sure that someone doesn’t start them up again, or forget to shut them back down after temporarily using them, can be an issue. And while started, the server requests are still not visible for reporting or alerting, and you are completely reliant on that underlying resource security model.
- IBM i’s functional usage commands, along with the application administration facility within Navigator for i, permit select functions to be controlled by individual user. This methodology has the useful ability to override some settings normally restricted by operating system security, but still provides no visibility, alerting, or reporting of activities. Not all services are covered by the function entries, and it is another interface to leverage and maintain user by user.
- The operating system comes with a registration facility to define exit programs for the vast majority of network interfaces. To access the registry, use the Work With Registration Information (WRKREGINF) command, and define the name and location of the desired exit program for each service. Similar to database trigger programs, an exit program will be invoked by the associated exit point when a request is received by the server. The exit program is passed details about the incoming request, and can then perform any programmatic task: commonly to assess the legitimacy of the request, or to log the activity.
It is important to understand that exit programs are not synonymous with security. The function performed by an exit program is solely defined by the programmer who creates it. While some exit points allow an exit program the optional ability to "approve/deny" a request before it is performed, others are there simply to facilitate a programmed function to be performed during a system task. For example, the "create user profile" exit point could invoke a program to create a work library for the new user.
While writing your own exit programs is possible, many organizations are reluctant to own the ongoing research and development of a potentially complex and security-sensitive application. Other considerations when deciding whether to develop your own solution should include performance implications, dynamic rule functionality, as well as the separation of duties issues when programmers have access to a system that their own code is protecting.
If you decide to get your hands dirty, there are a number of online examples you can refer to for some very basic functionality. A quick search should turn up examples and documentation. Make sure you are extremely comfortable with the configuration of the exit point (some have multiple formats depending on other system configuration settings), and that you thoroughly test the functionality using sample transactions.
An Exit Program with Advanced Security Features
If like most organizations, you decide to not trust this functionality to your own exit programs, we recommend a professional exit point security solution called Powertech Exit Point Manager for IBM i.
The installation and activation of Exit Point Manager for IBM i instantly enables visibility of the network requests made to the server. This information is stored in a secure IBM repository for analysis and reporting. User and application requests that entail server access, including the use of remote commands, can also issue alerts to ensure immediate notification and reaction from the appropriate parties.
Imagine being able to report on a user accessing your integrated file system (IFS), including the directories they are navigating through and files they are viewing or deleting. How reassuring to know an administrator was alerted when an FTP user targeted a production file, rather than the test file they were supposed to be accessing. And all while blocking the unauthorized access attempt!
One of the advanced features of Exit Point Manager for IBM i is the ability to change a request to run under an alternate profile. This permits the recommended "deny by default" methodology to be implemented, while granting temporary access to pre-approved requests. For example, you can set authorities on a library to *EXCLUDE, but still allow an FTP download of a specific file to be permitted (and logged) by your accounting group.
Likewise, take a normally unrestricted user profile with *ALLOBJ special authority, and downgrade them to have read-only capabilities over production data! Both are on-the-fly security changes that are transparent to the user themselves, and are only in effect for the desired requests. And of course, the request is still logged under the signed-on user.
See if Your Users Have Untraceable Access
To find out if users have access to sensitive data through interfaces like FTP and ODBC, request a free Security Scan. You'll get a quick evaluation of IBM i security and find out if your system is protected by exit programs.
