I've been auditing AS/400 security for nearly a year, so I am still new. When I asked one client why their programmers have *ALLOBJ, their response was that *ALLOBJ gives them read-only access. This threw me off guard. From all the training, articles and reference manuals to which I have access, I know that this is not true. I also learned that the programmers migrate their changes into production after development/testing. The client's explanation is that programmers also serve as support to security officers and administrators and that is why they need so much access and special authority. What type of monitoring should be done to mitigate the risk that programmers will be able to do anything without management's knowledge since they have so much access?
The client's answer is obviously wrong. *ALLOBJ gives them the ability to do whatever they want to to an object. There are numerous issues with the scenario you described. First, programmers should not be promoting their own objects (no separation of duties there!). Second, programmers should not permanently need *ALLOBJ assigned to their profiles. If it is a small shop, there are occasions when programmers may need more capabilities, such as during a system or application update. I would audit the commands the programmers run by using the CHGUSRAUD command, specifying *CMD for the AUDLVL parameter. Then monitor this activity in the audit journal by looking for CD entries.
Dig Deeper on iSeries system and application security
Related Q&A from Carol Woodbury
Before changing password levels and upgrading operating systems on the AS/400, ensure the clients connecting to the NetServer do not need the old ... Continue Reading
Look in the audit journal (QAUDJRN) on the AS/400 for an authority failure message with the name of the library as the object name. Use the ... Continue Reading
When error messages arise concerning attempts to use a permanent system object without authority, find the source of the issue by looking for an AF ... Continue Reading