In the System i world, it was always possible to track system access through user profiles. All that was necessary...
was activating and configuring the system audit journal to allow information to be accumulated. Using the display journal (DSPJRN) command judiciously, you could get a list of who signed on to the system and when.
This worked well when the common method of system access was via a green screen terminal, either hard wired or through a terminal emulator like iSeries Access. But in the era of network connections through TCP/IP server functions in the operating system (OS), this model doesn't work as neatly. Users can now log into your system using FTP or iSeries Access leaving little to no trace in your security journals.
In certain cases, however, an audit journal record for "process user profile swap" is left and recorded as a
PS type. This can happen on a logon from iSeries Access using the TCP Signon Server. After a successful logon, iSeries Access seems to do a user profile swap to the QUSER profile, and this gets logged in the journal. In this situation, you could scan the journal for
PS records and gather information about the user profiles establishing network connections with this method.
You can also see a record of remote users connecting to your system using iSeries Access and other, similar clients from the system history log. If you run the display log (DSPLOG) command, you can start the process by scanning for the CPIAD09 message. Do this by using the following command form:
This will show you any evidence of remote logon activity.
But these options are just a drop in the bucket compared to everything that can go on within your system "under the covers." If someone attempts to sign on to your system via FTP using a user profile that doesn't exist on your system for example, even journaling all security events won't record this access. Because this is a popular method that hackers use to try and break into your system, it would be beneficial to know if and when attempts like these are being made.
When IBM opened up the system to TCP/IP connectivity, their solution to this issue was, and still is, to provide exit points in the OS. For servers such as FTP, Telnet, SQL and TCP Signon, the OS lets you create your own program to monitor network activity and even control access to it.
The problem with this approach is that it is entirely passive. The OS is shipped with no exit program in place, and the fact that exit points even exist is still not widely known. In the meantime, all sorts of nefarious system connection activity can be going on without the security officer ever knowing. As a vendor that sells an exit point solution for the System i, I commonly hear from customers starting to use our product that they had no idea so much activity was going on via network server connections.
Another problem with this approach is that coding and maintaining your own exit point solution is a daunting task. Over the dozen years or so that exit points have been around, some of their data streams have changed significantly. To IBM's credit, they have left the old data stream in place and created a new exit point for the enhanced version, but you will have to re-code your application to take advantage of improvements when they are made.
The best solution available is to purchase a good exit point solution. There are a lot to choose from in the System i marketplace today, and the maintenance problem then becomes your software vendor's headache, not yours. Also, most solutions cover all of the exit points available, so you will be fully protected. These exit point solutions give you control over which user profiles can access your system and, in many cases, what objects they can work with. Additionally, all network activity can be logged, so you can finally see everything that is going on "under the covers."
If you have any questions about this topic, you can reach me at email@example.com, I'll give it my best shot. All email messages will be answered.