Can you trust all those trigger programs?

If you've seen the movie "Troy," or if you were paying attention in history when you were in school, you know that the Greeks brought down the city of Troy with the gift of a large wooden horse. Of course, unbeknownst to the Trojans, the horse was filled with soldiers and as soon as things settled down in Troy, the soldiers broke out of the horse and took the city.

In these days of rampant computer viruses, worms and other malicious programs moving their way around the Internet, the concept of the Trojan Horse is alive and well. But, you say, I'm sitting here working on my completely safe and secure iSeries-AS/400 system running the most secure operating system in town! These things can't affect me.

Think again. A malicious program can still get written and installed on your system, hidden away waiting for the right event to come out and strike. How, you ask? As a trigger program.

When I heard about this, I was much like most of you thinking that this just didn't apply to me. But then I ran the audit report that IBM includes in OS/400, and boy was I surprised at the number of trigger programs that are installed on our closed development system. I thought that the report would come out empty. Lo and behold, I got an eight-page report with information on more than 90 trigger programs in place that I had no idea about. Granted, most of them appear to be parts of OS/400, but I did find some application triggers that I did not know were there. Fortunately, I found that none of them were malicious, but I had my doubts for a while since one of them was written by a programmer who left our employ under somewhat of a cloud.

OS/400 includes a command that lets you keep track of the trigger programs that are installed on your system. The command lets you run a master list of all trigger programs and then, periodically, just list the trigger programs that are new or have changed.

To get started on understanding the trigger programs on your system, run the following command:

PRTTRGPGM LIB(*ALL) CHGRPTONLY(*NO)

This will produce a baseline report of all the trigger programs on your system. Be prepared for the command to take a long time to run. You might want to consider running it in batch. Review the listing closely and make sure you know what each of these programs does. If you see a program that you suspect, track down the source code and make sure you know what it is about. If it is from a third-party software provider, get a statement from the software vendor that describes what the program is doing. Since trigger programs react to events, they are good candidates to lie in wait for the right action to happen on your system and release their malicious payloads.

Once you have your baseline report, you can then periodically run the same command, just changing the CHGRPTONLY parameter to *YES. This version of the report will list changes and new trigger programs on your system.

If you have any questions concerning this tip, feel free to contact me directly. My e-mail address is rich@kisco.com.

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.

==================================
MORE INFORMATION ON THIS TOPIC
==================================

Testing user profiles
Security guru Rich Loeber takes a look at testing user profiles. According to Rich, the best time to test a user profile is when you initially create it. If, however, you have never tested your user profiles, you may want to tackle a project to get the profiles on your system tested on a periodic basis to make sure that they conform to your security objectives.

Testing resource security
Rich Loeber takes a look at how you can go about testing your resource security setup. There are two things that you need to test and evaluate on your system. First, you have to make sure users have sufficient authority to get all of their work done without a problem. Once that has been established, you then need to go back and make sure users don't have too much authority, thereby compromising the confidentiality issues that prompted you to secure specific resources in the first place.

Top 10 security tips
Not surprisingly, security is even more of an issue this year -- especially with Sarbanes-Oxley compliance deadlines. Here are 10 hot tips to ensure your security is all it can be.

Are my objects really secure?
One user that comes from an OS/390 environment writes, "I have recently been assigned to the iSeries system. When reviewing the security of my objects -- through WRKOBJ display authority -- I see that the objects are not secured by an Authorization List and PUBLIC has full access. How secure are my objects?" Security expert Carol Woodbury explains.