Manage Learn to apply best practices and optimize your operations.

AS/400 security auditing and *ALLOBJ access

System i security expert Carol Woodbury discusses *ALLOBJ access with an AS/400 security auditor.

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

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.