For many years, you have been repeatedly advised that securing the exit points on a modern iSeries/i5 is critical. And for good reasons. Very few of the iSeries in use today have no need to secure at least one exit point. Because of the increases in the number of "non-5250" ways to get to the box, the authority and access rules that were adequate in the green-screen world no longer cut it.

However, as I stated in my last "System Sentinel" article, there is not always a commitment to do the right thing. The problem I find is that organizations have implemented exit point processing programs either halfheartedly or with no real thought of how to use it. This article offers a few tips on how to really use this security facility that I truly believe is critically important to you.

How We Got Here

First, a little background: In the mid-1980s, IBM introduced a couple of security exit points at the stage in the development of the OS when more and more data access methods were made available on the System 38. The need for these exit points can be simply explained. Imagine a user whose job function included changing an employee's department number in the good old days of native security. This involved signing on and navigating to the "change department number" program through menu options. Then, on executing this RPG program, the relevant files were updated in the background.

To do this, the user would normally be granted authority to update the necessary files, including the employee payroll file. Numerous authority methodologies could be in place to achieve this. But that was OK; the RPG coding was controlling the update, such as which records the user could access, what fields could be changed (only department number), and the acceptable values for department number.

But in the changed world of the newly connected System 38, this all went wrong! Using PC Support (later Client Access and now iSeries Access), that same user could transfer the whole payroll file to a PC, edit it, and send it back. There was nothing to stop the user from changing his own salary (or that of the CEO) or from changing a "Yes/No" flag to a "Z," potentially causing later problems with other data accesses.

OK, maybe this is a slight oversimplification of the problem, but it is valid nonetheless. Since IBM first recognized the exit point requirement, other types of requests that can be processed into the iSeries have been introduced--ODBC, FTP, file transfer, Telnet, DDM, remote commands, etc. You need exit points so that you can intercept the requests and either monitor what is coming through or prevent requests that would normally be acceptable in the view of the native authorities.

Whether you choose to build your own exit point programs (with instructions from IBM at iSeries Information Center; look for "iSeries Internet Security" and "FTP security" for some specific advice) or buy one from a vendor (e.g., Bytware, Kisco, NetIQ, PowerTech, or the company I work for, SafeStone) is up to you, but for most situations, something is necessary.

Collecting Data

Now, let's address what data you collect and what you do with it.

First, do not be surprised if there is a lot of data to be collected and monitored. I have seen many installations where millions of events per day are processed though the exit points. With the modern front-ends to our iSeries applications and the use of more and more PC-based tools to access the iSeries databases, this isn't surprising. In addition, application and tool vendors typically don't explain how their products work under the covers. I've seen fax software that checks data queues every fraction of a second and barcode reader software that performs ODBC-based polling over and over again. It is not my place to say whether this is good or bad application design; however, don't be surprised if you see things you don't expect when you activate your exit point monitor.

Many security administrators looking at exit points for the first time approach tools such as Microsoft Excel and Access as the computer embodiments of evil. That's unfair; applications like these are very important for business and provide powerful tools to help users. Think of them in the same way you think of power saws: Used correctly, they're perfectly safe. But if you ignore the necessary safety mechanisms, you might lose something.

Therefore, when collecting information from the exit point, you must be selective. In IT security, one of the most overused analogies is the "needle in the haystack" principle. But it does apply here. If you have many thousands of transactions to look at per day, how will you ever find the important requests?

This is particularly true for those organizations that have chosen to take the safe route; they have bought exit point software or written it themselves, but all they are doing is monitoring the requests. They are not prepared to take the next logical (and important) step, which is to reject any requests that are unknown. This is normally explained away by fear: "What if we have a 'special' transaction that occurs only once every five years and I don't have an authority rule in my exit point manager? It could stop my business processes!"

While keeping the business running smoothly is an admirable goal, it should not be used as a reason to dilute the attempt to secure your system. If you are not monitoring the exit point requests every day, you are going to either miss something or find out about it too late. The best solution is to reduce the amount of data being collected so that you have less data to audit. The first step to practical exit point security is ensuring that all of the acceptable requests that go through the exit points can be ignored.

The next step is to introduce control of the requests. Your program accepts or denies the request and passes a flag back to the exit point so that the user can be either allowed or disallowed to perform that function. Within this checking process, be as granular as possible in the authorizations you define. This will make your process more flexible as you fine-tune your authorities. By "granular" I mean...

• Date/time processing--It may be useful to specify that an exit point is available only at certain times on certain days.
• Function level--It may not be enough to allow a user access through an exit point; you may want to control the functionality of each exit point. For example, you may want to permit a file to be transferred from the iSeries/i5 to the user's PC but not back again to overwrite the file.
• IP address--Sometimes, it is useful to be able to check that the user is requesting from an acceptable IP address range.
• Object level--Some exit points lend themselves only to high-level checking (e.g., FTP logon). The user needs only "yes/no" definitions against this exit point. However, for most exit points (e.g., FTP server and client requests), the processing will be more useable if you permit user access to specific libraries, objects, folders, and documents.

Note: As a brief aside, I want to discuss the principle of inclusive/exclusive security checks. On a few occasions, I have spoken to clients who say they want to stop user access to only a couple of files, such as the payroll file and the price file. The user can FTP or file transfer everything else to their heart's desire. This is not standard security practice. We know that a high percentage of fraud is internal, and we know that most iSeries have more high-level (e.g., *ALLOBJ) profiles than the organization is comfortable with. So an unscrupulous user can simply create a copy of the payroll file or price file and then transfer it out of the iSeries. There goes your exclusive security principle.

The final aspect of practical exit point security is the necessity for continued review of the technology. This is not an area of security in which you turn it on, select the requests you want to audit, define your authority rules, and never touch it again! For a number of reasons, you need to keep on top of this technology on a regular basis. For example:

• Sometimes, a new version of an application can process in a different way. Whether it is your 5250 access software, your business application, or a Microsoft tool, the requests may get processed through a different exit point or in a different way. For example, recent versions of iSeries Navigator process most of their functions through the "remote command/remote program" exit point. Therefore, some security administrators found that a lot of new authorities had to be granted.
• New versions of the OS may need special actions to be performed. One example of this is the SQL packages created by products like Microsoft Excel. To avoid exit point processing problems IBM advises that "significant changes to the operating system or hardware should always be followed by the deletion of all SQL packages. If you do not perform these deletions, it is possible that your exit point monitoring software will not correctly validate SQL requests. For more details, see SQL Packages Q&A.

Don't be complacent. Repeat testing of your exit point programs whenever you make a major change to your OS level or business applications.

Security You Can Tailor

Exit point security is a great feature that tailors to your environmental needs. On numerous occasions, when demonstrating how we have expanded our iSeries security tools to other platforms in the enterprise, our clients have asked whether we can extend our exit point processing to other operating systems and databases. Unfortunately for them, the processing relies upon the fact that IBM provided the capability to invoke these programs in OS/400. Fortunately for all of us, we work on one of the most securable business systems available today.

Martin Norman is Senior Systems Engineer for SafeStone Technologies, an IBM BP specializing in compliance and identity management. As one of the original developers of SafeStone's security portfolio, Martin has performed security audits and advised on installations for clients throughout the United States and Europe. Martin can be contacted at mnorman@safestone.com.