P ower Systems running IBM i are used by some

WHITE PAPER An overview of auditing events on Power Systems running IBM i By Robin Tatam P ower Systems running IBM i are used by some of the largest and most secure organizations on the planet. They rely on security functionality supplied by IBM and third-party providers, such as PowerTech, to comply with government legislation and industry regulations. As part of compliance, it s critical that security officers and auditors have insight into the activities of application and system users. They often must conduct forensic analysis of user activities and system events in a timely and efficient manner. IBM includes powerful auditing functionality in the operating system for this purpose. DISCLAIMER: This document is for informational purposes only it is not meant as legal compliance advice. Before taking any steps that may affect your compliance status with regulatory or government mandates, always seek advice from your compliance auditor and/or legal counsel. Unfortunately, many organizations see auditing as an all-or-nothing activity and shy away from using these auditing functions. They think of audit data as consuming large amounts of expensive disk space without providing business value (at least until a security event occurs). And, large amounts of audit data can mean time-consuming review by an already over-extended IT or audit staff. The title of this white paper refers to the real world, reflecting the fact that auditing every user, every object, and every system function is not feasible for most companies. However, with planning, you can relieve the audit collection and analysis burden and manage the volume of event data. TEL USA: 253-872-7788 TOLL FREE: +1 800-915-7700 TEL UK: +44 (0)870 120 3148 Copyright 2013. PowerTech is a registered trademark of AS/400 and System i are registered trademarks of IBM. All other product and company names are trademarks of their respective holders.

Auditing Overview The auditing discussed in this white paper is event auditing. These events typically are security-related activities such as deleting objects, creating user profiles, and changing system values. (Event auditing is different than database auditing, which involves capturing before-and-after images of the database as data changes.) Audit data often is collected for use by High Availability (HA) solutions. These applications typically use audit information to detect events that should be replicated to a secondary system. There are two main considerations if you re already collecting data for HA purposes: Not all of the required security events may be captured for HA purposes. Event data often is purged after a short period of time (1 to 3 days). The IBM i audit function writes event data to a special repository, the security audit journal QAUDJRN. This tamper-proof log is in the QSYS library and funnels its entries into a journal receiver in a user-selectable library. To start security auditing in the real world, you must perform the following three steps to manage the types and volume of events collected: 1. Start system auditing. 2. Start auditing powerful or inquisitive users. 3. Start auditing sensitive objects. Getting Started Ideally, audit journal receivers should be in a standalone, secure library. This helps ensure the integrity of the journal receivers and simplifies administrative tasks. The library should be named alphabetically before QSYS to ensure that the receivers are restored before the audit journal during a system restoration. You can use the following command to create a secure library for the journal receivers: CRTLIB LIB(audjrnlib) AUT(*EXCLUDE) TEXT( Security Audit Journal Receivers ) Basic Audit Configuration The CHGSECAUD (Change Security Auditing) command creates the audit journal (if it doesn t exist), creates and attaches the first journal receiver, and sets the QAUDCTL and QAUDLVL system values. You must have *ALLOBJ and *AUDIT special authority to run this command. The following command is an example of a basic audit configuration: CHGSECAUD QAUDCTL(*AUDLVL *OBJAUD *NOQTEMP) QAUDLVL(*DFTSET) JRNRCV(audjrnlib/AUDRCV0001) The Audit Control (QAUDCTL) system value acts like an on/off switch and defines the type of auditing that occurs when the switch is on. The default value *NONE indicates that no auditing is performed. You can use the special value *ALL to select all three available values, or you can specify each value individually: *AUDLVL *OBJAUD The operating system audits events based on the QAUDLVL system value. This is system-level (all user) auditing (see the System-Level Auditing section). The operating system audits individual objects by each object s auditing attribute (see the Auditing Sensitive Objects section). *NOQTEMP Actions involving temporary objects are not audited. The operating system creates and attaches a new journal receiver whenever the threshold capacity of the current receiver is reached. The system creates the new receiver in the same library as the current receiver

and gives it an incremental name. (In our example, the next receivers names would be AUDRCV0002, AUDRCV0003, and so on.) Three other system values (not accessible through the CHGSECAUD command) further define how auditing operates: QAUDFRCLVL Auditing Force Level This value specifies how many audit records are cached before they must be written to disk. If your security policy requires all audit entries to be written to disk with no possibility of data loss, set this to zero (0). Otherwise, use the default value, *SYS, for maximum performance. QAUDENDACN Auditing End Action This value specifies the action to take if the server cannot continue auditing for any reason. Set this value with caution. The default value, *NOTIFY, sends a message to QSYSOPR (and QSYSMSG if it exists) and the system continues to function. A value of *PWRDWNSYS forces the system to power down immediately! After the system IPLs, a user with *ALLOBJ and *AUDIT authority must determine the problem, restart auditing, and bring the system out of restricted state. QCRTOBJAUD Create Object Auditing This value specifies the default object auditing value for new objects. Object creation commands allow for the desired auditing value, or defer to the object auditing value for the library where the object is created. The library may specify an absolute value or defer to the QCRTOBJAUD system value by specifying *SYSVAL. Take care if you modify this value by default, all new objects are audited, which dramatically increases the volume of audited events. System-Level Auditing System-level auditing logs events for all users, plus other events caused by non-user activity. This is the most common way to audit events, and one of the first places to look if there is too much audit data. For system-level auditing to be in effect, the QAUDCTL system value must include the value *AUDLVL. The types of events to be audited are defined in the QAUDLVL system value. (If there are too many event types to specify in QAUDLVL, include the value *AUDLVL2 and use the QAUDLVL2 system value as an extension.) Categories of System-Level Auditing In IBM i 6.1, sixteen categories of events are available for system-level auditing. Three of the values (italics) can be further divided to be more selective about the events collected. *ATNEVT *AUTFAIL *CREATE *DELETE *JOBDTA *NETCMN *OBJMGT Attention Event Authority Failure Object Creations Object Deletions Actions Affecting Jobs (*JOBxxx) Network Communications (*NETxxx) Object Management *OPTICAL Optical Drive Operations *PGMADP Program Adoptions *PGMFAIL Program Failure *PRTDTA *SAVRST Print Data Save and Restore Operations *SECURITY Security Operations (*SECxxx) *SERVICE Service Functions *SPLFDTA Spooled File Functions *SYSMGT System Management Auditing Powerful Users One of the most common security issues cited by auditors is the control and auditing of powerful users. This is an area of particular concern in IBM i, and the annual PowerTech State of IBM i Security study shows that it continues to be a risk each year. What exactly is a powerful IBM i user? Any user who can perform actions directly via a command line, or can access application programs or data via network interfaces, is powerful. This access may come from overly permissive public authority, or from private

authorities to libraries and objects. In addition, any user with command permissions and any of the eight special administrator authorities should be considered a risk. In contrast, a user who has no direct access via the network and cannot step out of the bounds of a well-designed menu and application environment, may be considered an acceptable risk. It is important to know what all powerful users such as security officers, programmers, vendors, and administrators are doing on a system. Use the CHGUSRAUD (Change User Auditing) command to audit an individual user. Although a user s audit configuration is visible through several common user profile commands, such as DSPUSRPRF, the user auditing function is configured using the CHGUSRAUD command to support separation of duties as demanded by regulatory standards such as Sarbanes-Oxley (SOX). Starting User Auditing The following is an example of how to start user auditing: CHGUSRAUD USRPRF(username) OBJAUD(*NONE, *CHANGE, or *ALL) AUDLVL(*NONE or *CMD, *CREATE, *DELETE, *JOBDTA, *OBJMGT, *OFCSRV, *PGMADP, *SAVRST, *SECURITY, *SERVICE, *SPLFDTA, *SYSMGT) The OBJAUD parameter links user auditing to object auditing. By combining these capabilities, you can audit an object only when it is accessed by an audited user. This is an effective way to reduce the volume of object auditing (see Auditing Sensitive Objects). The AUDLVL parameter specifies what type of action events to audit for this user. These are in addition to the events specified in the QAUDLVL system value. Auditing events at the system level (for all users) can generate significant amounts of audit data for users that represent little or no risk. By restricting auditing to only the profiles that can step outside an application, or can execute commands, you reduce the volume of audit entries, without compromising the audit trail. The values that can be defined in the user s AUDLVL parameter are virtually identical to those for the QAUDLVL system value. One exception is the *ATNEVT value. It s only available at the system level as part of the operating system s network Intrusion Detection System (IDS), and does not apply to individual users. The *CMD value is available only at the user level and audits any commands executed by the user. Use it for any profile that has command line privileges, especially with special authorities, or for profiles that have wide-ranging public or private authority to application objects. Auditing Sensitive Objects Most IBM i servers host tens of thousands of objects, but most applications have a much smaller set of sensitive objects. Maybe a program performs encryption and decryption for credit card data, or a database file contains payroll information. Tracking that type of program or access to that file might be invaluable if an event takes place that compromises their integrity. You can configure object auditing to occur only when a user that is being audited accesses the object. This is the recommended strategy, since auditing users whose only access is through a secured application is likely to generate data that provides little forensic value. Use the CHGOBJAUD (Change Object Auditing) command to configure object auditing. As with user auditing, the existence of a specific configuration command supports the separation of duties required by many regulatory standards. Starting Object Auditing The following is an example of how to start object auditing: CHGOBJAUD OBJ(library/object) OBJAUD(*NONE, *USRPRF, *CHANGE, or *ALL)

If an object s OBJAUD parameter is set to *USRPRF, the operating system uses the user s auditing setting. If the user s OBJAUD parameter has a value of *NONE, object access is not audited; if the value is *ALL or *CHANGE, the object is audited. A value of *CHANGE on either the object or a deferred-to user tells the operating system to record when the object is opened with the possibility of being changed. A value of *ALL on either the object or a deferredto user writes an audit entry when the object is opened with the possibility of being read or changed. This doesn t mean it actually was read or changed. And, even if it was changed, the changes typically are not visible. Many organizations consider data object auditing to have limited benefit. They prefer to use data journaling or triggers to ensure the audit trail represents the life cycle of the data. PowerTech recommends auditing highly sensitive objects, in addition to using journaling or triggers. Storing a record of the object being accessed in the security audit journal provides proof that an object was touched by a particular user at a specific date and time. What Isn t Audited? Understanding what is not audited is as important as knowing what is. Thinking that an audit trail is comprehensive when it isn t is dangerous. And, it often doesn t come to light until an event occurs and a forensic review is required. Database Changes This white paper focuses on event auditing, but any auditing discussion must mention database auditing. Many users that define object-level auditing controls think database modifications are recorded in the security audit journal. But, object auditing controls are for object open notifications only not for data-level changes. These auditing values simply indicate that an object was opened to read or change; actual data changes aren t recorded. If you need to record data changes, the recommended approach is to use the journaling functions in the database. Data changes are stored in a repository (journal and journal receiver) similar to the repository used by the audit journaling function. Database journaling can record a snapshot of application data before and after a change event occurs. This adds some performance overhead and disk space requirements, but many users find that they already have that overhead with HA (the same infrastructure can be used for auditing). One of the most powerful features of IBM i database journaling is commitment control. It ensures data integrity by allowing multiple database files to be updated as a single transaction. If a program or system ends abnormally, the database remains in a consistent state and the failed process can be restarted. (This functionality impacts application development. It requires specific directives from the program to invoke the database update when all transaction elements have been performed, or to roll back and abandon the database changes.) Another way to track database changes is to use triggers. Triggers invoke a user-written program when an event occurs on a file. The programmer of the trigger program is responsible for the action performed. Both journaling and trigger applications should be written to extract the appropriate information and store it for reporting. A commercial solution can rapidly analyze vast quantities of this stored data to identify important anomalies. (For example, a change of $10 in a salary field may not be important; a change of $10,000 probably is.) Network-Initiated Events During auditing discussions, events originating from the network commonly are overlooked. This is because modern interfaces such as FTP, ODBC, and DDM provide functionality that is often transparent to the IBM i auditing functions. Unfortunately, data access is not an auditable event, so although object-level auditing will see an object being opened, you don t get any more visibility and information. A network-initiated action

that results in an auditable event (for example, a remote command that deletes a library) is observable, but the command or action that caused that event is not. Many administrators fail to realize that the user profile command line restrictions don t carry over to every network interface. Users may access the Microsoft Windows FTP client and execute operating system commands. If their profile carries the common special authority of *JOBCTL, they could conceivably put the system into a restricted state. This is just one example, and it typically leaves no audit trail. To audit network activities, you should implement exit programs in the system s exit point registry. You can either write or purchase exit programs, and their function depends on the programmer. They are not inherently secure, but do provide access control and auditing and notification functions. Although none of the network interfaces circumvent the operating system s comprehensive object security infrastructure, the annual PowerTech State of IBM i Security study shows that the vast majority of enterprises have not implemented such an infrastructure. Even those that have are restricted by the fact that there is only one authority setting for each user/object combination. This makes it difficult to secure one interface while allowing access through another. Well-designed exit programs can eliminate this one-size-fits-all restriction. Data Retention and Archiving Some common questions about audit data include what to do with it and how long to keep it. If you created a stand-alone library to contain your audit journal receivers, you can save your secure journal library to the media of your choice. Common options are tape, DVD, and using FTP to access an alternate server for storage. If you use PowerTech s Compliance Monitor, you can harvest audit journal data onto a centralized system or partition with as much as 90% compression. After you ve saved the audit data, you can delete the journal receivers based on your archive criteria, which may depend on regulatory or legal compliance directives. Check with your audit and legal departments for retention directives, especially if you are subject to regulatory standards. That decision should not be made by IT personnel. If there are no regulatory requirements, consider storing data 30 days online and as long as possible offline. Real-Time Alert Notification You can process critical security events in real-time using PowerTech s Interact. This unique solution rapidly parses event data into an industry-standard syslog format and escalates it to virtually any enterprise SIEM (System Information and Event Manager) solution. And, Interact can forward formatted event messages to e-mail using popular message management solutions, such as Robot/CONSOLE and Robot/ALERT from Help/Systems, or MessengerPlus from Bytware. Analyzing Audit Event Data Collecting event data is the most critical step in auditing even the most powerful forensic tool can t re-create data that doesn t exist. However, you still must be able to analyze the collected data. The CPYAUDJRNE (Copy Audit Journal Entry) command lets a user with *AUDIT special authority extract event information from the security audit journal. The following example locates all the CP (change user profile) events and extracts them into an output file for further analysis: CPYAUDJRNE ENTTYP(CP) Use the first 1 through 8 characters as the prefix of the output file name, or use the default of QAUDIT. The command appends the two-digit audit journal code to complete the name. For example, this command generates a file named QAUDITCP. (The field structure of the output file created depends on the audit code being extracted.) You can use other operating system commands to process the audit journal data, but they aren t as functional as CPYAUDJRNE. The DSPJRN (Display Journal) command doesn t parse the raw data. And, IBM no longer is enhancing the DSPAUDJRNE (Display Audit Journal Entry) command to include newer audit journal codes.

Once the data is in a usable format, you should analyze it for exception-type events. These include security events such as invalid sign-on attempts and authority failures and change events such as user profile actions and system value changes. Limiting the amount of audit data collected helps reduce the work involved. However, it s a fine balance between eliminating extraneous information and omitting important events. Thus, using a program to analyze audit journal data allows for faster, more efficient review and should be strongly considered. According to the IBM Security Reference Manual (SC41-5302-10), IBM i 6.1 is capable of logging many types of entries. The most common are listed below. AF AD AP AU CA CD CO CP CQ CU CV CY DI DO DS EV GR GS IM IP IS JD JS Authorization failure. Auditing changes. Obtaining adopted authority. Attribute changes. Change authority. Command string. Create object. Change user profile. Change of *CRQD object. Cluster management operations. Connection verification. Cryptographic configuration. Directory services. Delete object. DST security password reset. Environment variable operations. Generic record. Socket descriptor was given to another job. Intrusion monitor. Interprocess communication. Internet security management. Change to a user parameter of a job description. Actions against jobs entries. KF LD ML NA ND NE OM OR OW O1 O2 O3 PA PG PO PS PW RA RJ RO RP RQ RU RZ SD SE SF SG SK SM SO ST SV VA VC VF Key ring file. Link, unlink, or lookup directory entry. Office services mail actions. Network attribute changed. Directory search filter violations. End point filter violations. Object move or rename. Object restored. Object ownership changed. (Optical access) single file or directory. (Optical access) dual file or directory. (Optical access) volume. Program changed to adopt authority. Change of an object s primary group. Printed output entries. Profile swap. Invalid password entries. Authority change during restore. Restoring job description with user profile specified. Change of object owner during restore. Restoring adopted authority program. Restoring a *CRQD object. Restoring user profile authority. Changing a primary group during restore. Changes to system distribution directory. Subsystem routing entry changed. Action on spooled files entries. Asynchronous signals. Secure sockets connections. System management changes. Server security user information actions. Use of service tools. System values changed entries. Changing an access control list. Starting or ending a connection. Closing server files.

VL VN VO VP VR VS VU VV XO X1 YC YR ZC ZR Account limit exceeded. Logging on and off the network. Validation list actions. Network password error. Network resource access. Starting or ending a server session. Changing a network profile. Changing service status. Network Authentication. Identity token. DLO object changed entries. DLO object read entries. Object changed entries. Object read entries. filtering, log management and storage, and compliance scorecards for both single system/partition and multi-system/partition environments. Network Security provides access control and critical audit capability on network-initiated activities. Providing a ring of protection to supplemental system audit and authority functions, Network Security is the leading exit point solution for IBM i. Authority Broker temporarily elevates privileges and auditing of powerful user activities. Authorized users may swap to alternate profiles in emergency scenarios to perform restricted operations, while providing notification and audit reporting capabilities for auditors and managers. Although the list might look overwhelming, you should focus just on the entries that reflect important events for your organization. The operating system provides the basic extract functionality for manual access to collected audit journal data. Real-world auditing requirements typically go beyond simply having the data. Auditors often mandate an ongoing review of the data ideally in real-time to allow for rapid response using a commercial-grade audit reporting solution. The Next Step Once your organization has discovered the value of collecting key event information, the next step is to determine the most cost-effective way to analyze and distribute the event data as information that can be used to make timely decisions. Simple queries can help extract and list audit events, but a real-world solution typically uses a commercialgrade tool to sort, filter, and translate the raw audit data into formatted information that a security team can use. PowerTech offers the perfect solution to handle the job: Compliance Monitor is a powerful audit reporting and event log analysis solution. Designed specifically to report on IBM i servers, it provides advanced Interact escalates key events events generated by the operating system and by Network Security and Authority Broker for real-time alerting. Designed to interface with most SIEM solutions, Interact sends events in an industry-standard syslog format to popular commercial message management solutions. It offloads the time and effort of manual reporting and significantly reduces incident response times. DataThread monitors databases to provide visibility into data changes and help companies meet and exceed common regulatory goals. It handles the requirement of electronic signatures, performs custom workflow, and provides change notification regardless of the interface used to make the change (including tools such as RUNSQL, DFU, and DBU). Command Security allows you to monitor and control the use of selected commands on your system. You identify the commands you want to monitor, specify the conditions under which the command should be secured, and define the actions to take when the conditions are met. For more information on PowerTech s security solution suite, visit www.powertech.com.

Conclusion IBM i contains powerful event auditing capabilities. By adding a little common sense to the process, we can balance real-world business audit requirements against the challenge of managing and analyzing large volumes of audit data. Powerful commercial solutions from PowerTech can enhance the visibility of networkinitiated activities, and transform raw audit data into useful security information. Reference Material For additional information on the auditing capability of IBM i, PowerTech recommends the following reference materials: Security Guide for IBM i V6.1 (SG24-7680-00) (Chapter 6) IBM i Security Reference Manual 7.1 (SC41-5302-11) (Chapter 9) Additional Reading To discover how other organizations measure up, download PowerTech s annual State of IBM i Security study. This study is a compilation of anonymous compliance assessment data collected throughout the year with an expert analysis of the statistics. To download the latest edition, go to www.powertech.com. About the Author Robin Tatam is Director of Security Technologies for PowerTech, a leading provider of security solutions for IBM i servers. A frequent speaker on security topics, he also co-authored the IBM RedBook System i Security - Protecting i5/os Data with Encryption. Robin can be reached by e-mail at robin.tatam@powertech.com. C041SA3