(Some of this section is adapted from an iSeries NEWS Magazine, July 2004 article “Common Sense Security Auditing” By Dan Riehl.)
A Common Sense Approach
AS/400 provides a multitude of options when it comes to auditing security-related events. Many 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 by taking a common sense approach to security auditing, it's possible to eliminate the drawbacks and get the vital information needed to properly manage the system.
Relevant Standards:
COBIT DS13.1 - Operations Procedures and Instructions
Define, implement and maintain standard procedures for IT operations and ensure the operations staff is familiar with all operations tasks relevant to them.
COBIT DS5.5 - Security Testing, Surveillance and Monitoring
Ensure that IT security implementation is tested and monitored proactively. IT security should be reaccredited periodically to ensure the approved security level is maintained. A logging and monitoring function enables the early detection of unusual or abnormal activities that may need to be addressed.
Stop the Confusion
Security auditing is not merely journaling database files and other objects or 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 when implementing security auditing can these and many other security-related events be trapped and recorded.
One of the main sources of confusion regarding auditing is the feeling that it's an all or nothing proposition. Either we have to audit everything or we don't audit anything.
But in reality, all that is needed is 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, follow these 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 *SYSMGT +
*DELETE *OBJMGT *PGMFAIL *SAVRST ) +
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.
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 using the above command 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). |
|
*SYSMGT |
Log changes to certain system management areas. |
|
*SAVRST |
Log restore actions to security sensitive objects. |
|
*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 for using the AUDLVL values:
|
*CREATE |
Log creation of new objects |
Medium |
|
*JOBDTA |
Log job events such as start and stop |
Medium |
|
*PGMADP |
Log usage of programs that adopt authority |
Medium |
|
*NETCMN |
Log APPN firewall events |
Low |
|
*OFCSRV |
Log Office Vision/400 security changes |
Low |
|
*OPTICAL |
Log usage of optical storage devices |
Low |
|
*PRTDTA |
Log printing functions |
Low |
|
*SPLFDTA |
Log usage of spooled files (reports) |
Low |
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 identified 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.