With any security implementation, established rules become less effective as time passes. Because your security requirements and your systems aren’t static, you must continually audit and adapt your security plan to stay current. Be aware that your system is constantly changing.
IBM i includes extensive auditing features and provides a valuable tool for monitoring security-related events. The Security Audit Journal (QAUDJRN) is the primary tool for event auditing and is the wealthiest source of auditing information on the system. A security auditor inside or outside your organization can use the auditing function provided by the system to gather information about security-related events that occur on the system. The information in the audit journals is used to evaluate whether the security plan is complete and to make sure that the planned security controls are in place and working. This type of auditing is usually performed by the security officer as part of daily security administration. The audit journal is also used to detect attempted security violations as well as to prepare for a future event, such as installing a new application, moving to a higher security level, or setting up a communications network. Additionally, you can use the audit journal to monitor the use of sensitive objects, such as confidential files.
Which things you audit and how often depend on the size and security needs of your organization. You configure the audit controls that define what security related events appear in the journal. For example, system values, user profile parameters, object-auditing attributes. They all must be set properly to ensure critical events are logged.
Commands are available to view the information in the audit journals in different ways. You can define auditing on your system at three different levels: system-wide auditing that occurs for all users, auditing that occurs for specific users, and auditing that occurs for specific objects.
The Change Security Audit (CHGSECAUD) command creates the audit journal and a receiver and sets the appropriate system values for you.
In addition to auditing at the system level, you can perform user-level event auditing. You can tell IBM i to audit a user’s actions, to monitor a user’s particular objects, or both. You might want to turn on auditing for only a few users and not the entire system. You can even audit additional actions for a few individuals beyond what is audited at the system level. To configure auditing at the user level you use the Change User Audit (CHGUSRAUD) command.
Object auditing lets you track which users access a particular object. You use the OBJAUD attribute associated with an object description to track this. You can track a user simply using an object or changing an object. To change the object access auditing control for one or more objects on the system, you use the Change Object Audit (CHGOBJAUD) command. You can specify CHANGE ONLY or ALL which will audit any read or change access to the object.
Using the security audit journal, you can monitor for authority changes or authority failures. It’s important to audit events related to insufficient authorities, such as a user entering an incorrect user ID or password, or a user trying to access an object with authorities he or she doesn’t have. This will help you determine whether you have frequent attempts to gain access to specific user profiles without the correct password which would probably mean they are guessing the password. This is also helpful to debug which object a user lacks authority to when a “Not Authorized” message is issued. Since applications can be written in ways that make it difficult to determine which object a “Not Authorized” message refers to, the details of the audit journal entry will list the specific object as well as the user profile that lacks sufficient authority. For example, I signed on to one of our Power Systems recently using the QSECOFR user profile. A few screens into an application, I got a “Not Authorized” message. How could that be when I had signed on with QSECOFR? Luckily we were using the security audit journal. So I examined the audit journal entry and found out that a profile swap had occurred and the user receiving the message was actually a different profile, not QSECOFR. The journal entry also listed the object for which I lacked authority.
Monitoring object deletion is also important in helping you determine what activity has actually occurred on your system. The system creates an audit journal entry whenever an object is deleted. These entries are vital when you’re trying to determine the actions taken by a disgruntled employee on a production system. They’re also helpful in debugging programs and testing scenarios that delete the wrong object.
You can use security-related system values to build the foundation for your system security structure. By changing a single system value you can limit the number of successive incorrect sign on attempts allowed at a workstation, which would minimize the password guessing game and lower your security risk. Just because those system values are set, doesn’t mean you can ignore them! You need to monitor for changes to those system values—especially the security-related ones—to ensure your security plan stays in place.
