Common Sense Security Auditing for the AS/400 By Dan Riehl www.Sec... http://www.securemyi.com/articles/artaudit.

html

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

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.

1 de 6 20/12/2011 09:48 a.m.

Common Sense Security Auditing for the AS/400 By Dan Riehl www.Sec... http://www.securemyi.com/articles/artaudit.html

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:

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.

2 de 6 20/12/2011 09:48 a.m.

Common Sense Security Auditing for the AS/400 By Dan Riehl www.Sec... http://www.securemyi.com/articles/artaudit.html

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):

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.

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:

3 de 6 20/12/2011 09:48 a.m.

Common Sense Security Auditing for the AS/400 By Dan Riehl www.Sec... http://www.securemyi.com/articles/artaudit.html

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

4 de 6 20/12/2011 09:48 a.m.

Common Sense Security Auditing for the AS/400 By Dan Riehl www.Sec... http://www.securemyi.com/articles/artaudit.html

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:

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

5 de 6 20/12/2011 09:48 a.m.

Common Sense Security Auditing for the AS/400 By Dan Riehl www.Sec... http://www.securemyi.com/articles/artaudit.html

journal entries:

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

6 de 6 20/12/2011 09:48 a.m.