I have recently heard from several readers lamenting the deplorable state of security in their System i third-party application software. Some products enforce the establishment of a standard group user profile along with a default password for that profile. Others have their data files configured with all access to the public. In this day and age, these situations are certainly inexcusable. But, what can you do?
First, a little history is in order. A lot of mature third-party software has been around since before many of you were working in the IT field. In those days, there were no PCs, no networks and little connectivity between systems. So, security was controlled at the application level. By that, I mean that users were presented with menus and could only access data by choosing the right menu option. If the user wasn't authorized to use the data, the menu option would not be available to them. For its day, it was a good security model.
But, today is very different, with FTP, ODBC, iSeries Access and other such PC-based tools that are connected to your system via high-speed network connections. That old menu security model is not applicable to today's environment.
In the modern System i implementation, if your data files have public access to all users, then someone can connect to your system with FTP and download to their heart's content. Granted, they will still need a user profile and password, but is that the security model that you want to enforce for your shop? I don't think so.
An even worse situation comes from users with iSeries Access installed. From their desktop, an adventurous user could easily browse around your system looking for interesting file names and libraries until they find just about everything on your system.
So, what's the solution to this problem?
First, when you're shopping for software, the product's security implementation must be understood before you get too far down the road. If the product is wide open, move on to another vendor.
If you've already got a product with this security model implemented, you probably are not in a position to just switch to another vendor. In that case, the first thing you should do is contact the vendor and demand that the situation be corrected immediately. There are lots of easy solutions that a responsible software vendor can implement to correct this problem. Don't take "No" for an answer.
If you get little cooperation from your software vendor, you should take matters into your own hands. The quick solution is to implement exit point controls for the critical data in your system. If you don't have the know-how or wherewithal to create your own exit point programs, there are quite a few general purpose products on the market today that are good and address this issue.
The worst thing you can do, however, is to just sit back and wait for your vendor to fix the problem. In the interim, your data is exposed. You may think you're safe, but you just cannot guarantee the safety of your data in this environment.
If you have specific questions about this topic, email me at rich@kisco.com. All email messages will be answered.
---------------------------
About the author: Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.
