A Case For Contextual Security

By Rich Loeber

My wife and I live in the Adirondack Mountains of northern New York state. During most of the year, except for 10 weeks during the summer, we have very few neighbors with the closest being almost a mile away. On a normal day, we get a handful of cars that drive down our road (unless you count the number of times the snow plow goes by). In this context, we're not very concerned about security. We rarely, if ever, lock our doors. We know all of the year round residents and they know us. We all look out for each other and that seems to be all of the security that we need. Our biggest security consideration is the local bear population, they get into the trash if you're not careful and make quite a mess.

In the IBM i world, context can define how you handle security. Security in the OS is not attenuated to context, so you have to think about your requirements and implement contextual considerations as they apply.

What do I mean by contextual security? Here's the classic example.

Suppose that you have an order processing application that records credit card information and then processes that information to obtain credit card authorization approvals. Obviously, the clerk entering the order needs to have access to your customer database in order to enter the credit card information or validate the information that you already have on file. Within your standard security model, you will need to grant this user access to the information with sufficient authority to add new information, change existing information or even delete current erroneous information. For their normal order processing tasks, this user can be configured easily to provide for database access and change authority.

But, what about other possible accesses to this data that do not fall within the normal context of their job execution? The same level of access that they normally require is inappropriate when accessing your customer credit card information via FTP or by using IBM iAccess download functions. When using these functions, this same profile can make a copy of all the credit card information on their desktop, then copy the information to a flash disk or memory stick and walk out of the office with all of your credit card information in tact and nobody would be the wiser until the story breaks in the NY Times.

Given this reality, obviously the single context approach to database security is not going to work. The user does need access rights to do their normal job requirements, but they need to be restricted from access for other contexts.

Fortunately, there are several ways to accomplish this on the IBM i and I'll just mention three of them here so you can start thinking of how to get this taken care of.

First, and possibly easiest although not always cheapest, is to buy and install a good exit point security solution. There are several such solutions available on the market from reputable software developers. (I recommend SafeNet/i, the solution from my company.) The exit point solution lets you define a network access context for your users and restrict network accesses that might otherwise be wide open to them. You won't have to change the security setup in the IBM i OS, but the extra layer of security from the exit point solution will add the contextual security you need from network based applications like those already mentioned. You could write your own exit programs, but exit point programming is not for the feint of heart and the rules periodically change as the OS goes from release to release, so it is better to go with a good solution from a trusted software supplier (like ours!).

There are two other approaches that are similar in nature and can also let you define security on your IBM i based on context. One is adopted authority, the other is profile swapping. In both cases, the security in force when you application runs is NOT based on the user profile doing the work but on some other method. With adopted authority, your program is set to base security decisions on the user profile that owns the program, not on the profile that is running the program. This way, you can control who gets to use the program, then the program itself can control the resources that it needs access rights to. With profile swapping, you can let the requesting user profile control things up to the point where different access rights are needed, then under program control, you can call an API in the OS to swap profiles and run under a different profile for a given duration of processing. Either way, the user profile used to determine access rights is different from the user signed into the application, giving you contextual control over the situation.

If you have any questions about this topic, you can reach me at rich at kisco.com, I'll give it my best shot. All email messages will be answered.