The last time I wrote, I discussed tracking down hidden trigger programs on your system that could be just waiting for a specific event to release their malicious payload. But, as I've thought about this issue since then, there are other places where someone could "hide" a call to a malicious program that could get easily overlooked.
Let's look at two other areas for concern. These are the system job scheduler and exit programs. Both are places that someone -- intent on doing harm to your system -- could hide some malicious program. In each case, OS/400 can review the programs that are sitting there, and you should take a look periodically to see how each is being used on your system.
OS/400 has had a nice, easy to use job scheduler built into it for a long time now. Most shops where I've done consulting work seem to know about it and use it for regularly scheduled jobs. Though, that also means that the programming staff is aware of it and could misuse or abuse it.
To review the current contents of the system job scheduler, use the OS/400 command Work with Job Schedule Entries (WRKJOBSCDE). This command displays information about every job in the system job scheduler. It tells you what the job is, how it is invoked and when it is next scheduled to run. You should review each entry to make sure that you know its purpose and when it is next scheduled to run. A suspicious job, to me, would be one that is not set to run for quite a while. Most scheduled jobs happen frequently, either on a daily, weekly or monthly basis. If you see something on a different schedule than one of these, I'd pay particular attention.
The registered exit-point programs on your system are another area you should periodically review. Exit points are hooks into OS/400 processes. These are provided in OS/400 so customers can add their own customized processing called from OS/400 during normal operations. For example, many of the third-party network security products now available on the market use exit points to add security checking to the various network operations in OS/400. The potential problem is that a rogue program could get registered to an exit point just waiting for a specific OS event to occur before it jumps up and gets noticed.
To review exit programs registered on your system, use the OS/400 command Work with Registration Information (WRKREGINF). This command displays a list of the OS/400 exit points on your system -- remember that they are different for every level of OS/400. For each exit point, use the option '8' to see if there is a registered exit program for the exit point. If you find any, make sure that you know what they are there for. Don't be surprised to find some exit programs already registered. If you are using a network security system, you should find many programs registered. Also, some come registered with OS/400. For example, you will find that the IBM product Service Director uses some of the exit points as does the OS/400 Mail Server Framework (MSF). Just make sure that you can identify each program that shows up as a result of your review.
If you have any questions about specific exit points and you're not sure if the registered program is legitimate, just ask me and I'll give you my best shot. My e-mail address is rich@kisco.com.
Rich Loeber is president of Kisco Information Systems Inc., in Saranac Lake, NY. The company is a provider of various security products for the iSeries market.
==================================
MORE INFORMATION ON THIS TOPIC
==================================
Can you trust all those trigger programs?
You may think that because you're working on the iSeries that you're safe from rampant computer viruses, worms and other malicious programs moving their way around the Internet, but 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.
Standardized security setup across multiple systems
Nothing supports the popularity of the iSeries as much as the number of customers with multiple systems installed. For security officers, it can easily mean a lot of extra work keeping each system configured and setup for company security policies. While this can be a complex task, IBM has provided a little known capability in OS/400 for quite a while now that can help you to enforce standard security configuration setup rules across separate systems.
Secure JOBSCDEs with an authorization list
One user writes, "We have multiple customers on our system and we don't want them to be able to view another customer's JOBSCDEs. Is there any way to secure JOBSCDEs with an authorization list"? Search400.com security expert Carol Woodbury responds.
Use exit programs to secure your system
In this expert q&a security guru Paul Jury explains the best way to secure users from accessing data via applications using ODBC.
