Admin Alert: Getting Started with i/OS Security Auditing, Part 1
September 15, 2010 Joe Hertvik
|
Sometimes you need more information about what’s happening on your system. Who changed their password? Have any system values been changed recently? Who added an entry to the System Reply list? For company security and auditor information, sometimes you need to gather information about system events. That’s where i/OS security auditing comes in. Security Auditing in Two Paragraphs IBM i/OS security auditing allows you to collect information about system events that can affect system security and integrity. To implement auditing, a user configures his system and specifies what types of information he wants to collect. After turning auditing on, he can retrieve information on a number of critical i/OS functions including authorization failures, security configuration changes, program failures, save restore information, and object management information. He can also collect information for individual users or for individual objects. This week and next, I’ll look at how to configure security auditing on an i/OS V5R4Mx system. Today, I’ll look at how to set up the system. Next week, I’ll look at how to retrieve the data, giving you a broad overview of the entire process. Let’s get started. Configuring Your System for Auditing To get started with system security auditing, you need to perform the following steps. But don’t worry about creating these objects and turning on system settings just yet. In the next section, I’ll show you a command that will perform all these tasks and turn on security auditing with just one command. 1. Determine if auditing is already active on your system. You can do this by running the Display Security Auditing (DSPSECAUD) command. This option can also be reached by entering Option 11 (Display Security Auditing) off the Security Tools menu. This will show all your current security auditing values on a display that looks something like this.
If auditing is active, you can skip to step four to modify which values you are auditing for. If auditing isn’t active, continue to step two. 2. Create an initial journal receiver to receive the auditing entries for the items that you want to monitor. To create a new receiver in the library of your choice, run the following Create Journal Receiver (CRTJRNRCV) command.
CRTJRNRCV JRNRCV(lib/jrnrcvname) TEXT('Journal receiver for system audits')
The next step is dependent on creating this journal receiver. 3. If necessary, create the QAUDJRN journal object (type *JRN) in library QSYS. The system uses the QAUDJRN journal to capture and record the information that you are auditing for. It places that information into the journal receivers attached to the journal. This journal is not necessarily shipped with i/OS and if it isn’t present on your system, you can create it by using the following command.
CRTJRN JRN(QSYS/QAUDJRN) JRNRCV(lib/jrnrcvname) MNGRCV(*SYSTEM) DLTRCV(*NO)
TEXT('Auditing Journal') AUT(*EXCLUDE)
It’s critical that the journal’s name is QAUDJRN and that it resides in the QSYS library. System auditing cannot function if it doesn’t have that name and location. In this example, the journal receiver name equals the name of the receiver I created in step two. I set the Manage Receivers (MNGRCV) parameter to *SYSTEM, which tells the system to automatically create a new receiver and swap it in for the current receiver when the current receiver’s size becomes too large. Even though I set MNGRCV to *SYSTEM, I made a point to set the Delete Receivers (DLTRCV) parameter to *NO. This tells the system not to automatically delete old receivers after they have been detached from the QAUDJRN journal file. This is important because the journal receivers contain all the audit history for my system, and I don’t want to automatically lose that history because my journal receiver file gets swapped out. Keep in mind, however, that this obligates me to manually review and delete old journal receiver objects as needed. I can clean up my receivers by manually reviewing and deleting the old receiver objects every year or by setting up a custom-written program that automatically evaluates and deletes the old receivers for me, as necessary. It’s important to occasionally clean old auditing receivers as excessive receivers can take up a lot of system storage. 4. Tell the system what actions you want to audit by configuring the Security Auditing Level (QAUDLVL) system value list and (if necessary) the Security Auditing Level Extension (QAUDLVL2) system value list. You can configure these system values by using the following work with system value command. WRKSYSVAL SYSVAL(QAUDLVL*) Start by configuring the list in the QAUDLVL system value. If there are too many values for QAUDLVL, place the overflow values in the QAUDLVL2 system value. The values tell i/OS auditing exactly what actions you want to audit for. The list of possible values you can add to the list and what they do include the following:
You can find descriptions of all possible security auditing values for QAUDLVL and QAUDLVL2 in the iSeries Information Center. 5. After performing the other steps, you can now flip the switch to start security auditing. Do this by turning on the Auditing Control (QAUDCTL) system value. Although there are five values you can set QAUDCTL to, your best move is to set it to *AUDLVL, which tells i/OS to take its auditing parameters from the QAUDLVL and QAUDLVL2 system value lists you set up in step four. By default QAUDCTL is set to *NONE, which means system auditing is turned off. Provided you have performed the other three steps correctly, this will activate auditing on your system. These are the basic steps to start auditing on your system. However, IBM offers several other system values for setting up object auditing for specific users, including: the Change User Auditing (QCHGUSRAUD) system value, controlling what happens when the system cannot access the audit journal; and the Auditing End Action (QAUDENDACN) system value. You can read more about setting up additional values by going to the setting up security auditing page in the iSeries Information Center. The Easy Way To Start Auditing If you want to skip entering these four steps and configure security auditing with one command, you can use the Change Security Audit (CHGSECAUD) command for an even easier configuration on your system. For example, if I wanted to configure my system to log authorization failures, program failures, security configuration changes, and generic object management tasks, I could execute CHGSECAUD with the following parameters. CHGSECAUD QAUDCTL(*AUDLVL) QAUDLVL(*OBJMGT *SECCFG *AUTFAIL *PGMFAIL) INLJRNRCV(LIB/JRNRCVNAME) In one fell swoop, CHGSECAUD will do the following:
You can also use CHGSECAUD to check your current values and change them, if necessary. When the command comes up, it also displays your current values. And that’s it. One command configures object and user auditing on your system. To implement, make sure you read the above section to understand what you’re turning and then use CHGSECAUD to turn it on. Okay, It’s On, Now What? This week, we covered configuring security auditing on your system. In part two of this article next week, I’ll show you how to use the auditing journal entries to determine when questionable actions are taking place on your system. RELATED STORY iSeries Security Journal Receiver Management, Part 1
|
