Common Sense Security Auditing

By Dan Riehl

Adapted from System iNEWS Magazine article “Common Sense Security Auditing” by Dan Riehl

© 2004-2009 Dan Riehl , All rights reserved

The IBM System i provides a plethora of options when it comes to auditing security-related events. I think many of us have shied away from auditing because, from a cursory view, auditing seems only to eat up disk space and generate far more data than a normal human can digest. But I think if we take a common sense approach to security auditing, it's possible to eliminate the drawbacks and get the vital information we need to properly manage the system.

Stop the Confusion

When we speak of security auditing, we are not talking about journaling database files and other objects. We are not taking before and after images of data records. Security auditing is recording security-related events to the system security journal named QAUDJRN. The events recorded are incidents such as "Bad Password entered," "Attempt to access a file without proper authorization," "Joe accessed the sensitive Payroll file," "Library MYLIB deleted," and "Mary changed the QSTRUPPGM system value." Only if we implement security auditing can these and many other security-related events be trapped and recorded.

One of the main sources of confusion regarding auditing is that we have a feeling that it's an all or nothing proposition. Either we have to audit everything or we don't audit anything. In this article, I provide a simple game plan for configuring your OS/400 security auditing so that you can begin to see, and manage, what's really happening on your system. Once you begin to see the benefits, you will want to learn more about the system auditing options and features with a view to creating a more stable and secure system.

Three Simple Steps

To start common sense security auditing, we follow three easy steps:

1. Start Security Auditing.
2. Start auditing sensitive files.
3. Start auditing for powerful or inquisitive users.

To start Security Auditing, you can simply enter the command

CHGSECAUD QAUDCTL(*AUDLVL *OBJAUD *NOQTEMP) +
 QAUDLVL(*AUTFAIL *SECURITY *SERVICE +
 *DELETE *OBJMGT *PGMFAIL) +
 JRNRCV(audlib/AUDRCV0001)

where audlib is any secure library (i.e., CRTLIB LIB(AUDLIB) AUT(*EXCLUDE)).

The CHGSECAUD (Change Security Auditing) command creates the secured journal QAUDJRN, if it doesn't already exist, and sets the system values QAUDCTL and QAUDLVL to the associated values. It also creates and attaches the journal receiver AUDRCV0001 to the QAUDJRN journal.

QAUDCTL and QAUDLVL Values

The *AUDLVL value set here for QAUDCTL means that we want to start auditing security-related events that are specified in the QAUDLVL values. The events that we will audit in this case are

• *AUTFAIL -- Records failed sign-on attempts and unauthorized attempts to access files and other objects
• *SECURITY -- Records many security-sensitive operations such as changing a system value, resetting the QSECOFR DST password, and changing Object authority and ownership
• *SERVICE -- Records the use of System Service Tools (STRSST) and Dedicated Service Tools (DST)
• *DELETE -- Records the deletion of any object
• *OBJMGT -- Records object move and rename operations (you need this only on a production box)
• *PGMFAIL -- Records programs running restricted MI instructions or accessing internal OS/400 structures through unsupported interfaces (required information if you're moving to system security level 40 from a lower level)

There are many more options one could use for the AUDLVL values, but some of these (e.g., *PGMADP, *JOBDTA, *SPLFDTA) can generate a ton of journal entries and are normally of little value.

The *OBJAUD value means that we want to audit certain files and other objects that we will identify in step two as being sensitive. The *NOQTEMP value means that we don't want to audit anything a job does in its own QTEMP library. (For example, at the end of a job, the system deletes all objects in QTEMP. By specifying *NOQTEMP, we prevent the recording of all these routine deletions.)

Auditing Objects and Sensitive Files

We all have a small number of files that we consider sensitive and that need special protection, such as payroll data, health information, credit card numbers, sales, customer, and pricing and cost information. We can audit all access to these sensitive files using Object Auditing.

Before we discuss how to set up Object auditing, we need to understand the impact. When we turn on Object Auditing for a database file, we potentially have a situation where an audit record can be written every time the file is opened. If the sensitive file is seldom used, that's not a problem. But if it's used thousands of times a day, such activity will generate thousands of audit entries that will consume considerable amounts of disk space and certainly won't do much for system performance.

So, we'll take a common sense approach to Object Auditing. If the file is heavily used, we'll use one technique to maximize performance and disk utilization. If the file is seldom used, we'll use another.

To audit specific sensitive objects, we use the CHGOBJAUD (Change Object Auditing) command as shown here:

CHGOBJAUD OBJ(library-name/object-name) +
 OBJTYPE(object-type) +
 OBJAUD(*NONE, *CHANGE, *ALL, 
 or *USRPRF)

With an OBJAUD (Object Auditing) value of *NONE, the system performs no object auditing for the object. A value of *CHANGE causes the system to audit all changes to the object. The value *ALL audits each change or use of the object. The value *USRPRF instructs the system to check the user profile's OBJAUD parameter to see what, if any, auditing it should perform. This is the value we'll use for heavily used files, which we'll discuss in a moment.

When the audited object is a database file, the system records any OPEN operation against the file. If *ALL is specified for OBJAUD, the system records all file OPEN operations. If *CHANGE is specified, the system records only OPEN for UPDATE operations. Security auditing doesn't care whether records are altered, so the OPEN for INPUT only or OPEN for UPDATE is the only thing recorded. To audit the contents of an IFS file, you can use commands CHGDLOAUD (Change Document Library Object Audit) and CHGAUD (Change Audit).

So, for seldom-used sensitive files, we'll turn on object auditing as follows (where myfile and mylibrary indicates your sensitive file):

CHGOBJAUD OBJ(mylibrary/myfile) +
 OBJTYPE(*FILE) +
 OBJAUD(*ALL)

This will record every file OPEN operation, as well as the execution of CL commands that access or change the file object.

For heavily used files, we have to use a different approach (Figure 1). In this case, we'll set the OBJAUD value of the object to *USRPRF. This means we'll record file accesses only if the user profile performing the access has its object auditing value set to indicate that object accesses for that user should be recorded.

Using this approach, we do not audit file access by the typical end users of the file, which filters out normal accesses we don't want to read about anyway. Who cares if the payroll clerk accesses the payroll file? To understand how we record file accesses only by certain users, we need to know the relationship between object auditing and user auditing.

Auditing Powerful or Inquisitive Users

Often, we want to know what powerful users are doing on the system. For example, is QSECOFR, or an alternate security officer-type profile, accessing sensitive data files? To implement user auditing and specify what actions are to be recorded for that user, we employ the CHGUSRAUD (Change User Audit) command. The command's OBJAUD parameter deals specifically with auditing access to files and objects.

CHGUSRAUD USRPRF(user-id) +
  OBJAUD(*NONE, *CHANGE, or *ALL) +
 AUDLVL(*NONE or
 *CMD, *CREATE, *DELETE, 
 *JOBDTA, *OBJMGT, *OFCSRV, 
 *PGMADP, *SAVRST, *SECURITY, 
 *SERVICE, *SPLFDTA, *SYSMGT)

If we specify *NONE for OBJAUD, recording of access to objects is controlled completely by the object itself. For instance, if the object's OBJAUD value is *NONE or *USRPRF, no auditing takes place. If the object's OBJAUD value is set to *ALL, the system records all operations. If the OBJAUD value is set to *CHANGE, the system records only change operations.

If we specify *CHANGE or *ALL for the user profile's OBJAUD value, the system checks the object to see whether the object's OBJAUD value is set to *USRPRF. If that's true, then the user profile OBJAUD value takes control to record all accesses (or only change accesses) to the object.

In the scenario where we want to record sensitive object access only for certain users, we set the OBJAUD value in the object to *USRPRF and set the OBJAUD value in the user profile to *ALL or *CHANGE:

CHGOBJAUD OBJ(mylibrary/myfile) +
 OBJTYPE(*FILE) +
 OBJAUD(*USRPRF)
 
CHGUSRAUD USRPRF(user-id) +
 OBJAUD(*CHANGE, or *ALL)

Figure 1 Auditing Sensitive Objects

One note of caution: When first implementing auditing for objects, watch out for system performance degradation. Many times, when using the techniques described here, the performance impact may be negligible -- but not always. It may be that, due to performance problems, it will only be possible to turn on object auditing for a small sampling period (e.g., 20 minutes) to see which users are accessing certain objects.

Auditing User Actions

The AUDLVL (Auditing level) parameter of the CHGUSRAUD command lets us specify, for this user, which activities to audit. These values include all of the values discussed earlier in the CHGSECAUD command and their meaning is the same here. The auditing specified by the QAUDLVL parameter of the CHGSECAUD command will occur regardless of how the user auditing is configured. But by using the CHGUSRAUD command's AUDLVL parameter, we can specify additional events to audit for a particular user (Figure 2).

To help us track the actions of a particular user, the CHGUSRAUD command lets us specify several AUDLVL parameter values, as shown above. (Notice that we can audit all CL commands executed by the user.) If we specify *CMD as one of the user's AUDLVL values, the system will audit every CL command executed by the user. For commands contained in CL programs that were created as *LOG(*NO) and ALWRTVCLSRC(*NO), the entire command string isn't logged, but at least the command name is logged.

Here is a common sense way to set up user auditing for a powerful or inquisitive user:

CHGUSRAUD USRPRF(user-id) +
 OBJAUD(*CHANGE, or *ALL) + 
 AUDLVL(*CMD, *CREATE, *DELETE, 

 *JOBDTA, *OBJMGT, *OFCSRV, 

 *PGMADP, *SAVRST, *SECURITY, 

 *SERVICE, *SPLFDTA, *SYSMGT)

Figure 2 Auditing User Activities

Reviewing Audit Journal Entries

Now that we have our security auditing properly configured, the system starts writing entries to the QAUDJRN journal. So how do we view the data we have collected to see who's doing what?

IBM's iSeries Security Reference (SC41-5302) contains complete sections about the journal entries we're now generating. We can use the command DSPAUDJRNE (Display Audit Journal) to view the journal entries:

DSPAUDJRNE ENTTYP(AF) OUTPUT(*)

The ENTTYP parameter indicates the type of information we want to view. In this example, we indicate the entry type as "AF," which displays authority failures. Using the DSPAUD JRNE command is a challenge because we need to know what journal entry types we want to view. Pressing F1 (Help) in the command prompt lists the allowable values for a specific entry type. Again, the Security Reference is the best resource for locating the entry types and what they mean. Some of the more common entry types listed in the V5R2 Security Reference are in Figure 3.

More on Common Sense

While we haven't discussed all the possible actions one could take to start and configure system security auditing, we've established a great "common sense" starting point.

Figure 3
From IBM’s iSeries Security Reference IBM Pub# SC41-5302-06
 

Entry

Type Description

AD Auditing changes

AF Authority failure

AP Obtaining adopted authority

AU Attribute changes

CA Authority changes

CD Command string audit

CO Create object

CP User profile changed, created, or restored

DO Delete object

DS DST security password reset

JD Change to user parameter of a job description

JS Actions that affect jobs

NA Network attribute changed

OM Object move or rename

OR Object restore

OW Object ownership changed

PA Program changed to adopt authority

PO Printed output

PS Profile swap

PW Invalid password

SE Subsystem routing entry changed

SF Actions to spooled files

SM System management changes

ST Use of service tools

SV System value changed

VL Account limit exceeded

VP Network password error

YC DLO object accessed (change)

YR DLO object accessed (read)

ZC Object accessed (change)

ZR Object accessed (read)

© 2004-2009 Dan Riehl , All rights reserved