Management, auditors and examiners normally expect someone to review computer system activity. Compiling programs, adding user accounts, and creating device descriptions are just three ways - among many more - to open opportunities for intentional or unintentional misuse, compromise security, or violate privacy policies. A properly-configured AS/400 or iSeries computer helps limit access by unauthorized users. But how will you know if the configuration changes?
It's true that OS/400 can be set up to record security-related events in a journal for later review, but ...
Who configures the system to record security-related events?
Who sifts through the logs (which can be quite long) looking for patterns?
A qualified computer professional could look through the logs , but the principle of segregation of duties normally dictates that someone outside the computer area have this responsibility.
Do you have the time to do all this? Softlight Auditor does!
Automatically configures OS/400 to record security-related events.
Organizes the chronological security journal into a series of logical reports.
Suppresses reporting of events you describe as normal, to allow the unusual or abnormal events to stand out.
Saves you time.
Reduces your dependence on your information services department.
Enables you to do a more thorough and regular review.
Helps you satisfy your management, auditors and examiners.
Softlight Auditor automatically sifts through the volumes of audit logs on your iSeries or AS/400 and produces a few, organized reports for you to review.
Each site is different, and your needs will determine your security policies and priorities. Knowing that, we can still offer a few suggestions for reviewing your first set of audit reports. Samples of these reports are included toward the back of this manual.
You should become familiar with your users’ sign on IDs and with the names of the libraries used on your AS/400. The IBM commands WRKUSRPRF and DSPOBJD can help you find the descriptions for users and libraries, respectively.
1. Look at the invalid user ID and password report (RPJPW1). One or two bad passwords in a short period of time probably indicates someone is “all thumbs.” Many attempts in a row probably indicate an attempt to guess someone’s password. Note: a common error is to type one’s password in the place of the user name. Since this report lists user names that failed to log in, you may wish to shred it.
2. Scan the authority failure report (RAJAFA). Repeated, failed attempts to access a payroll library, for instance, should be investigated.
3. Look at the user profile changes report (RPJCP1) to see what new users have been created, and to learn of any changes made to existing user profiles.
4. Review the programs created report (RAJCOP) to see what programs have been compiled on your system. If you have significant development activity, it is good practice to limit compiles to a development library (or set of libraries). Only tested programs are then moved to the production libraries. If your shop operates in this way, you can use the stop list feature of Softlight Auditor to keep all compiles in a named set of (development) libraries off this report. Any compiles into production libraries would then stand out.
5. Refer to the objects moved or renamed report (RPJOM1) to see any objects (including programs) moved into or out of significant libraries on your system. The stop list allows you to eliminate any routine, nightly object movement.
6. Look at the programs changed to adopt authority (RPJPA1). In particular, programs that adopt the authority of QSECOFR or other “powerful” users should be scrutinized. Also check report RPJRP1 to see if any programs created on other systems to adopt authority have been restored to your system.
What is adopted authority?
OS/400 provides a mechanism to allow a program to run with all of the authorities of the owner of the program Here is an example. User TOM may not have authority to library PAYROLL. Thus, TOM cannot run Query/400 to view data in the PAYROLL library. If management wants employees to be able to check their own sick and vacation leave balances, a program can be written to access just that information for the user who is logged in to OS/400. If the program owner has access to the PAYROLL library, and if the program is changed to adopt the authority of its owner, and if TOM has authority to run the program, then TOM can check his leave balances, but he can do nothing else in the PAYROLL library. This is a reasonable way to control access, and does not necessarily indicate a problem. Softlight Auditor, for instance, uses several programs that adopt authority to allow an auditor, who normally would not need access to system objects, to read and manage the audit journal and history log.
7. Review system value changes by referring to report RPJSV1. Note that some changes in performance-related values are made automatically by IBM’s Operational Assistant program, so you may see entries on this report that were not made from a command line.
8. Look at the system management report (RAJOR). Activity on this report will be rare in most shops, and indicates an action was taken to change such items as the System Reply List, Operational Assistant functions, or Network File Operations.
9. See if users with *SERVICE special authority used the STRSST (service tools) function to change anything on the system by looking at the RAJST report. This should be a rare occurrence and should correspond to known service activity.
For those new to the system there is a lot to learn about the AS/400 in order to do a thorough audit. However, Softlight Auditor can help you, not only by summarizing the information, but also by organizing your approach to auditing. For example, you can use the library/object stop list (discussed in the chapter on configuring Softlight Auditor) to “check off” events that you determine to be normal. Over a few months, your Softlight Auditor reports – already much smaller than the raw audit journal – will be further trimmed down to a very manageable size.