Brief: V2R3 of OS/400 delivers many new security features for the AS/400. Although some of the new functions are designed to meet government requirements, they give every AS/400 shop enhanced audit capacities. This article offers an overview of all the new capabilities, background on audit requirements and suggestions for implementing the new features.
From a security perspective, V2R3 of OS/400 represents the most significant release since the AS/400 was announced in 1988. V2R3 greatly increases your ability to provide audit information about the AS/400 with enhanced facilities which are useful to all systems. The generic reason to provide audit functions on any computer is that system administrators and auditors (e.g., outside accountants) want to monitor the activity of users. Auditing can answer questions such as:
o Which users have accessed or changed a file?
o What commands does a privileged user such as the security officer enter?
o Is there a sudden increase in password failures that may indicate the presence of a hacker?
The audit features of V2R3 record the actions of users and can provide answers to all these questions and more.
The driving force behind the new security features is a U.S. government requirement formally known as the C2 requirements of the Trusted System Evaluation Criteria. On the AS/400, C2 requires a new security level, Level 50. Unless you need to operate in a C2 security environment, use of Level 50 is not recommended because of its significant performance impact. (Level 50 reduces performance by an average of 5 to 15 percent.) For more information on Level 50 and C2 requirements, consult the "C2 Certification and Level 50" sidebar.
This article concentrates on the enhanced audit features. Audit functions make it possible to track updates and changes to data and programs without writing extensive monitoring programs. In addition, when users know that their actions are being recorded and reviewed, the audit process itself can act as a deterrent to unauthorized activity. V2R3 auditing features include new system values, new commands, new attributes in the user profile definition and a new user profile special authority, *AUDIT.
Audit Overview
V2R3 stores data in the audit journal, just as previous releases did. The audit journal provides an efficient way to record events, and data placed in the journal cannot be altered. With the addition of more audit events and object auditing capability comes the potential for a larger volume of data in the audit journal. Under V2R2, you could record all the audit events with minimal impact on system performance. In V2R3, turning on every audit option may result in a significant volume of data and potential performance impacts.
V2R3 expands the events that can be audited to include the audit of object access, the systemwide audit of events and the audit of individual users. The table in 1 shows the growth of the audit capability from V2R2 to V2R3.
V2R3 expands the events that can be audited to include the audit of object access, the systemwide audit of events and the audit of individual users. The table in Figure 1 shows the growth of the audit capability from V2R2 to V2R3.
The audit capability in V2R2 was limited to systemwide events specified in the system value QAUDLVL. V2R3 doubles the number of systemwide events that can be audited. In addition, V2R3 can audit events for an individual user profile. For example, the system can record all the CL commands entered by a specific user. User profile auditing is particularly helpful for monitoring the actions of privileged users (i.e., security officers, system administrators and service profiles).
AUDLVL (User auditing level) is a new attribute in the user profile that specifies the audit events for each user. The Change User Auditing (CHGUSRAUD) command is used to set which events to audit for each user profile. To allow for separation of security and audit duties, the Create User Profile (CRTUSRPRF) and Change User Profile (CHGUSRPRF) commands do not allow setting of the audit criteria. A user must have *AUDIT special authority (discussed in more detail later) to set the audit criteria for users and objects. 2 summarizes the events that can be audited. The values set for QAUDLVL control auditing for all users. Additional auditing can be specified for an individual user profile (e.g., the security officer) using the AUDLVL attribute of the user profile.
AUDLVL (User auditing level) is a new attribute in the user profile that specifies the audit events for each user. The Change User Auditing (CHGUSRAUD) command is used to set which events to audit for each user profile. To allow for separation of security and audit duties, the Create User Profile (CRTUSRPRF) and Change User Profile (CHGUSRPRF) commands do not allow setting of the audit criteria. A user must have *AUDIT special authority (discussed in more detail later) to set the audit criteria for users and objects. Figure 2 summarizes the events that can be audited. The values set for QAUDLVL control auditing for all users. Additional auditing can be specified for an individual user profile (e.g., the security officer) using the AUDLVL attribute of the user profile.
System Values
Five new security-related system values have been added in V2R3 and the QAUDLVL system value has been expanded.
QAUDCTL (auditing control) turns auditing on or off. The options allowed are no auditing (*NONE), object auditing (*OBJAUD) or auditing level (*AUDLVL). Both *OBJAUD and *AUDLVL may be specified simultaneously. A value of *AUDLVL activates auditing of object access based on the values specified in the QAUDLVL system value or the AUDLVL parameter of a user profile.
QAUDLVL (auditing level) controls which events are audited. This value has been expanded in V2R3 to include more systemwide events and to control auditing of user events in conjunction with the AUDLVL parameter of the user profile.
QCRTOBJAUD (create object auditing) specifies the default audit level for new objects. It works in conjunction with the CRTOBJAUD library attribute as explained in the next section.
QAUDFRCLVL (Force auditing data) determines the maximum number of audit records that can be created before the data is forced to auxiliary storage. You can specify any number from 1 to 100, or you can use the default of *SYS to let the system determine the number. The default of *SYS is recommended.
QAUDENDACN (Auditing end action) specifies the action to be taken in the event the system is unable to write an audit record. The default value of *NOTIFY sends a message to the system operator when the system is not able to write an audit record. The other choice, *PWRDWNSYS, immediately terminates operation if the system cannot write an audit record. The default of *NOTIFY is recommended.
QALWUSRDMN (allow user domain objects in libraries) is not associated with the audit function. It is a new system value created specifically to meet C2 requirements. This system value determines the libraries where user domain objects-user space (*USRSPC), user index (*USRIDX) and user queue (*USRQ)-can be created. The default of *ALL is recommended.
Object Audit
One significant V2R3 improvement is the ability to audit successful access to individual objects. Two new commands, Change Object Audit (CHGOBJAUD) and Change Document Library Object Audit (CHGDLOAUD), set the audit criteria for an object to one of the following options:
o *NONE: (Default) No audit of successful access to the object.
o *CHANGE: Audit all users who change the object.
o *ALL: Audit all users who change or reference the object.
o *USRPRF: The audit criteria depends upon the setting of the OBJAUD parameter in the user profile.
When the object indicates *USRPRF, the system determines whether or not to record audit information based on the user profile that requested the function. The user profile has a new attribute, OBJAUD (Object auditing value), that can be set to *NONE, *CHANGE or *ALL. This parameter (like the AUDLVL parameter) is set by the new command CHGUSRAUD. 3 illustrates the interaction of the object and user profile auditing criteria.
When the object indicates *USRPRF, the system determines whether or not to record audit information based on the user profile that requested the function. The user profile has a new attribute, OBJAUD (Object auditing value), that can be set to *NONE, *CHANGE or *ALL. This parameter (like the AUDLVL parameter) is set by the new command CHGUSRAUD. Figure 3 illustrates the interaction of the object and user profile auditing criteria.
The CHGOBJAUD command sets the audit criteria for existing objects. The CRTOBJAUD library attribute (new for V2R3) determines the audit criteria for new objects created in a library. The CRTOBJAUD attribute can be set to *NONE, *CHANGE, *ALL, *USRPRF or *SYSVAL. *SYSVAL determines the audit criteria for new objects in the library based on the system value QCRTOBJAUD. The default for existing libraries will be set to *SYSVAL when V2R3 is installed. The interaction of the CRTOBJAUD library attribute and the QCRTOBJAUD system value is similar to the way library attribute CRTAUT works with system value QCRTAUT to set the public authority.
*AUDIT Special Authority
With V2R3, users in the security officer (*SECOFR) user class receive a new special authority of *AUDIT. The real purpose of this authority is not to give security officers additional authority but to allow the creation of a profile for an auditor. A user with *AUDIT special authority can specify the audit criteria for objects and users as follows:
o Use the CHGUSRAUD command to set the user profile audit criteria.
o Use the CHGOBJAUD and CHGDLOAUD commands to set the object audit criteria.
o Use the Change System Value (CHGSYSVAL) command to set systemwide auditing criteria in the system values QAUDLVL, QAUDCTL, QCRTOBJAUD, QAUDENDACN and QAUDFRCLVL.
IBM introduced the *AUDIT special authority rather than expanding the role of the security administrator (*SECADM) special authority. This allows a midrange shop to separate the audit and security administration roles if desired.
The new special authority falls short of requests made by internal and external auditors. It does not allow an auditor to display the object authority and user profile information he needs. If an auditor displays the authority for an object, he will see the *PUBLIC authority but he will not see users who have more authority than *PUBLIC. An auditor cannot display the user profile of another user unless the auditor is granted access to the user profile.
As a result, under V2R3, auditors must be given *ALLOBJ authority or access to programs that adopt authority for the display of user profiles and object authorities. To eliminate this problem, IBM could expand the *AUDIT special authority to allow a user with *AUDIT special authority to display the user profile and authority for all objects. With all the enhancements implemented by IBM in V2R3, this useful change was overlooked.
Control of User Domain Objects
The C2 requirement which is the basis for most of the V2R3 security enhancements specifies that the system must be able to audit every access to an object. This requirement imposes some restrictions on the use of pointers. (A pointer is initialized when a job resolves the name of an object to an address in memory or on disk.) Most applications are not affected, but an application which attempts to save a pointer for use outside of the job will not be allowed to run on a C2 system.
When an application resolves the name of an object into a pointer, the system can produce an audit record. If an application were allowed to store a resolved pointer for future access by another job, there would be no audit record. Pointers cannot be passed to other jobs because doing so could compromise audit integrity.
The user domain objects *USRSPC, *USRIDX and *USRQ can be used to store pointers. To prevent misuse of user domain objects to store pointers and thus avoid audit, the system value QALWUSRDMN (Allow user domain objects in libraries) was added. This system value determines what libraries can be used to store user domain objects.
The default of *ALL should be used for most systems and has no impact on existing applications. In the C2 environment, the QALWUSRDMN system value must be set to QTEMP so that user domain objects are limited to the job and cannot be used to bypass the audit requirements. QALWUSRDMN can name up to 50 private libraries for storage of user domain objects. However, you should select the default of *ALL unless you operate in a C2 environment.
MI Instructions Blocked
To prevent user applications from storing or obtaining pointers to system control blocks, IBM added three machine interface (MI) instructions to the group of blocked instructions not allowed in user programs. IBM anticipates no impact on user applications as a result of this change, but MI programs are not allowed to use blocked instructions. The three machine instructions are MODS, MATOBJLK and MATAUL. These instructions are disallowed at security levels 40 and 50.
A Word of Caution
The C2 certification of the AS/400 will have little meaning for most AS/400 installations. The major value to most users who do not need C2 is the improved audit functions IBM added to V2R3 to satisfy the C2 criteria. The individual user and object audit features allow installations to record the actions of users. Use these expanded audit features with discretion; otherwise, the volume of audit data can impact system performance.
Wayne O. Evans is an AS/400 security consultant and a frequent speaker on security topics. During his 27 years with IBM Corporation, he was involved with AS/400 security design issues. Direct your security-related questions to Wayne on MC-BBS or by fax at 507-252-9615.
SIDEBAR:
C2 Certification and Level 50
Level 50 changes the way OS/400 operates to meet the requirements for a C2 certified system. Running level 50 security has an adverse performance impact on systems, so its use is not recommended. IBM indicates that Level 50 introduces a 5-15 percent CPU performance impact.
When a system runs Level 50 security, the following changes occur.
Parameter Passing. Level 50 introduces additional checks each time a user application calls any operating-system program running in system state. The system checks every parameter that is passed by the user state program. Both the values and the storage domain of the data are checked to ensure that the application does not cause OS/400 to perform operations that could compromise the integrity of the system. At Level 50, every time an application program performs an I/O operation, the system checks the passed parameters.
Messages. To guarantee the preservation of audit integrity, pointers are removed from messages sent to a user application program from another job. In addition, user applications cannot send exception messages to system programs unless the system program is a request processor or the system program invoked the user application. This change may require modification to some applications.
Internal Control Blocks. Level 50 adds extra protection to prevent modification of the system internal control blocks. RPG and COBOL programs created prior to V2R2 need to be recompiled to run under Level 50 if they use workstation files.
QTEMP Library. At Level 50, a new QTEMP library is created at the start of each job and deleted when the job terminates. At security levels below 50, the system maintains a pool of QTEMP libraries that are cleared at job termination and then assigned to another job. This has a slight impact on the job initiation performance.
At Level 50, the QTEMP library is deleted upon abnormal system termination. However, the objects in the library are not deleted. You will need to run the Reclaim Storage (RCLSTG) command more frequently. At levels below 50, the system deletes the objects stored in the QTEMP library following an abnormal termination.
Powerful Audit Functions Enhance V2R3 Security
Figure 1 Audit Function Enhancements for V2R3
Description of audit function V2R2 V2R3 Number of systemwide audit events 7 14 Number of individual user audit events 0 12 Audit of failed access to objects Yes Yes Audit of successful access to objects No Yes
Powerful Audit Functions Enhance V2R3 Security
Figure 2 Options to Audit Events
Systemwide User Profile Value QAUDLVL AUDLVL Description *NONE o o No events controlled are logged. *AUTFAIL o Authority failure events are logged. *CMD o Commands entered by user are logged. *CREATE o o Object create operations are logged. *DELETE o o Object delete operations are logged. *JOBDTA o o Job start and stop data is logged. *OBJMGT o o Object management functions such as move and rename operations are logged. *OFCSRV o o Office mail actions and changes to the system distribution directory are logged. *PGMADP o o Running programs that adopt authority are logged. *PGMFAIL o System integrity violations are logged. *PRTDTA o Printing a spooled file and sending output directly to a printer are logged. *SAVRST o o Restore operations are logged. *SECURITY o o Security-related functions are logged. *SERVICE o o Use of service tools is logged. *SPLFDTA o o Actions performed on spooled files are logged. *SYSMGT o o Use of system management functions is logged.
Powerful Audit Functions Enhance V2R3 Security
Figure 3 Object Audit Options
User Profile Settings OBJAUD(*NONE) OBJAUD(*ALL) OBJAUD(*CHANGE) OBJAUD(*NONE) no audit no audit no audit OBJAUD(*ALL) any access any access any access OBJAUD(*CHANGE) modify modify modify OBJAUD(*USRPRF) no audit any access modify
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online