jopdf0801-auditing-ibm.pdf
TRANSCRIPT
-
7/29/2019 jopdf0801-auditing-ibm.pdf
1/8
Many information security professionals know what to
look for when auditing a Windows machine, as they
are quite practiced at it and there are a lot of
resources that help them stay current. Although IBM System i
(the IBM midrange platform formerly known as the AS/400
and the iSeries) architecture has been around for more than 25
years, the amount of information available about how to audit
the system is scarceand not because the system is
unimportant. System i is found in just about every industry
vertical and contains some of the most critical data an
organization must protect. Credit card numbers, bank
accounts, healthcare histories, customer lists and payroll
records are all processed and stored on System i. More than
400,000 systems are estimated in production use in the loyal
install base throughout the world, and 16,000 banks run core
banking and financial applications on System i. Some of the
better-known software vendors that provide applications are
Oracle (JD Edwards ERP), Lawson/Intentia (Financials), Jack
Henry and FiServ (Core Banking), SSA (BPICS, MAPICS,
Infinium and Infor ERP applications), and Manhattan
Associates (Supply Chain).
Given the mission-critical data that are kept on the system,
maintaining a secure configuration should be a top priority.
However, many of these systems are poorly configured and
poorly managed, but are given a clean bill of health by IT
auditors. In working with companies that run System i, someerrors/problems this author has found include:
IT auditors working from old and outdated checklists, and
seeming to be unaware that a full Transmission Control
Protocol/Internet Protocol (TCP/IP) networking capability
was introduced to the system back in 1993
IT auditors unaware of new capabilities (and risks) that have
been introduced in recent versions of the operating system
IT auditors not looking for issues that are specific to System i
IT auditors mistakenly assuming that limiting command-line
access (using the limit capabilities [LMTCPB] option on
user profiles) is adequate to control access to sensitive data
(It is not.)
This article outlines the key set of controls andconfiguration settings that need to be checked in any basic
review of System i and its i5/OS operating system. In many
places, a reference is provided to the relevant i5/OS command
required to retrieve the data, or alternatively the Compliance
Assessment1 tool, which gathers all of the relevant data into
one convenient report.
A Unique Operating SystemFirst, the basic principles of the operating system should be
reviewed. i5/OS (FKA OS/400) includes an integrated
enterprise-class relational database, DB2/400. Thus, auditing the
System i environment is similar to auditing the combination of
Microsoft SQL Server running on Windows Server, or Oracle
running on a UNIX system. It is not possible to have a System i
that does not have DB2/400 running.
One of the strengths of i5/OS is that it is an object-based
(not object-oriented) architecture, which makes it extremely
resistant to viruses. In fact, viruses that can plague Windows
or UNIX operating environments have no affect on a System i
because (among other reasons) the object-based architecture
can distinguish between files and programs and refuses to
execute files.
The most common control deficiencies on the System i
occur because of the incredibly loose authority structure under
which most shops run. On the typical System i, applications
have been configured such that every user has complete
access to every object on the system (equivalent to
read/write/execute). For example, in many of the banks that
run on System i, every teller can read and modify every
account. At thousands of retail giants, every one of the users
on System i can read and use credit card numbers stored in
database tables. In healthcare environments, no one can
definitively say who has looked at or changed various pieces
of data. And, in all of these environments, although the
operating system provides basic tools to do so, no one can
produce logs that describe what has happened on the machine.
Six Keys to SecurityThis article outlines six key areas that need to be checked
in an i5/OS environment. It explains how to spot the common
exposures, why they pose a threat and how best to remediate
those problems.2
The areas that need to be investigated are:
Network access
Program, file and library security
User security
Powerful administrator (root level) privileges
System values
Logging and auditing
Network AccessPerhaps the greatest area of risk on OS/400 systems is the
unprotected access that most end users have to the system
from their desktops, laptops and mobile devices.
The Big Risk: User Access Through the Network
When version 3.1 of OS/400 was released in 1994, IBM
not only introduced a robust TCP/IP stack to the AS/400, but
also enhanced its host servers capability to allow the system
Auditing IBM AS/400 and System iBy John Earl
Copyright 2008 ISACA. All rights reserved. www.isaca.org.
JO U R N A L ON L I N E 1
-
7/29/2019 jopdf0801-auditing-ibm.pdf
2/8
to more easily exchange data with connected personal
computers (many auditors are working off checklists that have
not been updated since this time). This was widely received as
a great leap forward by all users of the machine because it
simplified the task of transferring data to and from personal
computers. However, a huge exposure was unleashed at the
same time because of the shoddy way that OS/400 objects
were secured up to that point. Prior to OS/400 release 3.1,
users were typically connected to AS/400s through fixed
function, nonprogrammable (dumb) terminals. During these
times, the favored way of protecting data from end users was
to limit their application access to a green screen menu
system. This control was coupled with the limited capability
parameter on the user ID, which prevented users from
entering commands at a standard OS/400 menu. In this way
users were easily prevented from wandering about the system
and peering into places they should not.
OS/400 Meets TCP/IP
The introduction of the TCP/IP stack changed all of this
dramatically. Users now have complete access to all of the data
because they continue to carry *CHANGE authority(equivalent to rwx) to the data and because they can use simple
tools such as File Transfer Protocol (FTP) or Microsoft Excel
(using Open Database Connectivity [ODBC] connections) to
download or upload data between their personal computing
devices and System i. Since the 1990s, IBM has shipped
System i from the factory with all TCP/IP services enabled and
ready to talk to the outside world. Few system administrators
take the time to investigate what services are open and
conversational, and even fewer understand networking well
enough to understand which services should be turned off. The
result is that nearly every i5/OS-based machine that sits on a
network is at risk of having every piece of confidential data on
that system disclosed or corrupted by any user with a valid userID and password.
Direct access to System i (iSeries) data is possible through a
Microsoft Excel Plug-in, for example, which is installed with
every copy of IBM Client Access, the most widely distributed
PC to the System i connectivity tool.
At the time that IBM enabled the TCP/IP stack on OS/400,
it also introduced exit points for various TCP/IP servers.
These exit point application programming interfaces (APIs)
allow a system administrator to attach a program to the
TCP/IP servers that will see inbound and outbound data
requests and have the ability to record, alter or even block
these transaction requests. IBM did not provide the exit
programs, but rather left it to its customers or third-partyproviders to provide these essential security services. With an
exit program attached to, for example, the FTP servers exit
point, the system administrator can now see information such
as User JOHN connected to system XYZ from remote IP
address 196.6.3.104 at 10:22 a.m. At 10:24 a.m., he sent a
request to download the Payroll file, and at 10:31 a.m., he ran
a remote command that attempted to delete his joblog.
Armed with this level of information, the system
administrator can create access rules (much like f irewall
rules) that will control which users can use which services,
what files may be accessed, and what level of logging and
alerting is desired for these transactions.
To determine if the system has exit programs attached, the
WRKREGINF and the DSPNETA commands should be used
and the servers listed in figure 2 examined. Services such as
FTP, remote command and remote SQL should be monitored
and controlled. The system administrator should be asked to
produce logs of exit point traffic, and review the access rules
that control the exit programs. Without exit programs in place,
there are no logs or alerts of any data transfer activity or
requests over FTP, remote command or ODBC.
Figure 1 lists the most important remote access servers
that can be protected by exit programs, along with a brief
description of the function provided.
To inspect whether exit programs are deployed on a
system, the WRKREGINF command is used and the list is
scanned to find the exit point servers named in figure 1. If
the Compliance Assessment tool can be used, then the display
shown in figure 2 will provide the results.
Program, File and Library SecurityNext the object-level security assigned to programs, data
files and libraries (database collections) should be reviewed.
Public Authority to Objects
One of the benefits of i5/OS is that it has an integrated
database (DB2/400) contained within the operating system.
This is one of the reasons the system earns the suffix i for
integrated.
On the downside, an integrated database also means that
every user who has a valid user ID and password to the
operating system can access the database system. If the
individual objects in the database are well secured, this is not
a problem. Unfortunately, the usual authority settings for
Figure 1Remote Access Servers That Can Be
Protected by Exit Programs
Exit Point Server Description
*DDM Alternate ODBC server
*DQSRV Client data queue server
*FILESRV Remote file serverused when drives are mappedto integrated file system
*FTPCLIENT FTP client on the iSeriesused for requestsoriginating from the System i server
*FTPSERVER FTP server on the iSeries
*NDB ODBC and JDBC native database
*RMTSRV Remote command server
*RTVOBJINF ODBC and JDBC retrieve object info
*SQL ODBC and JDBC sign-on (logon)
*SQLSRV 1 ODBC and JDBC server
*SQLSRV 2 ODBC and JDBC server
*TELNET TCP/IP terminal emulation
*DATAQSRV Remote data queue server
*FTPREXEC Remote command through FTP
*REXEC_SO Remote command sign-on (logon)
*TFRFCL Client file transfer server
JO U R N A L ON L I N E2
-
7/29/2019 jopdf0801-auditing-ibm.pdf
3/8
OS/400 objects (files, programs, etc.) are for everyone
(*PUBLIC) to have at least change (*CHANGE) rights to allparts of an application. *CHANGE access not only allows a
user to read and change the contents of a file, but also to add
or delete entries in the file and to change some of the external
properties of a file (*CHANGE is roughly equivalent to rwx
on a UNIX system). To see whether a particular system allows
too much authority to important application objects, the object
authority must be displayed. To do this, the OS/400
DSPOBJAUT command must be used. Typical syntax for this
command is:
DSPOBJAUT OBJ(Library_Name /File_Name)
OBJTYPE(*FILE)
DSPOBJAUT OBJ(Library_Name) OBJTYPE(*LIB)
The Compliance Assessment display is shown in figure 3.
Who Is *PUBLIC?It is important at this time to understand the concept of
*PUBLIC. For every object on a system, there is an explicit
authority assigned to *PUBLIC. Typical assignments are *ALL
(complete rights to the object, including object deletion rights),
*CHANGE (the rights to change the contents and outer shell of
an object), *USE (the rights to use or read the object) and
*EXCLUDE (no rights to the object). Assuming one has a
system with 800 users and there is a f ile on that system called
PAYROLL, when the DSPOBJAUT command is issued on the
PAYROLL file, the following list of users appears: JOHN: *ALL
DAN: *USE
SCOTT: *EXCLUDE
*PUBLIC: *CHANGE
In this case, John, Dan and Scott have explicit authority to
the PAYROLL file, and the other 797 users on the system are
members of the group *PUBLIC.
On most OS/400-based systems, *PUBLIC has *CHANGE
access to virtually every object on the system, and
individually specified authorities are rare. This is for two
reasons. First, the default setting (as shipped from the factory)
for newly created objects is that *PUBLIC receives
*CHANGE access. Although this authority is almost alwaystoo permissive, history and inertia have conspired to leave this
setting in place. Additionally, there are few objects that detail
individual access because setting individual object authorities
is a far too cumbersome task for most system administrators.
Studies have found that the average number of users on a
system is approximately 800. Multiply that by an estimated
20,000 to 50,000 objects on the system, and it is quickly
evident why system administrators do not typically secure
individual objects to individual users.
A well-secured System i either has all application objects
and libraries secured against public access (*PUBLIC =
Figure 2Exit Program Display
JO U R N A L ON L I N E 3
-
7/29/2019 jopdf0801-auditing-ibm.pdf
4/8
Figure 3Compliance Assessment Display
*EXCLUDE) or provides some mitigating control that
prevents users from directly accessing those objects. It is
recommended that IT auditors first check *PUBLICs access to
production libraries. Access to libraries should be restricted to
only users who have a demonstrated need. The IT auditorshould check the object authorities of some items in the library
and some of the critical applications on the system. Public
access should be set to *EXCLUDE, and individual access
should be granted where there is an appropriate business need.
Group profiles that have broad access rights to database
objects should be identifiedthis is a common back door.
This is where the previous two items come together with
potentially disastrous results. If the auditor finds that there are
no exit programs protecting network access points from client
tools such as FTP and ODBC and *PUBLIC has broad access
(*CHANGE, or worse), then the system is at critical risk of
having lost, damaged or stolen data. An exit program
remediation would be essential to quickly safeguard the data.
User SecurityAs with other platforms, organizations should maintain
adequate control over the creation and modification of user
accounts or logon identities, which are called user profiles on
i5/OS. As part of a comprehensive information systems review,the process for the creation of new user profiles on the system
should be audited. There should be adequate controls in place to
ensure that the level of privilege assigned to the new profile is
consistent with the employees job responsibility.
By default, System i assigns to new user profiles a default
password that is the same as the username. Controls should bein place to ensure that profiles are not created with default
passwords. The audit should also review the procedures for
when an employee is terminated or changes jobs.An enabled profile is an active profile that can be used to
log on to the system. A disabled profile is essentially in a
suspended state since it cannot be used to log on to the system
even if the password is known.
On Microsoft systems, security policy often enforces strongpasswords that require the use of at least one uppercase and
one lowercase letter, a number, and a special character.
Passwords are required to be changed on a regular basis.On OS/400, there is no way to force a special character
without writing custom code in a password validation exit
program. Most organizations run at password level 0 or 2,
which restricts passwords to a maximum of 10 characters in
length and uppercase letters only. Password level 3 isrecommended and requires longer, mixed-case passwords.
The full set of password-related settings (called system values
on i5/OS) that need to be checked is outlined in figure 4, alongwith recommended values. The security system values can be
viewed by typing DSPSYSVAL SYSVAL(QPWD*).
JO U R N A L ON L I N E4
-
7/29/2019 jopdf0801-auditing-ibm.pdf
5/8
Administrative Rights (Powerful Profiles)The most striking finding from the State of System i
Security Study 20073 is the large number of users that wield
special authority on the typical OS/400 system. Specialauthorities grant user prof iles system administrator, or even
root-level, privilege and essentially provide a free pass aroundthe usual authority restrictions. There are eight special
authorities on i5/OS (see figure 5), allowing for separation ofduties and a f ine level of granularity when it comes to
assigning powerful authorities.
However, as the study data show, too many users are granted
these powerful authorities, and too few managers and auditors
can see and understand how this power is used. The 2007 studyfound that the average number of users on a machine was 825,
and the average number of users wielding *ALLOBJ (the most
powerful of special authorities) was
8210 percent of the user profiles on a typical system(see figure 6). Fully 20 percent of users had *SPLCTL
special authority, and nearly 20 percent had *JOBCTL
special authority. Of the eight special authorities available to
end users, only *AUDIT was kept in any sort of check.One has to wonder if this is why all of the other settings are so
out of control.
Often programmers try to justify their need for a powerful
profile on a production system because of occasional
emergencies. Contrary to popular complaints, no one needs
these special authorities to run day-to-day business
applications. To ensure appropriate segregation of duties,
Figure 5Special Authorities on i5/OS
SpecialAuthority Name Special Authority Description
*ALLOBJ Root- or administrator-level access (very powerful)
*SECADM Security administrator (can create new user profiles)
*IOSYSCFG Network services conf iguration
*AUDIT Configuration of audit and logging settings
*SPLCTL Full access to reports and printer spool files
*SERVICE Hardware administration
*JOBCTL System operator controls
*SAVSYS Backup and restore operations
180
160
140
120
100
80
60
40
20
0
NumberofUserProfiles
Special Authorities
RootAccess(*Allobj)
SecurityAdmin.
(*Secadm)
NetworkServices
(*losyscfg)
AuditRights(*audit)
Full ReportAccess(*splctl)
HardwareAdmin.
(*services)
SystemOperator(*Jobctl)
BackupOperator(*Savsys)
Copyright 2007 The Power Tech Group, Inc.
Figure 6Special Authorities Observations
From State of System i Security Study
Figure 4Compliance Assessment User Security Tab
System Value Recommended Setting Explanation
QPWDEXPITV 90 Number of days before a password expires
QPWDLMTAJC 1 Limits adjacent digits in password. Level 1 limits to a single digit.
QPWDLMTCHR *NONE Prevents the listed characters in a password. Characters listed here would not be valid foruse in a password.
QPWDLMTREP 2 Limits repeating characters in a password. Level 2 allows repeated characters, but theycannot be consecutive.
QPWDLVL 3 Supports the more complex 128-byte upper-/lowercase pass phrases rather than the shorter,10-character, uppercase passwords
QPWDMAXLEN 128 Maximum length of password
QPWDMINLEN 6 Minimum length of password
QPWDPOSDIF 0 Limits password character positions. If 1, the same character cannot be in the relativeposition in a new password.
QPWDRQDDGT 1 Requires a digit in the password
QPWDRQDDIF A number less than or equal to 5 Number of new passwords that must be used before a previous password can be recycled.The nonintuitive values are:0=Any password can be used1=Cannot be the same as last 322=Cannot be the same as last 243=Cannot be the same as last 184=Cannot be the same as last 12
5=Cannot be the same as last 106=Cannot be the same as last 87=Cannot be the same as last 68=Cannot be the same as last 4
QPWDVLDPGM *NONE, *REGFAC or a A system exit program that sees and controls password changes. A program mayprogram name be registered that prevents the creation of weak passwords or dictionary words. Any
program registered here should be treated as very sensitive due to its ability to see anddisclose passwords.
JO U R N A L ON L I N E 5
-
7/29/2019 jopdf0801-auditing-ibm.pdf
6/8
programmers and development staff members should not have
special authorities in their profiles. These authorities are
important for system management, but one of the notable
value propositions of System i is that it can typically be
managed by fewer than a handful of administrators.
Organizations can place far more restrictions on the use of
special privileges by granting the power only on an as-needed
basis. While the user has assumed privilege, all activity
should be audited and reported on a regular basis.
System SecuritySecurity on OS/400 begins with system values. These are
the base configuration settings that are used to harden the
system and prevent security breaches.
The most important of the system values is QSECURITY,
which defines the overall security level of the operating
system itself. Although it is still a quite common setting, a
QSECURITY value of 30 indicates an unprotected operating
system with suspect integrity. There are many well-known
exposures at this QSECURITY level. IBM recommends that
all systems should be set to security level 40 or higher, and all
new systems ship with a default value of 40.
To view the security-related system values, type in the
i5/OS command: DSPSYSVAL *SEC.The checklist of OS/400 system values and their
recommended settings is provided in figure 7.
Figure 7OS/400 System Values and Their Recommended Settings
System Value Recommended Value Explanation
QSECURITY 40 or 50 Controls the level of operating system integrity. Forty is the absolute minimum acceptable level.Thirty has numerous well-known exploits. Twenty and 10 indicate that every user has root-levelprivileges.
QALWOBJRST *NONE Controls the kinds of programs that can be restored to the system. W hile the *ALWPGMADP and
ALWPTF values may be acceptable from time to time, depending on specific circumstances, thedefault value should be the more stringent *NONE.
QALWUSRDMN Shall not contain the Certain sensitive objects can facilitate breaches if they are allowed in all libraries on a system. Ifvalues *ALL or *DIR these objects are required on a system, the applications and libraries that require these objects
should be known and documented here.
QAUTOCFG 0 Controls the automatic configuration of new physical devices as soon as they are connected to thesystem. This value should be turned off (0) until there is a specific need to use it, and turnedoff after use.
QAUTORMT 0 Controls the automatic configuration of remote device controllers as soon as they are connected tothe system. This value should be turned off (0) until there is a specific need to use it, and turnedoff after use.
QAUTOVRT 0 Controls the automatic configuration of new virtual devices as soon as they are connected to thesystem. This value should be turned off (0) until there is a specific need to use it, and turned offafter use.
QCRTAUT *EXCLUDE Controls what access the general public (*PUBLIC) should automatically receive to newly createdobjects (files and programs); ships as *CHANGE
QCRTOBJAUD *ALL Controls default auditing levels for all users and objects; should be set to the widest setting possible
QDSCJOBITV No more than 240 After an inactive Telnet session times out, determines how long (in minutes) to wait before the job isended. A longer time frame is tolerable if the QINACTITV and QINACTIVMSGQ values are set properly.
QDSPSGNINF 1 Requests that information about the last successful and unsuccessful sign-on attempts be displayedto the user as he/she signs on
QFRCCVNRST Set to 3-7 Forces program conversion on restore. Set to at least three.
QINACTITV No more than 30 The number of minutes before an inactive Telnet session times out
QINACTMSGQ *DSCJOB After a Telnet session has timed out, identifies what action should be taken.This setting instructsthe system to disconnect the job but leave it active in suspended animation for the amount of timedescribed in system value QDSCJOBITV. If the same user signs onto the same device within theQDSCJOBITV value, the job resumes where it left off.
QMAXSGNACN 2 After (QMAXSIGN) number of invalid sign-on attempts, identifies what action should be taken. Two
indicates that the user ID should be disabled. A setting of three (disable user and device) is bothcounterproductive and ineffective in a TCP/IP environment.
QMAXSIGN No more than 5 Maximum number of invalid sign-on attempts before a user is subjected to the action described insystem value QMAXSGNACN
QRMTIPL 0 Level one allows the system to be IPLd (booted) remotely via a modem. Should be set to zero unlessa specific contrary reason exists.
QRMTSIGN *VERIFY When a known user attempts to log in from a remote computer, allows login after verification hasoccurred
QUSEADPAUT A named authority list Names an authority list that names the system users who are allowed to create a program thatadopts another users authority. This list of users should be small and well managed.
QVFYOBJRST 3 or 5 Verifies object signatures when objects are restored to the system
Note: Specific system values related to auditing of the system and password control settings are covered elsewhere in this article.
JO U R N A L ON L I N E6
-
7/29/2019 jopdf0801-auditing-ibm.pdf
7/8
AuditingThe security audit journal QAUDJRN is a tamperproof log
that cannot be altered or changed once an event has been written
to the journal. The journal is a free feature of i5/OS, but it must
be turned on and properly configured in order to do its job.
Configuring the Audit Journal
The following is a checklist for the audit journal:
Verify that the security audit journal exists on the system
and that the auditing is active. Simply stated, the QAUDCTL
system value defines whether auditing is active on the
system (see figure 8).
Verify the type of activity that is configured to be logged to
the system (QAUDLVL below). QAUDLVL defines what
type of events to write to the audit log once the auditing has
been turned on by specifying *AUDLVL in the QAUDCTL
setting (figure 8).
Verify that a procedure exists to report against the audit logs
on a regular basis.
Determine how long the audit data are kept on the system.
QAUDJRN data should be kept live on the system for a
minimum of one month. Save the data to tape and store them for at least a year.
A complete table of the audit-related system values is
outlined in figure 8, along with recommended settings. The
audit-related system values can be viewed using the command
DSPSYSVAL SYSVAL(QAUD*).
i5/OS also has a history log (QHST), but it is less
reliable than the QAUDJRN because it is susceptible to
tampering. Beginning with V2R3 of the operating system,
all security-related events are written to the security audit
journal, making it unnecessary to review the history log for
these events.
Log File ReportingThe IT auditor should ensure that the organization reviews
the log file report output on a regular basis. Some of the most
important reports to review are:
Changes to user profiles
Changes to system values
Invalid sign-on attempts
Authority failures
Command usage by privileged users
Auditing changes
Attempts to violate OS integrity
It is most practical to conduct regular reviews using a
commercial reporting product since the format of the audit
journal makes it difficult to read.
ConclusionIBM System i is a powerful business platform, but data are
secure only if the IT department configures the system
correctly and maintains adequate controls over the
management of the system and its applications. Information
security professionals are now becoming more aware of some
of the more important security exposures on the system, such
as the open doors through FTP and ODBC. The checklists
outlined here form a basic IS audit program for AS/400.
Endnotes1 PowerTech Compliance Assessment is a tool that information
security professionals can download at no charge from
www.powertech.com. It simplifies the task of gathering audit
data from System i. The interactive graphical report includes
references to Control Objectives for Information and relatedTechnology (COBIT) objectives, along with hyperlinks to
detailed explanations of OS/400 concepts.2 IT professionals who are looking for a more advanced and/or
automated audit program for i5/OS and System i can f ind
more detailed information at www.powertech.com.3 The State of System i Security is an annual study that
reviews aggregate audit f indings from approximately 200
systems each year. Copies are available at
www.powertech.com.
John Earl
is a an expert on OS/400 security. He has presented several
hundred security sessions at System i and securityconferences worldwide. In addition, he has educated
thousands of IT auditors on methodologies to secure and audit
the platform. Earl has more than 25 years of experience with
IBM midrange systems and security. He has published
numerous articles and columns for industry magazines, and
served as a security subject matter expert for COMMON, the
worlds largest community of IBM midrange users. He is a
three-time winner of COMMONs Speaker Excellence Award.
Figure 8Audit-related System Values and Recommended Settings
System Value Recommended Value Explanation
QAUDCTL *AUDLVL, *OBJAUD, Specifies what type of audit ing is allowed on the system. Value *NOQTEMP is permitted but not*NOQTEMP required.
QAUDENDACN *NOTIFY Specifies the action to take if journal entries cannot be recorded.A llowable values are Notify andPower Down System Immediately, which may be too harsh for most environments.
QAUDFRCLVL *SYS Controls the buffering ration of records written to the security auditing journal. *SYS (systemregulated buffering) is sufficient.
QAUDLVL *AUTFAIL, *DELETE, Specifies what types of security events should be audited. This recommended group represents a*OBJMGT, *SYSMGT, minimum standard for best practices. More settings will require more data storage, but will also*SAVRST, *SECURITY, provide a fuller picture of system activity.*SERVICE, *PGMFAIL
QAUDLVL2 Use QAUDLVL system An extension of the QAUDLVL system value; could contain some additional valuesvalue to set auditing
JO U R N A L ON L I N E 7
-
7/29/2019 jopdf0801-auditing-ibm.pdf
8/8
Authors NoteSome of the more advanced topics that were not covered in
this article because of space limitations are:
Adopted authority
Sign-on screen messages
Dedicated service tools (DST) profiles and passwords
Network attribute settings
Library lists
Printer output queues
More detailed information, beyond the scope of this
introductory article, is available in an Open Source i5/OS
Security Policy available at www.powertech.com. A free copy of
the OS/400 Compliance Assessment tool may be downloaded
from www.powertech.com.
JO U R N A L ON L I N E8
Information Systems Control Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription tothe Information Systems Control Journal.
Opinions expressed in the Information Systems Control Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the ITGovernance Institute and their committees, and from opinions endorsed by authors employers, or the editors of thisJournal. Information Systems Control Journal does not attest to the originality ofauthors' content.
2008 ISACA.All rights reserved.
Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from theassociation. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, Mass. 01970, to photocopy articlesowned by ISACA, for a flat fee of US $2.50 per article plus 25 per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article.Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expresslyprohibited.
www.isaca.org