How to grant varying levels of IBM i security to different interfaces

By Robin Tatam, Director of Security Technologies, PowerTech Group

Let’s start with a brief history lesson. Don’t worry, the lesson only goes back about 25 years or so, but carries elements that are still very much in effect today. Start by recalling the days when the “AS/400” was first gaining popularity in the midrange market. One of the most impressive features of the new platform was that applications could be migrated from the earlier S/3x servers (not that the term “server” was even in use back then). At the same time, programmers were busy developing new applications in RPG, CL, and COBOL. Both migrated and new applications often shared a common thread: no object-level security. To be fair to the development community, many of the servers were running at security level 20 which, by default, grants every user the special authority of “all object” access, and would circumvent object security anyway.

Most developers didn’t really concern themselves with security (I know I didn’t!). Instead, they used application menus and command line restrictions to ensure that data could not be accessed outside the boundaries of the application. There was no mainstream Internet, and system access was usually facilitated via twinax connections to dumb terminals, or to PCs with twinax emulator cards inside.

Things changed, however, in the early 90s. IBM enhanced the operating system (OS/400) to support a number of TCP interfaces, such as FTP and ODBC. Users could now run programs and access data outside the confines of a green-screen display. While these interfaces represented a huge step forward in data openness, they often exposed the lack of object-level security.

“What do you mean, there’s no audit log?”
Today, people are still surprised that these network interfaces provide such powerful and open access to their application data, as well as the ability to execute server commands—sometimes without requiring command line permissions. What is even more shocking to them is that most of the interfaces provide no logging or tracking of the requests. Many people initially blamed IBM for leaving a “back door” into a system that was marketed as completely secure. In IBM’s defense, the AS/400 did contain an object-based security mechanism, which wasn’t often used. They also introduced a new supplemental security layer called network exit points. Exit points allow a program, called an exit program, to be called when someone makes a network access attempt, such as an FTP-based file transfer request.

However, even exit programs are not automatically synonymous with security. Although typically used for that purpose, an exit program only does as much (or as little) as the programmer codes it to do. In fact, IBM doesn’t provide exit programs, but instead expects the programming staff to write them, or a trusted commercial security vendor, such as PowerTech, to supply them.

Now, does object-level authority negate the need for exit programs? Or, does the presence of an exit program make the need to implement object-level security obsolete? While you might encounter each of these arguments from object-level aficionados and some exit point software vendors, I personally feel that these mechanisms are far more complementary than exclusive. In fact, the best security infrastructures are built in layers. If a user breaks through one defense layer, they are faced with the next. If there is only one layer in place, penetrating it exposes the data immediately.

These layers might be clearer if we use the analogy of the security measures you might see at a bank: an armed guard at the door, the requirement for a signature and photo ID prior to cash withdrawal, closed-circuit video cameras recording activities, and additional safeguards for accessing the safety deposit box area. If all they had was the guard at the front door, successfully navigating past the guard would provide free access to everything inside the bank without fear of getting stopped or caught.

“You can have any color, as long as it’s black”
Let’s assume you have a good understanding of object-level security, and that your libraries and objects are appropriately secured from direct user access. First of all, congratulations! According to PowerTech’s annual State of IBM i Security Study, a well-designed (and implemented) object security scheme is rare. In fact, it showed that, in 2009, approximately 50% of Power Systems libraries are still giving *PUBLIC (anyone who has a user profile) access levels of *CHANGE. In addition, while the operating system security controls are still applicable to all modern interfaces, the biggest challenge stems from the fact that those controls were originally designed when there was just a single point of access to the objects. Despite the fact that there are now numerous entry points, we still can set only a single level of access that applies to all of them collectively. Providing a user with change access in a green-screen application opens up a tremendous amount of exposure through an ODBC or FTP connection. Likewise, excluding a user from one data interface means that the data might not be available for legitimate business purposes.

“Emergency Exit”
Although only 43% of the IBM i shops that we audited in 2009 had even a single exit program in place, this still doesn’t tell the entire story. The main challenge when relying entirely on an exit program is that it is only as good as the programmer who wrote it. Merely having an exit program does not necessarily add security, especially if that program doesn’t provide two important functions:

1. Flexible Access Control
   Access control refers to the ability to set rules to allow or reject requests made through the network interfaces. Flexible access control dictates that you can define rules that take effect without having to recompile programs, or restart TCP servers. It also means that you should be able to control user requests based on a variety of factors such as the type of request, the user (or group) profile making the request, and the location where the request originated.
2. Auditing
   The operating system does not perform logging of network activities, so it’s crucial that an exit program include the auditing of transactions into a tamper-proof repository. Ideally, it also has the ability to trigger alerts for critical events.

The main advantage of implementing a good exit program solution is the subsequent ability to control and audit network requests, allowing legacy security controls (such as menu and command line restrictions) to be effective again.

When deciding whether to write your own programs, or to purchase a commercial exit program solution, you need to give careful consideration to performance, and the negative connotation of self-policing. And of course, bear in mind that even a solution as flexible and powerful as PowerTech Network Security adds value only if it’s implemented and maintained correctly.

Risk Management
Risk management refers to the process of understanding the chance of a security exposure being exploited, the costs associated with mitigating the exposure, and the estimated business costs incurred recovering from an event. The level of “risk” is based on the balance of these factors.

There are ways to reduce the risk associated with powerful users accessing servers and applications, and their data. The best security comes from the layered approach mentioned earlier. Pairing a user’s role to the appropriate combination of command line capabilities, special authorities, and private authority to objects, provides the most solid foundation, since overly powerful users will always represent a greater risk regardless of the controls in place.

When a user’s job demands powerful capabilities, a key requirement should include the auditing of their activities. Any user with command line access, or access to data through network interfaces, should be audited using an exit program, as well as the operating system’s legacy audit controls. One solution, PowerTech Authority Broker, provides auditing of green-screen activities, as well as enabling the restriction of powerful capabilities to an as-needed basis. Advanced features include interested party notification and “fire call” functionality for emergency situations.

Controlling the Uncontrollable
When you combine exit programs with legacy security controls, such as menus and command line restrictions, they reduce the risk from powerful users—such as those with *ALLOBJ authority—in two primary ways:

1. Priority of Evaluation
   The network exit program is called before the transaction is passed to the operating system for authority checking and execution. This means that the exit program is able to reject transactions that might otherwise be permitted. For example, in the eyes of the operating system, a user with *ALLOBJ special authority has unrestricted rights to the database. However, an exit program can reject that user’s transactions based on the name of the user, or the type of access being requested. This also allows a powerful user’s activities to be audited to a secure log such as the IBM security audit journal (QAUDJRN).
2. Profile Switching
   An advanced programming technique allows an exit program to override the requesting user’s capabilities. PowerTech Network Security has a feature called “switch profile” that allows a transaction to run under a different profile than the profile that invoked it. While typically used to elevate authority, the same technique can be used to reduce the authority of a user. In the case of the powerful *ALLOBJ user, you can selectively change their requests to run under a lower-level *USE, or even *EXCLUDE, access profile. As such, the operating system’s own authority mechanism then restricts any transactions that attempt to update or delete application data.

Ideally, data management tools should be restricted to only those that can provide a solid auditing functionality. Replacing the functions provided by legacy interfaces (DFU, RUNSQL, and so on) by applications that run from a client allows an exit program to audit and control the requests—even for users with the ultimate power of *ALLOBJ.

You can define profile switching, as found in PowerTech Network Security, to occur on a very granular basis and be completely transparent to the user. Entire servers, individual server functions, or even specific transactions can be set to run under specific profiles regardless of the requester’s authority. Instead of being tied to the single level of security that even a well-implemented object-level security model provides, this offers significant flexibility between the different interfaces: for example, a user is granted *EXCLUDE authority through ODBC, *USE to a particular library through FTP, and *CHANGE for the legacy 5250 application.

Sit back and relax
If you’d like to put Network Security (or any PowerTech security solution) through its paces—including the ability to temporarily override powerful user credentials—we make it easy with a free 30-day trial. Trial applications are fully functional, and can be licensed permanently without requiring reinstallation. We’ll even help you with the configuration process! Call us at 1-800-915-7700 or visit www.powertech.com.