Manage Learn to apply best practices and optimize your operations.

Data access risks of ODBC

What is the best way to secure users from accessing data via applications using ODBC?

This is a frequent concern of shops with PC's attached to their iSeries (which would all of us, wouldn't it?). And while it's good that you're aware of the data access risks of ODBC, I would warn you to also be aware of the similar exposures created by other OS/400 services such as, FTP, DDM, Remote Command, and a whole host of Client Access services.

There are really two main avenues of attack when trying to secure data against ODBC (or any other network) access -- either you change all of your data files so that the end user does not have direct access to the data (something like *PUBLIC = *EXCLUDE authority to all of your data) and then change your business applications so that the users can still access the application somehow, or you put exit programs in place to regulate the flow of ODBC traffic on and off of your system. Most folks choose the exit program route, because it is simple, secure, quick to implement, and it is less likely to disrupt your business operations than a complete application security redesign.

The value of an exit program is that it sits between the end-user's PC and the iSeries database and controls who can access DB2/400 data. The exit program acts as a sentinel so that only the ODBC or DDM traffic that you want is let through. What's more, it also can create a log of all the traffic (whether allowed or not) so that you can see who is trying to read or change your data.

When it comes to putting exit programs in place, you have two choices again, either write the programs yourself, or purchase a packaged solution from an experienced software vendor. Writing exit programs requires a fairly substantial amount of experience working with IBM API's and interfaces, as well as a dedicated test machine to experiment on; you don't want to lock everyone out of your production system because your exit program has a little bug in it. You also want to make sure you cover all of the network access points that people can use to access data or run commands. There are over 30 exit points to cover, and over 200 discrete functions within those 30+ exit points. If you just cover ODBC, and leave DDM or the Remote Command server exposed, you've still got a significant exposure.

A purchased solution is often the more cost effective route. It provides you with a complete and fully tested solution that will work on your current release, and if you've picked a responsible vendor, on future IBM releases as well. When evaluating any security solution, I recommend the S.U.R.F. test, that is the Solution should be:

Secure: Both in it's approach to your data and its approach to it's own data.

Usable: Easy to use and easy to implement. Complicated solutions don't often get actually implemented, and if they are, are difficult to verify and maintain.

Reliable: Security solutions have to work. Every time. End of story.

Fast: Performance is critical, a security solution that impacts your business processing runs the risk of getting torn out in favor of business flow.

The Bottom Line is, you are on the right track. Secure ODBC, FTP, Remote Command, DDM and all the other ways of getting at your data. Exit Programs are safest and fastest way to get it done, while doing nothing is a significant risk.


The Best Web Links: tips, tutorials and more.

Search400's targeted search engine: Get relevant information on security.

Ask your systems management questions--or help out your peers by answering them--in our live discussion

Dig Deeper on iSeries system and application security