IBM 1.13.1 Security zSecure Alert User Reference Manual
IBM Security zSecure Alert 1.13.1 is a real-time monitor for z/OS systems protected with the Security Server (RACF) or CA-ACF2. It issues alerts for important events relevant to the security of the system at the time they occur. It is part of the IBM Security zSecure suite and builds on zSecure Audit.
PDF
Download
Document
Advertisement
Advertisement
Security zSecure Alert Version 1.13.1 User Reference Manual SC22-5467-00 Security zSecure Alert Version 1.13.1 User Reference Manual SC22-5467-00 Note Note Before using this information and the product it supports, read the information in “Notices” on page 123. October 2012 This edition applies to version 1, release 13, modification 1 of IBM Security zSecure Alert (product number 5655-T11) and to all subsequent releases and modifications until otherwise indicated in new editions. © Copyright IBM Corporation 2002, 2012. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents About this publication . . . . . . . . vii Intended audience . . . . . . . . . . . . vii What this publication contains . . . . . . . . vii Publications . . . . . . . . . . . . . . vii IBM Security zSecure library . . . . . . . viii Related documentation . . . . . . . . . . x Accessing terminology online. . . . . . . . x Accessing publications online. . . . . . . . x Ordering publications . . . . . . . . . . xi Licensed publications . . . . . . . . . xi Accessibility . . . . . . . . . . . . . . xi Technical training . . . . . . . . . . . . xi Support for problem solving . . . . . . . . . xi Chapter 1. Introduction . . . . . . . . 1 Chapter 2. zSecure Alert configuration . 3 Overview . . . . . . . . . . . . . . Alert activation guidelines . . . . . . . . . Configuration guidelines and performance implications . . . . . . . . . . . . . Intervals . . . . . . . . . . . . . . Buffers . . . . . . . . . . . . . . Configuring zSecure Alert . . . . . . . . . Alert configuration: managing alert configurations (SE.A.A) . . . . . . . . Alert configuration: specifying general settings Alert configuration: specifying alert destinations Alert configuration: selecting alert categories . Alert configuration: verifying alert configuration Alert configuration: refreshing the alert configuration . . . . . . . . . . . . Email address lists (SE.A.E) . . . . . . . . Installation defined alerts . . . . . . . . . Specifying the alert ID and data source . . . CARLa skeleton for existing alerts . . . . . Environment-dependent selection . . . . Alert condition . . . . . . . . . . Email layout . . . . . . . . . . . Text message layout . . . . . . . . SNMP layout . . . . . . . . . . . UNIX syslog layout. . . . . . . . . Command section . . . . . . . . . Chapter 3. Predefined alerts . 3 . 5 . . . . . 10 12 16 . 20 22 . . . . . . . . . . . . 24 25 27 28 32 33 34 35 36 36 36 37 . . . . . 39 Standard email layout . . . . . . . . . . . Predefined RACF alerts . . . . . . . . . . User alerts. . . . . . . . . . . . . . Logon by unknown user (1101) . . . . . . Logon with emergency user ID (1102) . . . Logon of a user ID with uid(0) (UNIX superuser) (1103) . . . . . . . . . . Highly authorized user revoked for password (1104) . . . . . . . . . . . . . . System authority granted (1105) . . . . . © Copyright IBM Corp. 2002, 2012 6 6 6 9 42 43 43 43 44 44 45 45 System authority removed (1106) . . . . . Group authority granted (1107) . . . . . . Group authority removed (1108) . . . . . SPECIAL authority used by non-SPECIAL user (1109). . . . . . . . . . . . . Non-OPERATIONS user accessed data set with OPERATIONS (1110) . . . . . . . Invalid password attempts exceed limit (1111) Password history flushed (1112) . . . . . Suspect password changes (1113) . . . . . Connect authority>=CREATE set (1114) . . . Too many violations (1115) . . . . . . . Data set alerts . . . . . . . . . . . . WARNING mode access on data set (1201) . . UACC>=UPDATE on a DATASET profile (1202) . . . . . . . . . . . . . . UACC>NONE on a DATASET profile (1203) Update on APF data set (1204) . . . . . . Data set added to APF list using SETPROG (1205) . . . . . . . . . . . . . . Data set removed from APF list using SETPROG (1206). . . . . . . . . . . Data set addition to APF list detected (1207) Data set addition to APF list detected (1208) General resource alerts . . . . . . . . . Catchall profile used for STC (1301) . . . . Audited program has been executed (1302) . . WARNING mode access on general resource (1303) . . . . . . . . . . . . . . UNIX alerts . . . . . . . . . . . . . UNIX file access violation (1401) . . . . . Global write specified when altering file access (1402) . . . . . . . . . . . . Global read specified when altering file access (1403) . . . . . . . . . . . . . . Extended attribute changed (1404) . . . . . Audited UNIX program has been executed (1405) . . . . . . . . . . . . . . Superuser privileged UNIX program executed (1406) . . . . . . . . . . . . . . Superuser privileged shell obtained by user (1407) . . . . . . . . . . . . . . Superuser privileges set on UNIX program (1408) . . . . . . . . . . . . . . Extended attribute changed (1409) . . . . . RACF control alerts. . . . . . . . . . . Global security countermeasure activated (1501) . . . . . . . . . . . . . . Global security countermeasure deactivated (1502) . . . . . . . . . . . . . . Global security countermeasure or option changed (1503) . . . . . . . . . . . RACF Resource class activated (1504). . . . RACF Resource class deactivated (1505) . . . System alerts . . . . . . . . . . . . . SMF data loss started (1601) . . . . . . . 46 46 47 48 48 49 50 51 51 52 53 53 54 54 55 55 56 57 57 58 58 58 59 60 60 60 61 61 62 63 64 64 65 65 65 66 66 67 67 68 68 iii SMF logging resumed after failure (1602) . . SVC definition changed (1603) . . . . . . IBM Health Checker found low severity problem (1604) . . . . . . . . . . . IBM Health Checker found medium severity problem (1605) . . . . . . . . . . . IBM Health Checker found high severity problem (1606) . . . . . . . . . . . SMF record flood detected (1607) . . . . . SMF record flood detected (1608) . . . . . Attacks blocked by filter rules are no longer logged – audit trail incomplete (1609) . . . Attacks blocked by default filter rules are no longer logged – audit trail incomplete (1610) . SMF 119 subtype is no longer written - audit trail incomplete (1611) . . . . . . . . . IP filtering support and IPSec tunnel support deactivated (1612) . . . . . . . . . . Ports below 1024 are not reserved anymore (1613) . . . . . . . . . . . . . . Interface security class changed (1614) . . . IP filter rules changed (1615) . . . . . . Group alerts . . . . . . . . . . . . . Connected to an important group (1701). . . Predefined ACF2 alerts . . . . . . . . . . User alerts. . . . . . . . . . . . . . Logon with emergency logonid (2102) . . . Highly authorized user revoked for password (2104) . . . . . . . . . . . . . . System authority granted (2105) . . . . . System authority removed (2106) . . . . . Invalid password attempts exceed limit (2111) Password history flushed (2112) . . . . . Suspect password changes (2113) . . . . . Too many violations (2115) . . . . . . . SECURITY authority used by non-SECURITY logon ID (2116) . . . . . . . . . . . NON-CNCL authority used by non-NON-CNCL logon ID (2117) . . . . . READALL authority used by non-READALL logon ID (2118) . . . . . . . . . . . Data set alerts . . . . . . . . . . . . WARNING mode access on data set (2201) . . Update on APF data set (2204) . . . . . . Data set added to APF list (2205) . . . . . Data set removed from APF list (2206) . . . Data set addition to APF list detected (2207) Data set removal from APF list detected (2208) General resource alerts . . . . . . . . . Default STC logon ID used for STC (2301) . . UNIX alerts . . . . . . . . . . . . . Superuser privileged shell obtained by user (2407) . . . . . . . . . . . . . . Extended attribute changed (2409) . . . . . ACF2 control alerts . . . . . . . . . . . Global security countermeasure added (2501) Global security countermeasure deleted (2502) Global security countermeasure changed (2503) . . . . . . . . . . . . . . System alerts . . . . . . . . . . . . . SMF data loss started (2601) . . . . . . . iv User Reference Manual 68 69 69 70 70 71 71 71 72 72 73 73 74 74 75 75 76 76 76 76 77 77 78 78 79 80 80 81 81 82 82 82 83 83 84 84 85 85 86 86 86 87 87 87 88 88 88 SMF data loss started (2602) . . . . . . SVC definition changed (2603) . . . . . IBM Health Checker found low severity problem (2604) . . . . . . . . . . IBM Health Checker found medium severity problem (2605) . . . . . . . . . . IBM Health Checker found high severity problem (2606) . . . . . . . . . . SMF record flood detected (2607) . . . . SMF record flood detected (2608) . . . . Attacks blocked by filter rules are no longer logged – audit trail incomplete (2609) . . Attacks blocked by default filter rules are no longer logged – audit trail incomplete (2610) SMF 119 subtype is no longer written - audit trail incomplete (2611) . . . . . . . . IP filtering support and IPSec tunnel support deactivated (2612) . . . . . . . . . Ports below 1024 are not reserved anymore (2613) . . . . . . . . . . . . . Interface security class changed (2614) . . IP filter rules changed (2615) . . . . . Predefined alert configuration . . . . . . . Alert definition - specify action . . . . . . Emergency user configuration (alerts 1102 and 2102) . . . . . . . . . . . . . . Revocation for excessive violations (1115) configuration . . . . . . . . . . . . Important groups (1701) configuration . . . Number of violations and logonids to exclude (2115) configuration . . . . . . . . . . 89 . 89 . 90 . 90 . 91 . 91 . 91 . 92 . 92 . 93 . 93 . . . . . 94 94 95 95 96 . 96 . 97 . 98 . 99 Chapter 4. Periodical overview . . . . 101 Chapter 5. Problem determination guide . . . . . . . . . . . . . . . 103 Information for problem diagnosis . zSecure Audit problem diagnosis . zSecure Alert problem diagnosis . General problems and abends . . . License problems . . . . . . . Expected alerts do not show up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 103 104 104 105 105 Appendix A. SNMP output . . . . . . 107 Appendix B. Tivoli Enterprise Console and NetView configuration . . . . . . 111 Configuring Tivoli Enterprise Console . . . . . Configuring NetView on AIX and Windows . . . Add a user-defined alert to an MIB . . . . . . Variables . . . . . . . . . . . . . . TRAPS . . . . . . . . . . . . . . MIB file merging . . . . . . . . . . . User-defined BAROC files with Tivoli Enterprise Console classes . . . . . . . . . . . . . Addtrap commands for AIX . . . . . . . . Addtrap commands for Windows . . . . . . 111 113 114 114 115 117 117 118 120 Notices . . . . . . . . . . . . . . 123 Trademarks . . . . . . . . . . . . . . 125 Index . . . . . . . . . . . . . . . 127 Contents v vi User Reference Manual About this publication This manual explains how to configure, use, and troubleshoot IBM Security zSecure Alert, a real-time monitor for z/OS systems protected with the Security Server (RACF) or CA-ACF2. For information about installing IBM Security zSecure Alert, see the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. Intended audience This publication is intended for the following people: v Systems support personnel responsible for configuring IBM Security zSecure Alert v Security administrators responsible for implementing the additional RACF command controls provided by IBM Security zSecure Alert. Users of this book must also be familiar with RACF and ACF2 concepts and commands. What this publication contains This publication includes the following information: v Chapter 1, “Introduction,” on page 1 introduces IBM Security zSecure Alert and explains what it does and the advantages of using it. v Chapter 2, “zSecure Alert configuration,” on page 3 explains the various alert message formats. These formats include email, text message for pagers or cell phones, WTO for automated operations, SNMP trap for network consoles, and UNIX syslog. The chapter also describes how to configure and select the predefined alerts you are interested in and how to add your own. v Chapter 3, “Predefined alerts,” on page 39 describes the predefined alerts. v Chapter 4, “Periodical overview,” on page 101 explains what you need to do to send a periodical overview. v Chapter 5, “Problem determination guide,” on page 103 explains how to diagnose and fix any problems with IBM Security zSecure Alert. v Appendix A, “SNMP output,” on page 107 describes the format of the SNMP output. v Appendix B, “Tivoli Enterprise Console and NetView configuration,” on page 111 explains how to configure IBM Tivoli Enterprise Console to properly display IBM Security zSecure Alert traps and user-defined IBM Security zSecure Alert traps, and how to configure IBM NetView on AIX for IBM Security zSecure Alert. Publications This section lists publications in the IBM Security zSecure library and related documents. The section also describes how to access and order IBM Security zSecure and other IBM Security publications online. © Copyright IBM Corp. 2002, 2012 vii IBM Security zSecure library The following documents are available in the IBM Security zSecure library: v IBM Security zSecure: Release Information For each product release, the Release Information topics provide information about new features and enhancements, incompatibility warnings, and documentation update information for the IBM Security zSecure products. You can obtain the most current version of the release information from the IBM Security zSecure Information Center at http://publib.boulder.ibm.com/ infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.zsecure.doc_1.13.1/ welcome.html. v IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide, SC22-5463-00 Provides information about installing and configuring the following IBM Security zSecure components: – IBM Security zSecure Admin – IBM Security zSecure Audit for RACF®, CA-ACF2, and CA-Top Secret – IBM Security zSecure Alert for RACF and ACF2 – IBM Security zSecure Visual for RACF – IBM Tivoli Compliance Insight Manager Enabler for z/OS v IBM Security zSecure Admin and Audit for RACF: Getting Started, GI13-2309-00 Provides a hands-on guide introducing IBM Security zSecure Admin and IBM Security zSecure Audit product features and user instructions for performing standard tasks and procedures. This manual is intended to help new users develop both a working knowledge of the basic IBM Security zSecure Admin and Audit for RACF system functionality and the ability to explore the other product features that are available. v IBM Security zSecure Admin and Audit for RACF: User Reference Manual, LC22-5464-00 Describes the product features for IBM Security zSecure Admin and IBM Security zSecure Audit. Includes user instructions to run the features from ISPF panels, RACF administration and audit user documentation with both general and advanced user reference material for the CARLa command language and the SELECT/LIST fields. This manual also provides troubleshooting resources and instructions for installing the zSecure Collect for z/OS component. This publication is only available to licensed users. v IBM Security zSecure Audit for ACF2: User Reference Manual, LC22-5465-00 Explains how to use IBM Security zSecure Audit for ACF2 for mainframe security and monitoring. For new users, the guide provides an overview and conceptual information about using ACF2 and accessing functionality from the ISPF panels. For advanced users, the manual provides detailed reference information including message and return code lists, troubleshooting tips, information about using zSecure Collect for z/OS, and details about user interface setup. This publication is only available to licensed users. v IBM Security zSecure Audit for ACF2: Getting Started, GI13-2310-00 Describes the IBM Security zSecure Audit for ACF2 product features and provides user instructions for performing standard tasks and procedures such as analyzing Logon IDs, Rules, and Global System Options, and running reports. The manual also includes a list of common terms for those not familiar with ACF2 terminology. v IBM Security zSecure Audit for Top Secret: User Reference Manual, LC22-5466-00 viii User Reference Manual v v v v v v Describes the IBM Security zSecure Audit for Top Secret product features and provides user instructions for performing standard tasks and procedures. IBM Security zSecure Alert: User Reference Manual, SC22-5467-00 Explains how to configure, use, and troubleshoot IBM Security zSecure Alert, a real-time monitor for z/OS® systems protected with the Security Server (RACF) or CA-ACF2. IBM Security zSecure Visual: Client Manual, SC22-5470-00 Explains how to set up and use the IBM Security zSecure Visual Client to perform RACF administrative tasks from the Windows-based GUI. IBM Security zSecure Command Verifier: User Guide, SC22-5471-00 Explains how to install and use IBM Security zSecure Command Verifier to protect RACF mainframe security by enforcing RACF policies as RACF commands are entered. IBM Security zSecure CICS Toolkit: User Guide, SC22-5472-00 Explains how to install and use IBM Security zSecure CICS Toolkit to provide RACF administration capabilities from the CICS® environment. IBM Security zSecure: Messages Guide, SC22-5468-00 Provides a message reference for all IBM Security zSecure components. This guide describes the message types associated with each product or feature, and lists all IBM Security zSecure product messages and errors along with their severity levels sorted by message type. This guide also provides an explanation and any additional support information for each message. IBM Security zSecure: Quick Reference, SC22-5469-00 This booklet summarizes the commands and parameters for the following IBM Security zSecure Suite components: Admin, Audit, Alert, Collect, and Command Verifier. Obsolete commands are omitted. v IBM Security zSecure: Documentation CD, LCD7-1387-12 Supplies the IBM Security zSecure Information Center, which contains the licensed and unlicensed product documentation. The IBM Security zSecure: Documentation CD is only available to licensed users. v Program Directory: IBM Security zSecure Suite CARLa-driven components, GI11-7862-07 This program directory is intended for the system programmer responsible for program installation and maintenance. It contains information concerning the material and procedures associated with the installation of IBM Security zSecure CARLa-Driven Components: Admin, Audit, Visual, Alert, and the IBM Tivoli Compliance Insight Manager Enabler for z/OS. Program directories are provided with the product tapes. You can also download the latest copy from the IBM Security zSecure Information center available at http://publib.boulder.ibm.com/ infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm.zsecure.doc_1.13.1/ welcome.htm. v Program Directory: IBM Security zSecure CICS Toolkit, GI11-7863-06 This program directory is intended for the system programmer responsible for program installation and maintenance. It contains information concerning the material and procedures associated with the installation of IBM Security zSecure CICS Toolkit. Program directories are provided with the product tapes. You can also download the latest copy from the IBM Security zSecure Information center available at http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/ index.jsp?topic=/com.ibm.zsecure.doc_1.13.1/welcome.htm. v Program Directory: IBM Security zSecure Command Verifier, GI11-7864-07 About this publication ix This program directory is intended for the system programmer responsible for program installation and maintenance. It contains information concerning the material and procedures associated with the installation of IBM Security zSecure Command Verifier. Program directories are provided with the product tapes. You can also download the latest copy from the IBM Security zSecure Information center available at http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/ index.jsp?topic=/com.ibm.zsecure.doc_1.13.1/welcome.htm. v Program Directory: IBM Security zSecure Admin RACF-Offline, GI11-8146-06 This program directory is intended for the system programmer responsible for program installation and maintenance. It contains information concerning the material and procedures associated with the installation of the IBM Security zSecure Admin RACF-Offline component of IBM Security zSecure Admin. Program directories are provided with the product tapes. You can also download the latest copy from the IBM Security zSecure Information center available at http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/ com.ibm.zsecure.doc_1.13.1/welcome.htm. Related documentation More information about RACF and the types of events that are reported through IBM Security zSecure Alert can be found in several IBM manuals. For information about incompatibilities, see the Incompatibility section under Release Information of zSecure in the IBM Information Center. You can find information about the various types of events that are recorded by RACF in the RACF Auditor's Guide. Table 1. Further information about RACF administration, auditing, programming, and commands Full title of manual Order number z/OS V1R13 Security Server RACF Command Language Ref. SA22-7687 z/OS V1R13 Security Server RACF System Administrator's Guide SA22-7683 z/OS V1R13 Security Server RACF Auditor's Guide SA22-7684 z/OS V1R13 Security Server RACF System Programmer's Guide SA22-7681 z/OS MVS System Commands SA22-7627 Accessing terminology online The IBM Terminology website consolidates the terminology from IBM product libraries in one convenient location. You can access the Terminology website at http://www.ibm.com/software/globalization/terminology. Visit the IBM® Accessibility Center at http://www.ibm.com/alphaworks/topics/ accessibility/ for more information about IBM's commitment to accessibility. Accessing publications online The IBM Security zSecure: Documentation CD contains the publications that are in the product library. The format of the publications is PDF, HTML, or both. IBM posts publications for this and all other Tivoli® products, as they become available and whenever they are updated, to the Tivoli Information Center website at http://www.ibm.com/tivoli/documentation. x User Reference Manual Note: If you print PDF documents on other than letter-sized paper, set the option in the File → Print window that allows Adobe Reader to print letter-sized pages on your local paper. Ordering publications You can order many IBM publications online at: http://www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss. You can also order by telephone by calling one of these numbers: v In the United States: 800-879-2755 v In Canada: 800-426-4968 In other countries, contact your software account representative to order IBM publications. To locate the telephone number of your local representative, perform the following steps: 1. Go to http://www.elink.ibmlink.ibm.com/publications/servlet/pbi.wss. 2. Select your country from the list and click the Arrow icon. 3. Click About this site in the main panel to see an information page that includes the telephone number of your local representative. Licensed publications Licensed publications are indicated by a publication number that starts with L (for example, LC22-5464-00). To obtain PDF or printed copies of licensed publications, send an email requesting the publication to: [email protected] Include the following information: v IBM customer number v List of publication numbers that you want to order v Preferred contact information You will be contacted for further instructions for fulfilling your order. Accessibility Accessibility features help users who have a physical disability, such as restricted mobility or limited vision, to use software products successfully. For keyboard access in the IBM Security zSecure products, standard shortcut and accelerator keys are used by the product, where applicable, and are documented by the operating system. Technical training For technical training information, see the following IBM Education website at: http://www.ibm.com/software/tivoli/education/. Support for problem solving If you have a problem with your IBM software, you want to resolve it quickly. IBM provides the following ways for you to obtain the support you need: About this publication xi Online Go to the IBM Software Support site at http://www.ibm.com/software/support/ probsub.html and follow the instructions. IBM Support Assistant The IBM Support Assistant is a free local software serviceability workbench that helps you resolve questions and problems with IBM software products. The Support Assistant provides quick access to support-related information and serviceability tools for problem determination. To install the Support Assistant software, go to http://www.ibm.com/software/ support/isa. xii User Reference Manual Chapter 1. Introduction IBM Security zSecure Alert is a real-time monitor for z/OS systems protected with the Security Server (RACF) or CA-ACF2. zSecure Alert issues alerts for important events relevant to the security of the system at the time they occur. It is part of the IBM Security zSecure suite and builds on zSecure Audit. This chapter explains the functionality of zSecure Alert in terms of its relationship to basic z/OS components and other auditing, automation, and monitoring software. The main audit log of a z/OS system is the System Management Facilities (SMF) log. This log records events for Data Facility Storage Management Subsystem (DFSMS); for example, opening a data set, z/OS UNIX System Services, network functions (VTAM, TCP/IP), RMF (performance data), JES2/JES3 (job activity, TSO sessions, started task activity, SYSIN/SYSOUT/NJE processing), the external security manager (RACF, ACF2, TSS), and other applications. Data can be extracted by post-processing the SMF log for many different purposes. Commercial software is available for various purposes including accounting and billing based on resource use, performance analysis, capacity management, and monitoring security. zSecure Audit analyzes z/OS system security for RACF or ACF2 systems, using the SMF log as primary information for the event audit reports. The traditional post-processing of SMF records has one major drawback: the time elapsed between the event and the post-processing can often be up to a day. While this drawback can be acceptable for billing and capacity management, it can pose a problem for security. If a real intrusion attempt is going on, you must respond to it right away. zSecure Alert is designed to do this job. You can deactivate part of your application or network, or collect data on the location and identity of the intruder while the trail is hot. You also know when a global security setting is changed to turn off logging for certain events to SMF. zSecure Alert is active in your system, capturing SMF data before it is written to the SMF log. It can notify you in seconds to minutes about suspicious events. In addition, zSecure Alert also captures WTOs so that you can, for example, be notified the instant the SMF log becomes full. Notifications can be sent in the following forms: v As an email v As a text message to your pager or cell phone through an e-mail-based relay v As a WTO, which can be used to trigger your automated operations package v As an SNMP trap, which can be picked up by, for example, IBM Tivoli Security Operations Manager or your network console v To the UNIX syslog zSecure Alert also supports Extended Monitoring alerts. Unlike the event-based alerts triggered by SMF and WTO events, Extended Monitoring alerts are status-based. They are triggered by changes in the status of the system and security settings. These types of alerts are based on comparing a snapshot of the current system and security settings to a snapshot of previous system and security settings. The snapshots are taken at regular, user-specified intervals. The data is compared each time a new snapshot is taken. Whenever something significant changes, an alert can be generated. This alert type can notify you of changes that occur in the system, even when those changes do not generate an SMF or WTO event. © Copyright IBM Corp. 2002, 2012 1 On RACF systems, zSecure Alert can dynamically install and activate an additional RACF exit (ICHPWX01) to create SMF records for user password changes. These SMF records are similar to the records created by the RACF PASSWORD command, but they can be recognized by a special value for the SMFUID field. You can control activation of these exits using the C2XEXITS parameter in the zSecure configuration. For more information, see the configuration information in the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. zSecure Alert consists of two components: v A long-living address space (a started task) that does the actual capturing, correlation, and alert generation. v An ISPF interface that you can use to specify which events are to be reported, and in what format. zSecure Alert comes with a set of predefined alerts described in Chapter 3, “Predefined alerts,” on page 39. You can also specify your own alerts. See the IBM Security zSecure Admin and Audit for RACF: User Reference Manual for information about the full power of the CARLa Auditing and Reporting Language (CARLa) and its great flexibility in selecting events and applying thresholds. You can also use CARLa to customize alerts by including installation-specific data such as user data or parts of the installation data held in the security database, and key-based lookups in general. The following graph presents the zSecure Alert architecture. SMF record zSecure Audit WTO console • SNMP • WTO • SMTP • UNIX syslog recent history • e-mail • cellphone • pager zSecure Alert CKFREEZE snapshots Figure 1. zSecure Alert architecture 2 User Reference Manual process output Chapter 2. zSecure Alert configuration This chapter describes the zSecure Alert configuration process. It explains the various steps to select, configure, and activate zSecure Alert in detail. The ISPF user interface used during the zSecure Alert configuration process has its own configuration. This IBM Security zSecure configuration must be completed and selected as described in the post-installation tasks section in the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. For information about zSecure Alert address space operations, see the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. Overview In the configuration process, you must specify the settings that are unique to your installation. You must specify alert conditions, the destination where you want to deliver the resulting alerts, and the alert format. You can find all this information in the Alert Configuration. If you want to work on a configuration without immediately impacting the production environment, you can create multiple Alert Configurations. By doing so, you can easily have different configurations for multiple environments or different z/OS images. In each z/OS image, only one configuration can be active at a time. In a full sysplex environment, sometimes known as a PlatinumPlex, you can use the same Alert Configuration on all z/OS images. In partial sysplex implementations, sometimes called BronzePlex or GoldPlex, you can use a different Alert Configuration for each z/OS image. After completing the Alert Configuration, you can activate the configuration. The Alert Configuration contains two types of information. v General settings that are required for the started task, such as the number and size of the data buffers. v A specification of which alert conditions you want to monitor, and how the resulting alerts can be delivered. Because zSecure Alert provides many predefined Alert Conditions, these Alert Conditions are grouped into Alert Categories. Because the alert conditions are grouped, you can configure multiple alert conditions at the same time. The following sections explain how to set options for an entire category or for individual alerts. Aside from the Alert Configurations, you can also create an email Destination. An Email Destination refers to a data set that contains email addresses. The Email Destination specifies how to interpret the data and locate the email addresses you want. Alert Configurations use several of the created Email Destinations to specify where alerts can be sent. Note: Text messages to mobile phones are also sent by email, and thus require an email address. © Copyright IBM Corp. 2002, 2012 3 Figure 2 provides an overview of the configuration of zSecure Alert. The zSecure Alert Configuration data set contains multiple Alert Configurations and zero or more Email Destination definitions. Each configuration and destination has a unique name. Note: The names of the Alert Configurations and Email Destinations can be unrelated. However, to make it easier to identify Alert Configurations and Email Destinations, create names that are short mnemonics that reflect their intended use. In the example in Figure 2, the Alert Configuration ProdA has default Email Destination TEST. Several Alert Categories and individual Alert Conditions have overriding Email Destinations. Each Email Destination defines which parts of the associated data sets contain the desired email addresses. The email address data sets are physically separate from the zSecure Alert Configuration data set. Alert Configuration data set E-mail Address data set: DSNA Alert Configuration: TestA E-mail Destination: TEST General Settings Data Definition [email protected] [email protected] [email protected] [email protected] Alert Configuration: ProdA E-mail Destination: XYZ General Settings Data Definition E-mail Address data set: DSNX [email protected] [email protected] E-mail Destination: ABC Data Definition E-mail Address data set: DSNY [email protected] Alert Configuration: ProdB General Settings Figure 2. Alert Configuration data set Alerts can be sent to various destinations. zSecure Alert currently supports the following destination types: v Email v Text message v WTO v SNMP trap v UNIX syslog 4 User Reference Manual The alert format is specified per destination type. The alerts provided with the product have a common email layout that is described in “Standard email layout” on page 42. The text message format is a shortened version of the email format for use with an e-mail-to-text-message gateway. It is displayed on a cell phone or pager. For the UNIX syslog layout, see “UNIX syslog layout” on page 36. The SNMP trap format is explained in Appendix A, “SNMP output,” on page 107. For more information about the supplied IBM-alerts, see Chapter 3, “Predefined alerts,” on page 39. For questions about configuring text messaging, contact IBM Software Support. When you add your own alerts, you can tailor the various formats to suit your needs. See “Installation defined alerts” on page 27. Alert activation guidelines An important step in configuring zSecure Alert is deciding which alert conditions to monitor and whether you want specific destinations for the alerts. For example, activating all alerts might cause the designated recipients to be flooded with emails. You can monitor only the most relevant alert conditions first, and see how much attention they demand. To assist you in selecting alert conditions, zSecure classifies all predefined alerts. See Table 5 on page 39. v Class 1 contains the Alert Conditions that are most likely to be active for a basic or Low level of vigilance. v Class 2 contains likely candidates to add for reaching a Medium level of vigilance. v Class 3 contains Alert Conditions that you must activate if you want a High level of vigilance. This classification is just a global guideline. To activate the alerts to reach a certain level of vigilance mainly depends on your security policy and the attacks you want to guard against. Monitoring possible abuse of authorization has other requirements than detecting an intrusion attempt or being alerted to a denial of service attack. For example, alert 1301 is triggered when a started task gets its user ID from a catchall profile in the STARTED class on a RACF system. Alert 2301 is triggered when a started task uses the default logon ID as specified by the GSO OPTS setting DFTSTC on an ACF2 system. Your security policy might forbid this action; in that case you can monitor it. You might, in fact, have an administrative policy in place to minimize effort in administering started tasks. In this case, activating the alert would be distracting and your vigilance level would deteriorate. You can also configure Extended Monitoring alerts. Extended Monitoring alerts are based on the detection of changes in the system. They are useful for those types of changes that are not accompanied by an SMF or WTO event record. For example, in-storage updates to certain z/OS control blocks can be detected by an appropriate Extended Monitoring alert. Such a change need not be detected by SMF-based or WTO-based alerts. Extended Monitoring alerts only detect that something has changed. They do not provide details about who made the change and how the change was made. Note: Before Extended Monitoring Alerts can be activated, the person who installs and configures zSecure Alert must perform some configuration tasks. For more Chapter 2. zSecure Alert configuration 5 information about the configuration tasks, see the zSecure Alert Post-installation tasks section in the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. During the implementation phase, consider writing specific alerts to a file instead of sending them. This practice decreases the number of alert messages that are being generated and reduces the chance that the recipient might decide to ignore all of the messages. For more information about writing alerts to a file, see “Alert configuration: managing alert configurations (SE.A.A)” on page 10. Configuration guidelines and performance implications zSecure Alert processing consists of several parts. The parameters specified at startup influence the overall performance of zSecure Alert and its impact on other users. The parameters that are specified in the general settings of each Alert Configuration are the intervals, the buffer size, and the number of buffers. Intervals There are several relevant intervals: v The reporting interval for performing data analysis and generating alerts v The stage 1 interval for reassessing the environment v The "average" interval for "moving window" analysis By default, data analysis is done every 60 seconds. This interval can be increased if you do not need almost real-time alert messages. If you need a faster response, you can reduce the interval time. Note: For each reporting interval, a new buffer is used so that this ties in with the buffer considerations explained in “Buffers.” The stage-1 preprocessing subtask obtains current information about the system environment and user attributes. This task is carried out hourly by default. For example, information about data sets and system control blocks, is collected in a CKFREEZE data set, which is refreshed once a day at the specified time. However, it is also possible to have zSecure Alert dispatch this task by the operator command MODIFY C2POLICE,COLLECT. Some "averaging" alerts with thresholds might use a time window larger than the reporting interval. For these alerts, SMF records are kept in history buffers for five times the reporting interval, for example. This long-term analysis interval can be adjusted as well, depending on your reporting needs. Buffers Another important consideration for the configuration of zSecure Alert is the in-memory buffer usage. The buffer space used by zSecure Alert is regular pageable storage in the private area of the zSecure Alert started task address space. It is similar in all aspects to the working storage of a TSO user editing a data set. As a guideline for calculating the buffer size, you can perform the following steps. Note: The numbers given in the steps are for illustration purposes only and must not be used as a starting point for your system. 1. Look at the output of your SMF dump program. Summarize the number of RACF SMF records (Record type 80) or ACF2 SMF records, and Accounting SMF records (Record type 30) written per day. 6 User Reference Manual 2. 3. 4. 5. For instance, on a small system, during an average day, the MAN data sets are switched and dumped five times. The output of the IFASMFDP program shows the following numbers of RACF or ACF2 SMF records: 50,000 32,000 69,000 49,000 and 27,000. The total number of RACF or ACF2 SMF records written during that average day is 227,000. The number of SMF 30 Records were: 19000 15000 31000 23000 and 17000. The total number of SMF 30 records during the day is 105,000. Assuming an alert reporting interval of 1 minute (the default), calculate the number of records per interval. In this example, it yields 227,000 / 1440 = 158 RACF or ACF2 records, and 105,000 / 1440 = 73 SMF-30 records per minute. Look at the output of your SMF dump program for the average record length of these SMF records. It must be 250 - 300 bytes for the RACF records, 600 - 700 bytes for ACF2 records, and 1000 - 1500 bytes for the SMF-30 records. Multiply the average number of records by the average record length to find the average buffer size per interval. In the example of the small system, it results in (158 * 274) + (73 * 1224) = 132,644 bytes. To accommodate for normal fluctuations in system workload, multiply the average found by a factor of 5, and round up to the nearest "nice" number to find the best starting point for your bufsize parameter. In the example, a good setting for the bufsize parameter is 700 KB. After determining the minimum buffer size, the next concern is about the number of buffers required. As mentioned, the minimum number of buffers is also related to your long-term event analysis. For instance, if you want to generate an alert whenever a user generates more than 10 RACF logon violations in 10 minutes, the amount of data kept in the buffers must represent at least 10 minutes. Because one buffer is always being filled with new events and therefore not available for the averaging process, the formula becomes: Numbufs > (AverageInterval / Interval) + 1 As a starting point, use twice the number of buffers based on the previous formula. So, assuming that you use the default values for Interval (60 seconds) and for AverageInterval (300 seconds), you end up with 2*((300/60)+1) = 12 buffers. Additional buffers allocated through this procedure can be used as overflow buffers for periods with high system activity. Typically, such periods do not last long. The previous example calculation allows for short periods (1 minutes or 2 minutes) where three to four times the normal amount of SMF records must be captured. In the previous examples, it is assumed that the default values for Interval, and AverageInterval are used. The main criteria for determining these parameters are the reporting requirements. For most installations, an alert response time of about 1 minute seems appropriate. It is also well in the normal response time of people to emails, or other methods of alert delivery. For the AverageInterval, the use of a 5-minute interval is sufficiently long to avoid excessive false alarms, It is also short enough to detect most situations for which alerts are wanted. You can use the following values as starting values for these OPTION and REPORT parameters: Bufsize 1024 (=1 MB) for RACF systems or 2028 (=2 MB) for ACF2 systems. Chapter 2. zSecure Alert configuration 7 This is based on the average length of an RACF or ACF2 SMF-record, the following specified interval, and an average of 40 RACF or ACF2 SMF-records per second during periods of high activity. NumBufs 12 This is based on the long-term threshold time-period (AverageInterval) and the Interval period. It also allows for an additional six overflow buffers. Interval 60 Seconds AverageInterval 300 Seconds During initial execution of zSecure Alert, monitor the in-memory buffer usage, using the DEBUG BUFFER operator or PARMLIB command. This results in three messages at the end of each Interval period. The C2P0325 and C2P0326 messages indicate how much buffer space was used for SMF-records and WTO-messages. If the amount of space for the SMF-records and WTO-records for each interval adds up to around the size calculated in step 4, the buffer space is adequate and does not need any further changes. In step 5, the buffer size was specified at five times the average expected space required. So, the buffers are expected to be used for only about 20 percent. It leaves ample space for fluctuations in system activity. Using the same numbers as used in the previous example calculation, you might expect these messages: C2P0333I Buffer index is 09 C2P0325I Buffer stats: SMF(cnt,len) 00000214-00131928 C2P0326I Buffer stats: WTO(cnt,len) 00000000-00000000 The messages confirm that your expected record rate was about right, that is, 214 records versus the expected 231, and that the average size of the records was also in the right order of magnitude, that is, 131,928 versus the expected 132,644. When activating buffer debug messages, zSecure Alert also generates a message whenever there is a need for an overflow buffer. See the following message example: C2P0334I C2P0333I C2P0325I C2P0326I C2P0333I C2P0325I C2P0326I Extended buffer used Buffer index is 02 Buffer stats: SMF(cnt,len) Buffer stats: WTO(cnt,len) Buffer index is 03 Buffer stats: SMF(cnt,len) Buffer stats: WTO(cnt,len) 00002728-01037650 00000000-00000000 00000814-00307855 00000000-00000000 These messages are issued in addition to the regular buffer usage messages. The indicated buffer '02' is the previous buffer that was overflowing into the subsequent buffer ('03'), which is shown in the regular C2P0325 and C2P0326 messages that follow. If the C2P0334 message is only issued a few times per day, the buffer size is adequate and does not need any further changes. During normal processing, a few C2P0334 messages are expected and their presence does not indicate any buffer shortage or problem. Using the steps previously outlined, you can select a minimum buffer size and number of buffers that fits your needs, without using excessive system resources. The method starts with small buffers that can be increased when needed. An 8 User Reference Manual alternative approach is to start with many large buffers, and monitoring the buffer statistics messages. After a few tests, you can decide by which amount the buffer size can be reduced. When allocating buffers, you must also consider the amount of virtual storage specified in the zSecure Alert started task JCL. The region parameter in the JCL must be at least 64 MB larger than the total buffer space specified by bufsize and numbufs. Configuring zSecure Alert About this task The zSecure Alert configuration process involves several steps, which are performed from the option SE.A on the zSecure Admin and Audit menu. If you select this option, you can see the following panel: Menu Options Info Commands Setup StartPanel ------------------------------------------------------------------------------zSecure Suite - Setup Alert Option ===> __________________________________________________________________ A E Alert E-mail Select and customize alerts Configure e-mail address lists Figure 3. zSecure Suite: Setup Alert panel for configuring zSecure Alert The zSecure Alert configuration application provides the following options. v Use Alert to configure Alert Conditions and destination of the resulting alerts. v Use Email to define how to obtain email addresses from external data sets, to avoid using hardcoded email addresses in the Alert Configuration. Procedure To configure zSecure Alert, perform the following steps: 1. Optionally, define at least one Email Destination for use in the Alert Configuration to avoid hardcoded email address specifications. You can reach this through option SE.A.E. See note 1. 2. Copy the default Alert Configuration (C2PDFL), which is provided as part of the shipped product. This step and the following ones are reached through option SE.A.A. See note 2. 3. Edit the General Settings. 4. Specify the Alert Destinations on the Alert Configuration level. 5. Select which Alert Conditions you want to monitor. During this process, you can override Destinations on the alert category level or on the individual alert level. 6. Verify the Alert Configuration. See note 3. 7. Refresh or Activate the Alert Configuration. See note 3. Results Note: 1. After completing step 1, you can use the Email Destination in the other steps. However, if you are a first time user, you can skip step 1. In that case, you cannot use Email Destinations, but you can still hardcode an email address in Chapter 2. zSecure Alert configuration 9 the Alert Configuration. In this way, you can gain experience with alert monitoring and creation. At a later stage during the zSecure Alert implementation, you can revisit the configuration process. At that time you can add the necessary Email Destinations and change the Alert Configuration to use them. 2. Step 2 on page 9 is included because the default Alert Configuration is intended to be used as a template for your own configuration. For this reason also, not all adaptations are used with the default configuration. A side effect of using the Copy command to create an Alert Configuration is that the configuration application takes you automatically to all the required configuration steps. That way, you do not need to track the steps, but complete the necessary fields. 3. Steps 6 on page 9 and 7 on page 9 are both required to make the updated Alert Configuration available for the zSecure Alert address space. In some cases, it is necessary to rerun these transactions. These cases include: v If you have been running, for a time, with a higher release of the ISPF interface, and need to perform a fallback, see the section about backing out an upgrade in the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. v In some cases, maintenance was applied to specific components of IBM Security zSecure. If so, the installer of the maintenance must notify you. The following sections describe how to perform the tasks, set up email destinations for easier maintenance, and add your own alert definitions. Alert configuration: managing alert configurations (SE.A.A) About this task To manage Alert configurations, use option SE.A.A (Alert). An Alert configuration specifies which alert conditions you want to monitor, and where and how the alerts must be sent. It also contains general parameters that are required for the zSecure Alert started task. Only one Alert configuration can be active at a time on a z/OS image. After setting the alert conditions, destinations, and parameters, you must verify the Alert configuration. The verification process ensures that the configuration is consistent and does not contain errors that prevent it from being used. The Alert configurations that have been verified can be made active. Note: Changes made to the alert configuration are not permanently saved until you leave option SE.A.A. When you select option SE.A.A (Alert), the following panel is displayed: 10 User Reference Manual Menu Options Info Commands Setup -------------------------------------------------------------------------------zSecure Suite - Setup - Alert Row 1 from 2 Command ===> ________________________________________________ Scroll ===> CSR Managing alert configurations Line commands are available depending on the configuration stage: C(opy), D(elete), I(nsert), E(dit), W(Who/Where), S(elect), V(erify), F(Refresh), B(rowse) ------------------------------------------------—-----—----—--- Configuration steps --Name Description Set Des Sel Ver Ref Act _ C2PDFL zSecure Alert default alert configurati Req Req Req Req Req _ ------------------------------------------------------------------------------_ PRODA1 Alert config for production image A1 Req Req Req Req Req _ ------------------------------------------------------------------------------******************************* Bottom of data ******************************** Figure 4. Setup Alert panel: Configuring zSecure Alert This panel provides an overview of the existing Alert configurations and shows how far configuration has proceeded. The Configuration steps show OK if a step has completed or Req if the Alert configuration requires that particular step. The Act column can show an indication that the configuration is currently active on this system. In the screen display, you must perform all configuration steps. The panel shows the following fields: Name The name of the Alert configuration. The Alert configuration name must be unique and has a maximum length of six characters. Alert configuration names with prefix C2P are reserved for IBM Security zSecure use. Several PDS/E members prefixed with this name are created by the Verify (V) and Refresh (F) line commands. For more information about the members generated during these steps, see “Alert configuration: verifying alert configuration” on page 22. Description A description for the Alert configuration. Configuration steps This group of fields indicates the steps required to complete the configuration and the order of these steps. The corresponding line commands are available only when the previous step has been completed. Initially a step is indicated as Req. After it is successfully completed, it shows OK. Perform the following steps: 1. Set: Specify the zSecure Alert parameters. The corresponding line command is E; that is, Edit general Alert configuration settings. 2. Des: Set the default Alert destination for all selected Alert conditions in this Alert configuration. Destinations can be email addresses, text message/cell phone receivers, SNMP addresses, WTO messages, and UNIX syslog. The corresponding line command is W; that is, Specify Who can receive alerts or Where alerts must be sent. 3. Sel: Select which Alert conditions you want to monitor, and optionally specify Alert destinations on the alert category or individual alert level. You can also specify your own Alert conditions. The corresponding line command is S; that is, Specify alerts and their destinations for this Alert configuration. 4. Ver: After finishing all previous steps, you must verify the Alert configuration for errors. The corresponding line command is V; that is, Verify Alert configuration. Chapter 2. zSecure Alert configuration 11 5. Ref: After successful verification, you can decide to put the verified Alert configuration in production. The Refresh command copies several PDS/E members over the existing production members. In addition, a refresh command is issued to the possibly active zSecure Alert address space in this system. This command causes the system to read its configuration members again. The corresponding line command is F; that is, Refresh production members. Note: The PARMLIB DD-statement in the started task JCL must point to your configuration data set and this alert configuration. 6. Act: A Yes in this column indicates that this Alert Configuration is the active configuration on this z/OS image. The converse is not necessarily true, because you might not have sufficient authority to issue the z/OS MODIFY command required to retrieve this information. If the name of the active started task does not match the name specified in this Alert configuration, the Act column is blank. The Alert configuration overview panel provides all Alert configuration management functions. The following table describes the line commands that are available. Some line commands are available only after the earlier configuration steps have been completed. Enter a forward slash (/) to see the currently allowed line commands. Table 2. Alert Configuration Management line commands C Copy the Alert Configuration. This action can display the general settings panel with all fields. These fields are copied from the selected Alert configuration, except for the Name field, which must be unique for each Alert configuration. I Insert a new Alert configuration. This action displays the general settings panel with all fields blank. When all required fields have been entered, the new Alert configuration is added. E Edit general settings for this Alert configuration. The corresponding configuration step is Set. D Delete the selected Alert configuration. W Set the Alert destinations on the Alert configuration level. Destinations can be email addresses, text message/cell phone destinations, SNMP addresses, WTO messages, and UNIX syslog. The corresponding configuration step is Des. S Select which Alert conditions you want to monitor, and optionally specify Alert destinations on the alert category or individual alert level. It is also possible to create your own Alert conditions. The corresponding configuration step is Sel. V Verify the Alert configuration for errors. The corresponding configuration step is Ver. F Refresh production members. The verified members are copied to production members. If the address space is active on this system, a command is issued to reprocess its production members. This is effective only if the started task JCL uses this Alert configuration. The corresponding configuration step is Ref. B Browse the general settings for this Alert configuration. Alert configuration: specifying general settings The General Settings panel is displayed when you use the E(Edit), C(Copy) or I(Insert) line command on the Alert Configuration overview panel. The main difference between the three actions is the amount of information already present in the panel. v When you Edit, all current information for the selected configuration is shown. 12 User Reference Manual v When you Copy, all information except the Name is taken from the copied configuration. v When you Insert, only default settings are entered. You must provide the additional information to make the configuration a valid one. The following screen shows the panel image that you see when using the Copy command to copy the default Alert configuration (C2PDFL). Menu Options Info Commands Setup ------------------------------------------------------------------------------zSecure Admin+Audit for RACF - Setup - Alert Command ===> Name . . . . . . . . . AHJB (also report member) Description . . . . . . zSecure Alert default alert configuration You may scroll forward/backward to view all parameters SMTP node . . . . . . . SMTP sysout . . . . . . B SMTP writer . . . . . . SMTP Interval . . . . . Environment refresh Average . . . . . . Buffer size . . . . Number of buffers . . . . . . . . . . . 60 60 300 1024 10 (in (in (in (in seconds) minutes) seconds) kilobytes) RACF database . . . . . BACKUP (PRIMARY or BACKUP) Collect started task C2PCOLL CKFREEZE data set . . . CRMA.T.DATA.SP390.C2POLICE.IOCONFIG CKFREEZE Collect time 0100 (Time of day in hhmm) Extended Monitoring . . y Snapshot retention . . 12 (Y/N) (Number of hours, 1-99) Enter / to view/edit the global CARLa skeleton Skeleton C2PSGLOB Figure 5. Setup Alert panel: Copying the default Alert Configuration You must provide the relevant information in this panel. After you complete the fields, you can use the END key (PF3) to save these settings. If you used the Copy or Insert line command to reach this panel, pressing END automatically takes you to the next step in the configuration process. Otherwise, you can return to the Alert Configuration overview panel. Note: Before you use this panel, see “Configuration guidelines and performance implications” on page 6. The General Settings panel has the following fields: Name The name of the Alert configuration. This field is required. See Name. Description A description for the Alert configuration. This field is required. SMTP node Specifies the JES destination to which emails are routed for final processing. This setting is initially taken from SETUP OUTPUT. (This option is part of the zSecure Admin and Audit interface.) When not specified on SETUP OUTPUT, a search is done for REXX SMTPNOTE to obtain the value of SMTPNODE. If the SMTP server is running on your Chapter 2. zSecure Alert configuration 13 local system, this field can be left blank. If the SMTP server is running on your local system, ask your system programmer for the correct setting. SMTP sysout Specifies the JES output class to be used for the SMTP output processing of emails. This setting is initially taken from SETUP OUTPUT. When not specified, a default of sysout class B is used. This field is required. Ask your system programmer for the correct setting. SMTP writer Specifies a name for use in SMTP when selecting an email SYSOUT data set. The external writer name is equal to the SMTP address space name. This setting is initially taken from SETUP OUTPUT. When not specified on SETUP OUTPUT, a search is done for REXX SMTPNOTE to obtain the value of SMTPJOB. This field is required. Ask your system programmer for the correct setting. Interval Specifies the reporting interval. At each interval, zSecure Alert analyzes the collected WTO and SMF records and generates alert messages. The interval also defines the frequency with which messages can be sent. A recipient gets a message for every alert subscribed, if it was triggered one or more times during the interval. The default is 60 seconds. Interval corresponds to the REPORT option INTERVAL. See the description of the Interval field in the REPORT command section of the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. Environment refresh Specifies the interval at which zSecure Alert generates the environment-dependent selection criteria (that is, analyze the RACF database and CKFREEZE file, and refresh alert definitions based on current RACF database content). The default is 60 minutes. Environment refresh corresponds to the REPORT option STAGE1INTERVAL. See the description of the PreProcessInterval or Stage1Interval field in the REPORT command section of the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. Average Specifies the time period in seconds over which zSecure Alert averages the occurrence of certain events for moving window analysis. The default is 300; that is, 5 minutes. See the description of the Number of buffers field for the relation between Average, Interval, and Number of buffers. Average corresponds to the REPORT option AVERAGEINTERVAL. See the description of the AverageInterval field in the REPORT command section of the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. Buffer size Specifies in kilobytes the size of each of the in-memory buffers used for storing WTO and SMF records during the interval period. The number must be 1 - 16384. The default is 1024; that is, 1 MB. If a buffer proves to be too small during an interval, zSecure Alert attempts to switch to an unused buffer. If no free buffer is available, the buffer with the oldest information is overlaid with current information. If the size and number of buffers is insufficient, data-loss error messages are logged. 14 User Reference Manual Buffer size corresponds to the OPTION BUFSIZE. See the description of the Bufsize field in the OPTION command section of the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. Number of buffers Specifies the number of buffers allocated. The number must be 2 - 32. The number must be sufficient to contain Average / Interval + 1 buffers. To cope with peaks in the event arrival rate, extra buffers beyond the minimum must be allocated. The extra buffers can be used in event of a buffer overflow. Number of buffers corresponds to the OPTION NUMBUFS. See the description of the Numbufs field in the OPTION command section of the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. Security database Specifies whether the PRIMARY or BACKUP security database is used to generate the environment-dependent selection criteria. Use of the PRIMARY database might be needed if you create your own alerts that use certain statistical information like the time of last user access. In all other cases, use of the BACKUP database has the least impact on other system components and provides all information used by the predefined alerts. Collect started task Specifies the name of the started task that is started by the zSecure Alert address space at CKFREEZE Collect time. This started task calls program CKFCOLL to collect environmental data. Collect started task corresponds to the OPTION COLLECTSTCNAME. See the description of the CollectSTCName field in the OPTION command section of the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. CKFREEZE data set Specifies the name of the CKFREEZE data set containing environmental data. Note: zSecure Alert does not enforce that the data set name you specify here matches the one that is specified in the Collect started task JCL. In that case, the name you specify here is only used during Verify processing of the Alert Configuration. If this data set is specified in the Collect started task, it is refreshed daily at CKFREEZE Collect time. CKFREEZE Collect time Specifies the time of day at which the Collect started task must be started. The value 0000 is used to signify that the zSecure Collect for z/OS started task must not be started at all. CKFREEZE Collect time corresponds to the OPTION COLLECTTIME. See the description of the CollectTime field in the OPTION command section of the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. Extended Monitoring This field determines whether the Extended Monitoring process is active. If you specify YES, Extended Monitoring is activated. It results in a system snapshot being taken and written to a CKFREEZE data set at the interval specified in the Environment refresh field. This option is effective only if Chapter 2. zSecure Alert configuration 15 Extended Monitoring alerts are selected. If no Extended Monitoring alerts are selected, a warning message is issued during the verification process. Snapshot retention Specifies the retention period for the Extended Monitoring snapshot data sets. Snapshot data sets older than the specified period are automatically deleted. The retention period is specified in hours. The value must be in the range 1 through 99, inclusive. The default value is 24 hours. The main reason to retain snapshot data sets is that you can analyze the details for generated alerts. Skeleton This member contains the global CARLa statements, such as ALLOCATE, DEFTYPE, and DEFINE statements. You need this option if you defined your own Alert conditions. See “Installation defined alerts” on page 27. Normally, however, you use the provided C2PSGLOB member. Alert configuration: specifying alert destinations You can select the Alert Destination panel from the W (Who/Where) line command on either the Alert Configuration overview panel or one of the alert selection panels. In this panel, you can specify where you want alerts to be sent. Using the W line command, you can specify Alert destinations separately for each of the following alert types: v An Alert configuration v An Alert category v An individual alert. This panel can be shown automatically if you use the Copy or Insert function on the Alert Configuration overview panel. It is shown after you complete the General Settings from END, or PF3. You can have alert messages sent to multiple destination types by selecting more than one destination type on this panel. Each destination type can have its own destinations. When all destination types are selected, the panel displayed looks like the following screen: 16 User Reference Manual Menu Options Info Commands Setup ------------------------------------------------------------------------------zSecure Suite - Setup - Alert Command ===> _________________________________________________________________ Select the alert destination / E-mail _ Write e-mails to C2RSMTP DD Specify e-mail recipient(s) From . . . . . . . &jobname at &system <mbox@domain>_______________ Mail to . . . . . ________________________________________________________ (You may specify : to receive a list of defined recipients :setname.fields) CC . . . . . . BCC . . . . . Reply to . . . Output format Font size / . . . . . . . . ________________________________________________________ ________________________________________________________ ________________________________________________________ 1 1. Normal (MIME/HTML) 2. Plain text (formatting may be lost) . . . . _ (number in range 1-7) Text message to cell phone _ Write text messages to C2RSMTP DD Specify text message/cell phone recipient From . . . . . . . &jobname at &system <mbox@domain>_______________ Phone@gateway . . ________________________________________________________ (You may specify : to receive a list of defined recipients :setname.fields) Reply to . . . . . ________________________________________________________ / SNMP _ Write SNMP traps to C2RSNMP DD Specify SNMP receiver address(es) (multiple addresses in parentheses, separated by a comma) Address . . . . . ________________________________________________________ / UNIX syslog Write messages to C2RSYSLG DD _ Specify UNIX SYSLOG address(es) (multiple addresses in parentheses, separated by a comma) Address(es) . . . ________________________________________________________ / WTO _ Write WTOs to C2RWTO DD _ Reset all existing destination settings for this Alert Configuration Figure 6. Setup Alert panel: Specifying destination types When your screen size is 24 x 80, you must scroll down to see all fields. The Mail to and Phone@gateway fields on this panel accept email addresses in several formats. You can specify the email addresses as: v One or more email addresses of the form [email protected] separated by commas (,). v If the email addresses are contained in a data set and the data set has no other data in it, not even line numbers, you can use //data_set_name. v If you have defined an email destination, you can refer to it from:destination-name.field-name. Chapter 2. zSecure Alert configuration 17 If you do not know the names of your email destinations, or the field names that you have used, use a single colon (:) to request information. A panel is displayed with a selection list of the defined email destinations and their defined fields. The following fields are displayed in the Email section: Email Send the alert as email. Write emails to C2RSMTP DD When both this field and email are tagged, the generated emails are not sent, but written to the C2RSMTP DD. You can use this option when you define your own alert conditions. If you are not sure how many alerts are generated, this option ensures that you are not flooding the intended recipient with alert emails. From The "From" email address. This address is added to the "From:" header. You can use the variables &jobname and &system, that is, SMF system ID, as part of the phrase, but not in quotation marks. For example, use &jobname at &system<mbox@domain>. These variables are case-sensitive. &SYSTEM, &system and &System are allowed, but no other variations. Mail to Enter the destination email address. For information about the specification of email addresses, see the information earlier in this section about "Mail to" and "Phone" specifications. CC Enter email addresses, separated by commas, for those recipients that are to receive a copy of the email. BCC Enter email addresses, separated by commas, for those recipients that are to receive a blind carbon copy of the email. These addresses are not displayed on the recipient list. Reply to The address or list of addresses to be set in the email "Reply-To" header. Output format This option can be used to specify the method that is to be used to format the report. The supported options are: Normal Use MIME/HTML email with limited HTML encoding. Plain text No special formatting is done. This means that no MIME/HTML encoding is performed. Font size This sets the HTML font size used for email. The default is 1. The HTML font size is a number in the range 1 - 7. It corresponds to 8, 10, 12, 14, 18, 24, and 26 point size if the browser default font is set at 12 point. The user can change that. The following fields are displayed in the text message section: Text message to cell phone Send the alert as a text message to a mobile phone or a pager. Write text messages to C2RSMTP DD When both this field and Text message to cell phone are tagged, the generated text message is not sent, but written to the C2RSMTP DD. You can use this option when you define your own alert conditions. If you are 18 User Reference Manual not sure how many alerts can be generated, this option ensures that you are not flooding the intended recipient with alerts. From, Reply to These fields are analogous to the From and Reply to fields in the email section. Phone@gateway The phone or text pager address as <phone number>@<gateway>. See also the field description for Mail to. The following fields are displayed in the SNMP section: SNMP Send the alert as an SNMP trap. The field SNMP destination must be specified. Write SNMP traps to C2RSNMP DD When both this field and SNMP are tagged, the generated SNMP traps are not sent, but written to the C2RSNMP DD in symbolic form; that is, the sortlist output is written, and not the actual ASCII trap. This field is meant for testing purposes. Addresses When SNMP is selected, you must use this field to specify where SNMP traps are sent. The destination can be a name (looked up by DNS), an IP address, or a list separated by commas. Each destination can be followed by a colon and a port number in decimal form. The following fields are displayed in the UNIX syslog section: UNIX syslog Send the alert to the UNIX syslog Write messages to C2RSYSLG DD When both this field and UNIX syslog are selected, the generated alert message is not sent to the UNIX syslog, but written to the C2RSYSLG DD. This field is meant for testing purposes. Addresses When UNIX syslog is selected, you must use this field to specify where alert messages are sent. The destination can be a name (looked up by DNS), an IP address, or a list separated by commas. Each destination can be followed by a colon and a port number in decimal form. The following fields are displayed in the WTO section: WTO Generate a WTO for the alert. Write WTOs to C2RWTO DD When both this field and WTO are tagged, the generated WTO is not sent to the console, but written to the C2RWTO DD. This field is meant for testing purposes. The Reset all existing destination settings for this Alert Configuration option resets all destination settings for the individual alerts. This option is available only on the Alert Configuration level. Chapter 2. zSecure Alert configuration 19 Alert configuration: selecting alert categories You can select this panel by using the S(elect) line command on an Alert configuration. This panel is shown automatically if you do Copy or Insert on the Alert Configuration overview panel. It is shown after you complete the Alert destination panel through END or PF3. Menu Options Info Commands Setup zSecure Suite - Setup - Alert Row 1 to 8 of 8 Command ===> ________________________________________________ Scroll ===> CSR Select the alert category you want to work with The following line commands are available: W(Who/Where), S(elect) ------------------------------------------------------------------------------Id Category #alerts #selected S 1 User alerts 15 0 _ 7 Group alerts 1 0 _ 2 Data set alerts 6 0 _ 3 General resource alerts 3 0 _ 4 UNIX alerts 8 8 _ 5 RACF control alerts 3 0 _ 6 System alerts 2 0 0 Other alerts 1 0 ******************************* Bottom of data ******************************** Figure 7. Setup Alert panel: Selecting Alert categories This panel shows the available Alert categories. The following fields are displayed: Id The report category ID. The second position of the alert ID is used to determine the category. Category The zSecure Alert report category. Currently, the following categories are defined: v User alerts v Group alerts (only on RACF systems) v Data set alerts v General resource alerts v UNIX alerts v RACF (or ACF2) control alerts v System alerts v Other alerts #alerts The number of defined alerts in this category. #selected The number of selected alerts in this category. You can use the W (that is, Who or Where) line command to specify a destination for all alerts in this category. Destinations set on the individual alert level for alerts in this category are then discarded. The S(elect) command displays all alerts in the category. For example, on RACF systems, the alerts display looks like the following screen: 20 User Reference Manual Menu Options Info Commands Setup _______________________________________________________________________________ zSecure Audit for RACF - Setup - Al Row 1 to 13 of 15 Command ===> ________________________________________________ Scroll ===> CSR User alerts Select the alert you want to work with. The following line commands are available: A(Preview), C(opy), D(elete), E(dit), I(nsert), W(Who/Where),S(elect), U(nselect), B(rowse) -----------------------------------------------------------------------------Alert Id Sel gECSWU CA EM _ Logon by unknown user 1101 No g U __ N _ Logon with emergency userid 1102 No g U Y N _ Logon of a userid with UID(0) (Unix superuser) 1103 No g U __ N _ Highly authorized user revoked for pwd violatio 1104 No g U __ N _ System authority granted 1105 No g U __ N _ System authority removed 1106 No g U __ N _ Group authority granted 1107 No g U __ N _ Group authority removed 1108 No g U __ N _ SPECIAL authority used by non-SPECIAL user 1109 No g U __ N _ non-OPERATIONS user accessed data set with OPER 1110 No g U __ N _ Invalid password attempts exceed limit 1111 No g U __ N _ Password history flushed 1112 No g U __ N _ Suspect password changes 1113 No g U __ N ******************************* Bottom of data ******************************* Figure 8. Setup Alert panel: Display of alerts in the selected category On ACF2 systems, the alerts display looks like the following screen: Menu Options Info Commands Setup _______________________________________________________________________________ zSecure Suite - Setup - Alert Row 1 to 11 of 11 Command ===> ________________________________________________ Scroll ===> CSR User alerts Select the alert you want to work with. The following line commands are available: A(Preview), C(opy), D(elete), E(dit), I(nsert), W(Who/Where),S(elect), U(nselect), B(rowse) ----------------------------------------------------------------------------------------------------------------------------------------------------------Alert Id Sel gECSWU CA EM _ Logon with emergency logonid 2102 Yes gE Y N _ Highly authorized user revoked for pwd violatio 2104 No gE __ N _ System authority granted 2105 No gE __ N _ System authority removed 2106 No gE __ N _ Invalid password attempts exceed limit 2111 No gE __ N _ Password history flushed 2112 No gE __ N _ Suspect password changes 2113 No gE __ N _ Too many violations 2115 No gE Y N _ non-SECURITY user accessed data set with SECURI 2116 No gE __ N _ non-NON-CNCL user accessed data set with NON-CN 2117 No gE __ N _ non-READALL user accessed data set with READALL 2118 No gE __ N ******************************* Bottom of data ******************************** Figure 9. Setup Alert panel for ACF2 systems: Display of alerts in the selected category The following fields are displayed: Alert A description of the alert. Id A numeric ID for the alert. IBM alert IDs use range 1000-1999. The range 4000-4999 is reserved for installation defined alerts. The ID is used to generate the skeleton member name, the WTO output message number, and the SNMP trap number. Sel Indicates whether this alert is selected. Chapter 2. zSecure Alert configuration 21 gECSWU The Destination Types for this alert as set with the W line command. The following values can be displayed: E email C Cell phone (text message) S SNMP trap W WTO U UNIX syslog The value can be prefixed with g, which means the destination has been set globally by the W line command on an Alert configuration. C Flag indicating whether this alert allows configuration to reflect items such as installation-specific names. When the alert is selected, a panel is displayed so that configuration can be performed. See “Predefined alert configuration” on page 95. A Flag indicating whether this alert is configured to generate an action command. EM Flag indicating whether this alert is an Extended Monitoring alert that requires activation of Extended Monitoring in the Alert Configuration general settings panel. For more information about Extended Monitoring alerts, see Chapter 1, “Introduction,” on page 1 and “Alert activation guidelines” on page 5. The following line commands are available: Table 3. Line commands available on the Alert list display A Preview CARLa code. This action displays the generated CARLa for this alert in ISPF BROWSE mode. C Copy alert. This action displays the alert definition panel with all fields. These fields are copied from the selected alert, except for the field ID, which must be unique for each alert. D Delete the selected alert. IBM Security zSecure defined alerts cannot be deleted. E Edit alert. Specify the alert characteristics such as the alert ID, record types, and CARLa code. I Insert new alert. This action displays the alert definition panel with all fields blank. When all required fields are entered, a new alert is added. W Who/Where to alert. Destinations can be email addresses, text message/cell phone receivers, SNMP addresses, UNIX syslog addresses, and WTO formats. When all destinations for an alert are cleared, the destinations of the alert category are used. If the destinations of the alert category are also not set, the destinations of the Alert Configuration are used. S Select alert. After verification and refresh of the Alert Configuration, this alert is reported. U Unselect alert. After verification and refresh of the Alert Configuration, this alert is no longer reported. B Browse Alert definition. This action displays the alert definition and also allows you to specify an action command. See “Alert definition - specify action” on page 96. See “Installation defined alerts” on page 27 for information about using the C(opy) or I(nsert) line commands to add alerts. Alert configuration: verifying alert configuration You can request verification by using the V(Verify) line command on an Alert configuration. 22 User Reference Manual This panel can be shown automatically if you do Copy or Insert on the Alert Configuration overview panel. It is shown after you complete selecting the alert conditions. Menu Options Info Commands Setup Startpanel ------------------------------------------------------------------------------zSecure Admin+Audit for RACF - Setup - Alert Command ===> Use SETUP FILES input instead of zSecure Alert input data The following selections are supported: B Browse file S Default action (for each file) V View file Enter a selection in front of a highlighted line below: AHJBVS AHJBVO AHJBV AHJBVE AHJBVP Stage one member Environment dependent selection criteria zSecure Alert report member zSecure Alert extended monitor member zSecure Alert parameter member Press Enter to start Alert set verification Figure 10. Setup Alert panel: Verifying the Alert configuration If you select the option Use SETUP FILES input instead of zSecure Alert input data, the verification process uses the SETUP FILES-selected input set instead of the security database and CKFREEZE data set configured for this alert set. Note: This option applies only to the verification function. The Alert address space always uses the security database and CKFREEZE data set as configured. After you press Enter, the same panel shows the results of the verification process. You can browse or view the members that were created by the verification process. When an error is detected during verification, the file that contains the error is highlighted in red. To view the CARLa output of the successful "Alert Generation" verification process, you can use the SYSPRINT primary command. Because no SMF and WTO records are provided during the verification process, no actual alerts are generated. The following members are created by the verification process: <configuration-name>VS The verified zSecure Alert stage1 member. This member contains the CARLa commands used to generate system-dependent CARLa selection statements used during the alert analysis. When the F line command is issued, this member is copied to member <configuration-name>S. For information about the function of the stage1 member, see the sections about the Alert address space in the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. <configuration-name>VO This member contains the environment-dependent selection criteria used during analysis and generated by the stage1 member. This member is only used by the user interface, so the zSecure Alert report member can be verified. The zSecure Alert started task writes this stage1 output to the C2P1OUT DD. Chapter 2. zSecure Alert configuration 23 <configuration-name>V The verified zSecure Alert report member. This member contains the main (primary) CARLa commands used to analyze the captured records. When the F line command is issued, this member is copied to member <configuration-name>. <configuration-name>VE The verified zSecure Alert report member for Extended Monitoring alerts. This member contains the CARLa commands used to compare the latest two CKFREEZE snapshot data sets. When the F line command is issued, this member is copied to the member <configuration-name>E. <configuration-name>VP This member contains the zSecure Alert parameters. When the F line command is issued, this member is copied to parameter member <configuration-name>P. This member is allocated by the PARMLIB DD in the started task JCL. Alert configuration: refreshing the alert configuration About this task A refresh of your alert configuration copies the verified members in the configuration data set to production members. Procedure 1. Select this panel by using the F (Refresh) line command on an Alert Configuration. This panel displays automatically if you do Copy or Insert on the Alert Configuration overview panel at the end of verification processing. During the Refresh step, the verified members in the configuration data set is copied to production members. After a successful copy, the following confirmation panel is displayed: zSecure Suite - Setup - Alert Production members generated. Use ’/’ to issue a refresh command for the current system. The selected alerts will then be reported. _ Refresh Alert started task Enter to continue Figure 11. Setup Alert panel: Refreshing the Alert configuration 2. In this panel, specify that a REFRESH command must be issued to the started task. If the JCL of the started task (PARMLIB DD-statement) is configured to use the current Alert configuration, the REFRESH command instructs the started task to reprocess the new members. 3. You can use '/' to issue an MVS MODIFY C2POLICE,REFRESH command. When you leave the Refresh panel by pressing PF3, the Alert configuration panel displays again. If all configuration steps complete successfully, the status shows OK. 24 User Reference Manual Email address lists (SE.A.E) In zSecure Alert, you can use email address lists to mail alert messages to multiple people. You can do that from direct specification of a list of comma-separated email addresses in the various panels. The email option provides an alternative approach. From the option email, you specify a data set and how email addresses are to be extracted from each record. Use the term email destination to differentiate this from the list of comma-separated email addresses. The email destination referenced by its name can be used in the Mail to field of an alert. For details, see the field description for Mail to. Note: Changes made to the alert configuration are not permanently saved until you leave option SE.A.E. If you are a first time user of zSecure Alert, you can skip this configuration step. If you later need more flexible email addresses, revisit this section and create the required email destinations. The first time you enter this option, the following panel is displayed: Note: As an example, most of the fields are already completed. Menu Options Info Commands Setup ------------------------------------------------------------------------------zSecure Suite - Setup - Alert Command ===> _________________________________________________________________ Enter zSecure Alert definition for e-mail destinations Name . . . . . . . . . SECADM Description . . . . . . Security administrator e-mail addresses Enter / to edit the e-mail destination data set / Data set name ’C2P.DATA.MAIL(SECADM)’ Field definitions Field name Start secadmin userid ______ e-mail address ______ Length||Word ______ 1 ______ 2 Delimiter ; ; Figure 12. Setup Alert panel: Specifying email destinations The panel has the following fields: Name A short descriptive name for this email destination. This field is required and must be unique. You use this name during the Alert configuration to refer to this email destination. Description A description for the email destination. This field is required. Data set name The data set containing the email addresses. It can be a sequential data set, or a partitioned data set, with the member name enclosed in parentheses: 'C2P.DATA.MAIL(SECADM)', for example. Use a partitioned data set, preferably PDS/E, because the data set is allocated (with DISP=SHR) by the zSecure Alert address space. A sequential data set requires an exclusive enqueue for edit. You would never obtain it when the started task had allocated it, and a PDS needs exclusive enqueue when you need to compress it. Chapter 2. zSecure Alert configuration 25 Any change to the member takes effect at each F C2POLICE,REFRESH and at each environment refresh interval; default is 60 minutes. Field name A field name such as e-mail address. When the data set consists of just email addresses but has line numbers, use the Start and Length fields to define the email address field. For example, for an FB 80 data set, enter 1 for Start and 72 for Length. If the data set contains other information besides the email address, you need the Field Name to identify which part of the record is the email address you want to use. During the alert configuration, you can refer to this field by specifying :destinationname.fieldname. Start Enter the numeric start position of the field. For example, enter 1 to start directly at the leftmost character. This field is used with the Length field to extract the email address from the data set. This field is mutually exclusive with the fields Word and Delimiter. Length The length of the field. This field is used with the Start field. This field is mutually exclusive with the fields Word and Delimiter. Word The sequence number of the "word" wanted. This field is used with the Delimiter field to extract the email address from the data set. This field is mutually exclusive with the fields Start and Length. Delimiter The character used to separate the words from each other. Examples are ";" or a space. This field is used with the Word field. This field is mutually exclusive with the fields Start and Length. By entering a "/" before the data set name, it is possible to view or edit the email destination set. With the data as shown in Figure 12 on page 25, the data set layout would be: File Edit Confirm Menu Utilities Compilers Test Help ------------------------------------------------------------------------------EDIT C2P.DATA.MAIL(SECADM) Columns 00001 00072 Command ===> ________________________________________________ Scroll ===> CSR ****** ***************************** Top of Data ****************************** 000001 C2PSA01;[email protected]; 000002 C2PSA02;[email protected]; 000003 C2PSA03;[email protected]; 000004 C2PSA04;[email protected]; ****** **************************** Bottom of Data **************************** Figure 13. Panel for viewing or editing the email destination set When the Email Destination has been saved by pressing END, the following panel is displayed. This panel provides an overview of the available email destinations, and enables you to manage them. In the following example, only one email destination has been defined. 26 User Reference Manual Menu Options Info Commands Setup ------------------------------------------------------------------------------zSecure Suite - Setup - Alert Row 1 from 6 Command ===> ________________________________________________ Scroll ===> CSR CKRM839 E-mail destination added Select Alert e-mail destination The following line commands are available: B(rowse), C(opy), D(elete), E(dit set), I(nsert), S(elect), V(iew) ------------------------------------------------------------------------------Set name Description Data set name _ SECADM Security administrator e-mail addresses ’C2P.DATA.MAIL(SECADM)’ ------------------------------------------------------------------------------******************************* Bottom of data ******************************** Figure 14. Setup Alert panel: Save Confirmation message for email destination update The following line commands can be used on the email destination set overview panel: Table 4. Line commands available on the email destination set overview panel Line Command Description / Display a popup panel showing the available line commands. C Copy the Email Destination. This action displays the definition panel as shown in Figure 12 on page 25 with all fields. These fields are copied from the selected Email Destination, except for the field Name, which must be unique for each Email Destination. D Delete the Email Destination. This action does not affect any associated data set. I Insert a new Email Destination. This action displays the definition panel with all fields blank. S Select the General Settings for this Email Destination for modification. B Browse the data set with the ISPF BROWSE service. E Edit the data set with the ISPF EDIT service, so email addresses can be modified. V View the data set with the ISPF VIEW service. Installation defined alerts New alerts can be created by copying and adapting an existing alert or by creating an alert from scratch. The specification of an alert is largely done by a number of CARLa code sections in a skeleton member. This skeleton member is used during the Verify operation to create the actual CARLa to be passed to the zSecure Alert engine. In general, it requires advanced CARLa coding skills. This knowledge is assumed throughout this section. See theIBM Security zSecure Admin and Audit for RACF: User Reference Manual for details. When creating an alert, you must decide on the following items: v The alert ID. This four-digit number serves as an identifier and is always prominently present. IBM-supplied alerts have alert numbers 1000-1999 (RACF), 2000-2999 (ACF2), and 3000-3999 (TSS). The ranges 4000-4999 (RACF), 5000-5999 Chapter 2. zSecure Alert configuration 27 (ACF2), and 6000-6999 (TSS) are reserved for installation-defined alerts. The second digit of this number assigns the alert to an Alert Category. v The event that you want to trigger your alert. v How to format relevant data from the Alert condition into your alert. v Whether your alert is customizable. For instance, your alert might need a list of data sets or user IDs. You want to maintain this list without the need to edit the skeletons each time. If you want your alert to be customizable, you must have a panel to allow customizing it. It is up to you how the panel looks and which parameters it accepts to customize your alert. You can create a panel from scratch, or you can use, copy, or clone a standard zSecure panel that fits your requirements. If you need a panel of your own, you must store it in a library of your own. You must use the UPREFIX/WPREFIX zSecure configuration parameters to make that library available to ISPF. See IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide for the UPREFIX/WPREFIX parameters. To supply your skeletons with the parameters they need to generate the CARLa for your alert, you must assign the names of these parameters to a variable named EXTVAR; that is: &extvar='c2peeus0,c2peeus1,c2peeus2,c2peeus3,c2peeus4' The format in which an alert is to be sent is specified per Destination Type. There are the following Destination types: v Email v Text message v WTO v SNMP trap v UNIX syslog The email format is the most descriptive. The alerts provided with the product have a common layout, described in “Standard email layout” on page 42. The emails are sent in HTML format. The text message format in all IBM Security zSecure-supplied alerts is a shortened version of the email format for use with an e-mail-to-text-message gateway where the recipient (for example, cell phone or pager) is specified in the "To" header of the email message. The text message itself can be taken from the subject or the body of the email, depending on the gateway. The subject and body as sent are therefore similar, though the body can contain a little more information. The WTO format can be used with automated operation software. The SNMP trap format can be used with IBM Tivoli Compliance Insight Manager or Tivoli Security Information and Event Manager or your network console. For more description of this format, see Appendix A, “SNMP output,” on page 107. Specifying the alert ID and data source Procedure Follow these steps to create an alert: 1. To create an alert, go to the option SE.A.A and select the Alert Configuration you want to work with. 2. In the Alert Category panel, select any category; for example System alerts. 28 User Reference Manual The category to which the new alert belongs is determined by its second digit, and not by which category you use to create it. Menu Options Info Commands Setup ------------------------------------------------------------------------------zSecure Suite - Setup - Alert Row 1 to 1 of 1 Command ===> ________________________________________________ Scroll ===> CSR System alerts Select the alert you want to work with. The following line commands are available: A(Preview), C(opy), D(elete), E(dit), I(nsert), W(Who/Where), S(elect), U(nselect), B(rowse) -----------------------------------------------------------------------------Alert Id Sel gECSW C EM I SMF data loss started 1601 Yes gE W N _ SMF logging resumed after failure 1602 Yes gE W N _ SVC definition changed 1603 No gE W Y ******************************* Bottom of data ******************************** Figure 15. Setup Alert panel: Specifying Alert ID and data source for custom Alerts 3. You can create an alert by issuing the C(Copy) or I(Insert) line command. The Copy command copies all fields except the Alert Id. The following panel is displayed after issuing the I line command: Menu Options Info Commands Setup ------------------------------------------------------------------------------zSecure Admin+Audit for RACF - Setup - Alert Command ===> Description . . Member prefix Alert id. . . . Data source . . SMF Parameters . . . Panel name . . . Severity. . . . (I, W, E or S) (Panel for additional customization) Specify SMF records to be collected for this alert Type Sub Type Sub Type Sub Type Sub Type Sub ____ ___ ____ ___ ____ ___ ____ ___ ____ ___ Specify WTO filters for this alert Prefix Prefix Prefix Prefix Prefix Allowable destination types E-mail Cellphone _ UNIX syslog _ Specify action . . . . . . . N (Y/N) Extended Monitoring alert . . (Y/N) View/edit the alert skeleton ISPF Skeleton SNMP WTO Action command Figure 16. Setup Alert panel: Adding an Alert The following fields are displayed: Description A description of the alert. Member prefix A three-character prefix for the skeleton member. The generated name of the skeleton member is: <Member prefix>S<Alert id>. The three-character prefix must start with a letter or "@", "#", or "$", and not with a numeric digit. Prefix C2P is reserved for IBM Security zSecure use. Chapter 2. zSecure Alert configuration 29 Alert id A numeric ID for the alert. IBM alert IDs use ranges 1000-1999 (RACF), 2000-2999 (ACF2), and 3000-3999 (TSS). The ranges 4000-4999 (RACF), 5000-5999 (ACF2), and 6000-6999 (TSS) are reserved for installation defined alerts. The second digit determines the Alert category. The ID is used to generate the skeleton member name. When WTO is selected as a Destination type, the value is also used to populate the <Alert id> field in the message ID: C2P<Alert id><Severity>. Severity A severity for the alert. When WTO is selected as a Destination type, this value is used to populate the <Severity> field in the message ID: C2P<Alert id><Severity> The following list shows the valid severities: I Information. Action is not required. W Attention. Action might be required. E Error. Action is required. S Severe error. Action is required urgently. For alerts with destination type UNIX, these severities are translated as shown in the following list: Severity Priority I 117 W 116 E 115 S 114 Data source The data source of CARLa newlist type for the alert, SMF or WTO for example. Parameters This field is intended to pass additional parameters to the generated NEWLIST statement. For Extended Monitoring alerts, the required COMPAREOPT=<compareopt-name> must be entered in this field. Panel name If you want your new alert to be customizable, specify the name of the customizing panel in this field. The panel you specify must exist and be accessible, either as a standard zSecure panel if there is one that fits your requirements, or as a panel that you created yourself. This panel is shown as the next transaction during creation of the new alert. It can also be used for future configuration of this alert. 30 User Reference Manual Type If the data source is SMF: the SMF record type that must be collected for this alert. To collect ACF2 records, you can specify the pseudo-type ACF2. The zSecure Alert program looks up the correct record type from the ACF2 control blocks. Sub Specifies the SMF-record subtype that must be collected. The subtype is only used for SMF-record types 30, 80, and ACF2 records. For all other SMF-record types, the subtype is ignored. The subtype is interpreted as follows: Rectype 30 The subtype is the standard SMF-record subtype. Rectype 80 The subtype is the RACF event code. For a complete list of RACF event codes, see the RACF Auditor's guide. Rectype ACF2 See IBM Security zSecure Audit for ACF2: User Reference Manual for a complete list of ACF2 subtypes. Prefix If the data source is WTO: specifies which message prefixes must be collected. Allowable destination types Select the Destination Types for which reports can be generated by this alert. The alert skeleton must have a section for each Destination Type selected. Specify action Select Y to specify an action command for this alert. See “Alert definition - specify action” on page 96. Extended Monitoring alert This field specifies whether the alert is an Extended Monitoring alert. Specify Y if it is an Extended Monitoring alert that compares the current and previous CKFREEZE snapshot data sets. Specify N if it is an Event-based alert. Ensure that the Data Source field specifies the correct value to match the Extended Monitoring setting. For event-based alerts, the Data Source field must have the value SMF or WTO. For Extended Monitoring alerts, the Data Source field can have the value of any supported CKFREEZE-based NEWLIST type. See “Alert activation guidelines” on page 5 for more information about Extended Monitoring alerts. ISPF Skeleton Type a forward slash (/) in this field to edit the ISPF skeleton for this alert. The skeleton contains the CARLa code to specify the Alert Condition, the alert contents, and the alert layout. When you add an alert using the Copy command, the skeleton of the source alert is copied; otherwise a model skeleton is used. If the skeleton exists, it is not changed. For Extended Monitoring alerts, only the selection criteria, the alert contents, and the alert layout are specified in this ISPF Skeleton. You must also add the required CompareOpt statements at the bottom of the Global CARLa Skeleton, similar to the default CompareOpt statements that are already present. You specified the name for the required CompareOpt statement in the Parameters field, described earlier in this list. For example, to define an alert to be triggered on the event that the APF list is updated by the SETPROG command: Chapter 2. zSecure Alert configuration 31 Menu Options Info Commands Setup ------------------------------------------------------------------------------zSecure Admin+Audit for RACF - Setup - Alert Command ===> Description . Member prefix Alert id . . . Data source . Parameters . . Panel name . . . APF List changed using SETPROG command AHJ . 4000 Severity . . . . W (I, W, E or S) . WTO . . (Panel for additional customization) Specify SMF records to be collected for this alert Type Sub Type Sub Type Sub Type Sub Type Sub Specify WTO filters for this alert Prefix Prefix Prefix Prefix Prefix CSV410I Allowable destination types / E-mail Cellphone _ UNIX syslog Extended Monitoring alert . . (Y/N) View/edit the alert skeleton / ISPF Skeleton SNMP WTO Figure 17. Setup Alert panel: Defining an Alert CARLa skeleton for existing alerts You can edit the CARLa skeleton of an existing installation-defined alert. Tag the ISPF skeleton option in the panel you reach with the E(Edit) line command on an individual alert. If you perform this action on an IBM Security zSecure-supplied alert, you get an ISPF VIEW session instead. You reach the same panel with the B(Browse) line command. When adding an alert with the C(Copy) or I(Insert) line commands, you reach the panel where you can tag that option. In that case, the skeleton member does not normally exist yet. For Copy, it is then copied from the skeleton member of the copied alert. If the copied member defines local pre-selection filters, their names must be changed in the copy to avoid name clashes. The names are supposed to end in the alert ID. For Insert, you get an "empty" skeleton member. The information in the rest of this section is based on the "empty" skeleton member. In any case, you must see seven sections with CARLa code. The first two sections specify the Alert Condition. The next four sections specify the alert message format for the various Destination types. The last section specifies a possible command to be issued when the Alert Condition is raised. The CARLa sections in the skeleton are each marked with an identifying comment line as follows: )CM Pass one query Here you can specify a two-pass CARLa query for the stage1 member. Use it if your Alert Condition depends on the environment. During the stage1 step of this query, its output is used as a prefix for the reporting step. This output is a one-pass CARLa query populated with current environmental values. It enables you to generate a pre-selection based on the actual environment. Your Alert Condition can refer to this pre-selection. The pre-selection is adapted with each environmental refresh run. Normally, it is one time per hour. See “Alert configuration: specifying general settings” on page 12. 32 User Reference Manual )CM Alert condition Specify the Alert Condition that you want to trigger your alert. For Extended Monitoring alerts, it requires only a selection of the complex, for example, select complex=(base, current). The fields that determine which records trigger the alert are specified in the CompareOpt statement defined in the Global CARLa Skeleton. )CM Action command Here you can specify the following to embed statements to be able to specify an action command: )IM C2PSACTX )IM C2PSACTS See “Alert definition - specify action” on page 96. )CM EMAIL sortlist Here you can specify the alert message in the layout to be used for email destinations. )CM Cellphone sortlist Here you can specify the alert message in the layout to be used in text messages. Whether the text message as received is taken from the subject or the body of the email depends on the e-mail-to-text-message-gateway you use. All IBM Security zSecure-supplied alerts send a similar message in both subject and body. )CM SNMP sortlist Here you can specify the alert message in the layout to be used for SNMP destinations. )CM UNIX syslog sortlist Here you can specify the alert message in the layout to be used for SYSLOG destinations. )CM WTO sortlist Here you can specify the alert message in the layout to be sent to the console. )CM Command Here you can add a command to be issued when the condition occurs. You do not need to specify message formats that you do not want to use. However, you can keep at least the alert ID in each section so that you can recognize the alert if it ever gets used in that format. The alert ID parts can be recognized by the occurrence of the &c2pemem. skeleton variable. Each actual CARLa section is bounded by)SEL and)ENDSEL skeleton directives. The stage1 section also has an)IM directive. Do not change these directives. The next manual sections explain each CARLa section in detail. When you are done changing the skeleton, return to the alerts panel by pressing PF3. If you add an alert, it is selected automatically. Pressing PF3 twice more, you can return to the Alert Configuration panel, where you can then issue the V(Verify) command to check the new alert. If the verification is successful, you can enter the F(Refresh) command to activate the new alert. Environment-dependent selection You must enter the )CM Pass one query section if you want to use environment-dependent selection criteria in your Alert Condition. Chapter 2. zSecure Alert configuration 33 The following example is from skeleton member C2PS1204 for IBM Security zSecure-supplied alerts 1204 and 2204. It shows a stage1 query that asks the system what data sets are currently part of the APF list, that is, the DSN field and APF flag field of NEWLIST TYPE=SENSDSN. For more explanation, see IBM Security zSecure Admin and Audit for RACF: User Reference Manual. These data set names are substituted into another CARLa query. This query is otherwise contained in quotation marks and thus literally copied to the output file to become the start of the reporting step query. )CM Pass one query )SEL &C2PEPASS = Y n type=system outlim=1 nopage sortlist, "n type=smf name=uapf1204 outlim=0" /, )SEL &C2PESECP = RACF " select event=access(allowed) intent>=update likelist=recent," /, )ENDSEL )SEL &C2PESECP = ACF2 " select likelist=recent acf2_subtype=D," /, " acf2_access=(OUTPUT,UPDATE,INOUT,OUTIN,OUTINX)," /, )ENDSEL n type=sensdsn nopage select apf sortlist, " " dsn(0) | "," n type=system outlim=1 nopage sortlist, " )" /, " sortlist ’’" )ENDSEL The generated query is named UAPF1204 by the NAME keyword on the generated N (Newlist) statement. It allows the Alert Condition to refer to it. The NAME ends in the alert ID to avoid name clashes with filters specified in other alerts. The generated query is meant as a pre-selection only, and thus specifies OUTLIM=0, meaning that no output must be generated. The pre-selection is for SMF records for event=access(allowed) intent>=update on RACF systems. Or, it is for acf2_subtype=D ACF2_ACCESS=OUTPUT on ACF2 systems and for the APF data sets obtained from the system. The LIKELIST=RECENT clause further restricts the selection to the SMF records written during the current reporting interval. The following section explains about the pre-selection filters that are always available to specify what SMF and WTO input data to tie the selection to. Alert condition You must complete the )CM Alert condition section to indicate when you want to issue the alert. The following example is taken from skeleton member C2PS1204 for IBM Security zSecure-supplied alerts 1204 and 2204. The entire selection has already been done in a pre-selection named UAPF1204 that was generated by the environment-dependent selection for that alert as shown in the previous section. )CM Alert condition )SEL &C2PEPASS = N )IM C2PSGNEW select likelist=uapf1204 Skeleton member C2PSGNEW embedded by the )IM directive generates the CARLa NEWLIST statement for selection criteria. After the )IM statement, you can enter DEFINE and SELECT statements. 34 User Reference Manual The LIKELIST keyword refers to a preceding NEWLIST that has a NAME keyword with the same value. It means that the effective selection from that NEWLIST is to be used as a clause. In this case, it is the only clause so the exact same selection is used. The filters used in an alert can end in the alert ID to avoid name clashes with other alerts. See only the following global pre-selection filters and filters defined in the alert itself. There is no guarantee that references to filters in other alerts work consistently, or at all. The Alert Condition must always be tied to a global pre-selection filter to indicate what SMF and WTO input to monitor, either directly or indirectly. In this case the UAPF1204 pre-selection was already tied to the RECENT pre-selection filter, so this condition is indirectly satisfied. You can choose the global pre-selection filters from the following list: likelist=recent Tie to the recent SMF records written during the current reporting interval. likelist=history Tie to the "moving window" analysis SMF records written during the "averaging" interval. There is no overlap between recent and history. likelist=wtorec Tie to the recent WTO messages written during the current reporting interval. likelist=wtohis Tie to the "moving window" analysis WTO messages written during the "averaging" interval. There is no overlap between wtorec and wtohis. This list applies to the global skeleton C2PSGLOB. Note: If necessary, you can use a different global skeleton for an Alert Configuration. In these pre-selections, further selection on SMF record TYPE and SUBTYPE or on WTO MSGID is often required; for example, SELECT likelist=wtorec MSGID(CSV410I). For Extended Monitoring alerts, the alert condition requires only a selection of the complex select complex=(base, current), for example. However, additional selection criteria might be needed to limit the search for differences in system and security settings so that only certain records are included. For example, in Alert 1207, a NEWLIST TYPE=SENSDSN is used. However, the selection limits the comparison operation to just the APF data sets. See ID 1207 in Table 5 on page 39. The CompareOpt statement that specifies which fields to compare is defined in the Global CARLa Skeleton. Email layout You can specify the layout of the alert message for email destinations in the )CM EMAIL sortlist section. The IBM Security zSecure-supplied alerts have a common layout as shown in “Standard email layout” on page 42. The following example shows alert 1302. )CM EMAIL sortlist )SEL &C2PERCTP = MAIL sortlist, recno(nd), ’Alert: Audited program’(t) resource(t,8) ’has been executed’(t), ’Alert: Audited program’ resource(0) ’has been executed’ /, ’A program with auditing specified has been executed’ /, / ’ Alert id &c2pemem;’, Chapter 2. zSecure Alert configuration 35 / ’ / ’ / ’ / ’ / ’ / ’ / / )ENDSEL Date and time’(18) date(9) time(11), Program’(18) resource, Data set’(18) dataset, User’(18) user(8) name, Job name’(18) jobname, System ID’(18) system, Note: The title modifier (t) is used to set the email subject. Text message layout You can specify the layout of the alert message for text message destinations in the )CM Cellphone sortlist section. Whether the text message as received is taken from the subject or the body of the email depends on the e-mail-to-text-messagegateway you use. All IBM Security zSecure-supplied alerts send a similar message in both subject and body. The following example shows alert 1204. )CM Cellphone sortlist )SEL &C2PERCTP = CELL sortlist, recno(nd), ’Alert &c2pemem;: Update by’(t) user(t) ’on APF data set’(t), dataset(t), ’Alert &c2pemem;: Update by’ user(0) ’on APF data set’, dataset(0) )ENDSEL SNMP layout You can specify the layout of the alert message for SNMP destinations in the )CM SNMP sortlist section. In this layout, you specify combinations of variables and their contents. See also Appendix A, “SNMP output,” on page 107. The following example shows alert 1204. )CM SNMP sortlist )SEL &C2PERCTP = SNMP sortlist, recno(nd), ’&c2pemem.’ /, ’eventIntegral’, ’Alert: Update on APF data set’ dataset(0,hor) ’-’, ’APF data set successfully updated’ /, ’eventWhen’ datetime(datetimezone,0) /, ’onWhatDSNAME’ dataset(0,hor) /, ’onWhatGRANTED’ intent /, ’onWhatALLOWED’ access /, ’onWhatINTENT’ intent /, ’whoUSERID’ userid(0) /, ’whoNAME’ name(0) /, ’whatDESC’ desc(0,explode) /, ’whatJOBNAME’ jobname(0) /, ’whereSYSTEM’ system(0) )ENDSEL UNIX syslog layout You can specify the layout of the alert message for SYSLOG destinations in the )CM UNIX syslog sortlist section. The following example shows alert 1204. )CM UNIX syslog sortlist )SEL &C2PERCTP = SYSL )SEL &C2PESECP = RACF sortlist, recno(nd) ’<&C2PEPRIO.>’ | date(month,3) date(monthday,0) time(8), system ’C2P&c2pemem.’, ’[C2P&C2PEMEM.’, 36 User Reference Manual ’onWhatDSNAME="’ | dataset(0,firstonly) | ’"’, ’onWhatGRANTED="’ | intent(0) | ’"’, ’onWhatALLOWED="’ | access(0) | ’"’, ’onWhatINTENT="’ | intent(0) | ’"’, ’whoUSERID="’ | userid(0) | ’"’, ’whoNAME="’ | user:pgmrname(0) | ’"’, ’whatDESC="’ | desc(0,explode) | ’"’, ’whatJOBNAME="’ | jobname(0) | ’"’, ’whereSYSTEM="’ | system(0) | ’"]’, ’Alert: Update on APF data set’ dataset(0,hor) ’-’, ’APF data set successfully updated’ )ENDSEL Command section For RACF systems, you can optionally specify a command to be issued when the Alert Condition occurs in the )CM Command section. In the following example, the user to which the selected alert applies is revoked by RACF. )CM Command )SEL &C2PERCTP = CMD "alu" userid(0) "revoke" )ENDSEL Chapter 2. zSecure Alert configuration 37 38 User Reference Manual Chapter 3. Predefined alerts This chapter describes the alerts that are shipped with zSecure Alert. For an explanation of the Class column, see “Alert activation guidelines” on page 5. The following table explains the meaning of the Severity column. Alerts with IDs in the range 1000-1999 are RACF alerts and those alerts in the range 2000-2999 are ACF2 alerts. Table 5. Predefined Alerts ID Description Class Severity 1001 Heartbeat event (indicates that its originator is up and running) 3 0 1101 Logon by unknown user 2 3 1102 Logon with emergency user ID 1(*) 3 1103 Logon of a user ID with uid(0) (UNIX superuser) 2 2 1104 Highly authorized user revoked for password 2 3 1105 System authority granted 2 3 1106 System authority removed 3 2 1107 Group authority granted 2 2 1108 Group authority removed 3 3 1109 SPECIAL authority used by non-SPECIAL user 1 2 1110 non-OPERATIONS user accessed data set with OPERATIONS 1 3 1111 Invalid password attempts exceed limit 2 3 1112 Password history flushed 2 3 1113 Suspect password changes 3 2 1114 Connect authority>=CREATE set 2 2 1115 Too many violations 1 3 1201 WARNING mode access on data set 1 2 1202 Setting UACC>=UPDATE on a DATASET profile 2 3 1203 Setting UACC>NONE on a DATASET profile 3 2 1204 Update on APF data set 2 2 1205 Data set added to APF list using SETPROG 2 3 1206 Data set removed from APF list using SETPROG 2 2 1207 Data set addition to APF list detected 2 3 1208 Data set removal from APF list detected 2 2 1301 Catchall profile used for STC 3 2 1302 Audited program has been executed 3 2 1303 WARNING mode access on general resource 1 2 1401 UNIX file access violation 3 2 1402 Global write specified when altering file access 2 3 1403 Global read specified when altering file access 3 2 © Copyright IBM Corp. 2002, 2012 39 Table 5. Predefined Alerts (continued) 40 ID Description Class Severity 1404 Extended attribute changed (Superseded by 1409) 2 2 1405 Audited UNIX program has been executed 3 2 1406 Superuser privileged UNIX program executed 2 2 1407 Superuser privileged shell obtained by user 2 2 1408 Superuser privileges set on UNIX program 2 2 1409 Extended attribute changed 2 2 1501 Global security countermeasure activated 3(**) 2 1502 Global security countermeasure deactivated 1(*) (**) 4 1503 Global security countermeasure or option changed 1 3 1504 RACF resource class activated 2 2 1505 RACF resource class deactivated 2 3 1601 SMF data loss started 1(*) 5 1602 SMF logging resumed after failure 3 2 1603 SVC definition changed 2 3 1604 IBM Health Checker found low severity problem 3 2 1605 IBM Health Checker found medium severity problem 2 3 1606 IBM Health Checker found high severity problem 1 4 1607 SMF record flood detected 1 4 1608 SMF record flood starts dropping records 1 5 1609 Attacks blocked by filter rules are no longer logged 2 2 1610 Attacks blocked by default filter rules are no longer logged 3 2 1611 Certain SMF 119 records are no longer written; audit trail incomplete 1 3 1612 IPv4 or IPv6 filtering support and IPSec tunnel support 1 deactivated 4 1613 TCP or UDP ports below 1024 are not reserved any more 1 4 1614 The security class of an interface has changed 2 2 1615 IP filter rules changed 2 2 1701 Connect to an important group 2 3 2001 Heartbeat event (indicates that its originator is up and running) 3 0 2102 Logon with emergency user 1(*) 3 2104 Highly authorized user revoked for password 2 3 2105 System authority granted 2 3 2106 System authority removed 3 2 2111 Invalid password attempts exceed limit for user 2 3 2112 Password history flushed 2 3 2113 Suspect password changes 3 2 2115 Too many violations 1 3 User Reference Manual Table 5. Predefined Alerts (continued) ID Description Class Severity 2116 SECURITY authority used by non-SECURITY logon ID 1 2 2117 NON-CNCL authority used by non-NON-CNCL logon ID 1 3 2118 READALL authority used by non-READALL logon ID 1 3 2201 WARNING mode access on data set 1 2 2204 Update on APF data sets 2 2 2205 Data set added to APF list using SETPROG 2 3 2206 Data set removed from APF list using SETPROG 2 2 2207 Data set addition to APF list detected 2 3 2208 Data set removal from APF list detected 2 2 2301 Default STC logon ID used for STC 3 2 2407 Superuser privileged shell obtained by user 2 2 2409 Extended attribute changed 2 2 2501 Global security countermeasure added 3 2 2502 Global security countermeasure deleted 1 (*) 4 2503 Global security countermeasure or option changed 1 3 2601 SMF data loss started 1(*) 5 2602 SMF logging resumed after failure 3 2 2603 SVC definition changed 2 3 2604 IBM Health Checker found low severity problem 3 2 2605 IBM Health Checker found medium severity problem 2 3 2606 IBM Health Checker found high severity problem 1 4 2607 SMF record flood detected 1 4 2608 SMF record flood starts dropping records 1 5 2609 Attacks blocked by filter rules are no longer logged 2 (***) 2 2610 Attacks blocked by default filter rules are no longer logged 3 (***) 2 2611 Certain SMF 119 records are no longer written; audit trail incomplete 1 (***) 3 2612 IPv4 or IPv6 filtering support and IPSec tunnel support 1 (***) deactivated 4 2613 TCP or UDP ports below 1024 are not reserved any more 1 (***) 4 2614 The security class of an interface has changed 2 (***) 2 2615 IP filter rules changed 2 (***) 2 (*) When this alert is issued, a fast response is required. (**) This alert is included in alert 1503, so there is little point in activating it if they have the same receiver set. (***) The class and severity of this alert is identical to that of its RACF counterpart. Chapter 3. Predefined alerts 41 The Severity column lists the severity levels that Tivoli Enterprise Console and IBM Tivoli NetView associate with alerts. Severity levels range from 0 to 5: Table 6. Tivoli Enterprise Console and NetView severity levels Severity Meaning in Tivoli Enterprise Console Meaning in NetView 0 Harmless Cleared 1 Unknown Indeterminate 2 Warning Warning 3 Minor Minor error 4 Critical Critical 5 Fatal Major The alerts are communicated through alert messages that are available in the following different formats: v email v text message v WTO v SNMP trap v UNIX syslog See “Overview” on page 3. Sample emails and text messages are shown with each individual predefined alert in this chapter. The SNMP trap format is explained in Appendix A, “SNMP output,” on page 107. The rest of this chapter explains the general layout of the email format and describes the predefined alerts in detail, divided in functional categories. If an alert can be configured, it is explained here. Each alert requires certain SMF record types to be logged or specific WTO messages to be issued. Most predefined alerts require SMF type 80, RACF processing. It is assumed that you log these SMF types. All other requirements are shown with each individual alert. SMF logging is controlled per subsystem. Standard email layout All email alert messages have similar output. See the following example of an email that can be sent. From: C2POLICE at DINO Subject: Alert: Audited program ASMIDFA has been executed Alert: Audited program ASMIDFA has been executed A program which auditing specified has been executed Alert id Date and time Program Data set User Job name System ID 42 User Reference Manual 1302 07Feb2003 13:44:43.20 ASMIDFA SHARED.LINKLIB C##BDV2 DIONNE VONT C##BDV2 DINO You can see here that a program called ASMIDFA from the data set SHARED.LINKLIB has started execution. The user that executed the program is C##BDV2, and the user name is Dionne Vont. The program executes in job C##BDV2 on system DINO. The sender of the email can be configured using the interface. The default is: jobname at system name. The subject header and the body of the email are generated by the CARLa code. The email subject is the same as the first line in the email body; however, formatting might vary slightly. Below that line is a general header that describes the event. Below the headers of the alert is the section with details. The first line contains the alert ID. This number can be used to find the corresponding alert using SNMP, WTO, or SMS output and for finding the right entry in this documentation. The second line shows the date and time the event occurred. This is followed by the alert-specific fields. Finally, the job name, job ID, and system name are listed if available. Predefined RACF alerts This topic describes the RACF alerts that are shipped with zSecure Alert. User alerts The following alerts are used to monitor events pertaining to specific users and for auditing changes to users. Logon by unknown user (1101) This alert is triggered on two occasions: 1. A user, unknown to RACF, successfully logs on to TSO. This user is defined in SYS1.UADS, but not in RACF. 2. A batch job is submitted by NJE on another system for this system. On the receiving system, the user that submitted the job is not defined to RACF. To receive this alert, you must log SMF record type 30 subtype 1. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Logon by unknown user Alert: logon by unknown user A user unknown to RACF logged on or submitted a batch job Alert id Date and time User Result Job name + id System ID 1101 10Feb2003 06:53:16.60 * Success TSOB JOB00042 DINO The text message format of the alert is: Subject: Alert 1101: Logon by unknown user * job TSOB Alert 1101: Logon by unknown user * job TSOB The generated email report always shows a '*' for the user and whether the logon succeeded. Chapter 3. Predefined alerts 43 It can be difficult to find the source of the unknown logon because the system only logs a '*' as user. However, you can verify that the SYS1.UADS data set does not contain any user IDs that are not defined in RACF. Additionally, to stop job submissions by undefined users you can set SETROPTS JES(BATCHALLRACF). Logon with emergency user ID (1102) An alert is sent if a user ID that is meant for emergencies is used for TSO logon or batch job submission. To receive this alert, you must log SMF record type 30 subtype 1. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Emergency user IBMUSER logged on Alert: Emergency user IBMUSER logged on Successful logon or job submit with a userid meant for emergencies Alert id Date and time User Result Job name + id System ID 1102 03Feb2003 09:38:44.94 IBMUSER IBM DEFAULT USER Success IBMUSER TSU05900 DINO The text message format of the alert is: Subject: Alert 1102: emergency user IBMUSER logged on Alert 1102: emergency user IBMUSER logged on The generated email report shows the user ID used to log on to the system and whether the logon succeeded. You can configure the alert for your site. When selecting the alert, you are prompted with a panel. You can enter up to 10 user IDs that must be used only in case of emergencies. See “Emergency user configuration (alerts 1102 and 2102)” on page 96. Logon of a user ID with uid(0) (UNIX superuser) (1103) An alert is sent if a user ID with UNIX uid 0 is used to logon to TSO or OMVS. It is a sound UNIX principle that you must not log on with superuser privileges but instead use 'su' when needed. To receive this alert, you must log SMF record type 30 subtype 1. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Superuser C##BMR1 logon Alert: Superuser C##BMR1 logon A user with uid(0) has logged on Alert id Date and time User Logon to Result Job name + id System ID 44 User Reference Manual 1103 03Feb2003 09:38:44.94 C##BMR1 MARY ROBERTSON TSO Success C##BMR1 TSU05900 DINO The text message format of the alert is: Subject: Alert 1103: Superuser C##BMR1 logon to TSO Alert 1103: Superuser C##BMR1 logon to TSO The generated email report shows the user ID that was used to log on to the system, on which subsystem the logon took place, TSO or OMVS, and the status of the logon. If you receive these alerts, you must remove the uid 0 definition in the OMVS segments of these users. Use profiles in the UNIXPRIV class and BPX.SUPERUSER in the FACILITY class to give users selective superuser authority. Highly authorized user revoked for password (1104) This alert is triggered when a user with a system-level authority (SPECIAL, OPERATIONS, or AUDITOR) is revoked because of excessive invalid password attempts. It can be caused by an intruder who is trying to guess the password of the user. Note: You must take care not all your users with system authority get revoked at the same time. You must have some procedure to make sure that at least one unrevoked user ID with SPECIAL authority is reinstated. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Highly authorized user C##CX44 revoked for password violations Alert: Highly authorized user C##CX44 revoked for password violations System-level authorized user revoked due to excessive password attempts Alert id Date and time User System ID 1104 07Feb2003 14:58:27.13 C##CX44 TEST USER DINO The text message format of the alert is: Subject: Alert 1104: Highly authorized user C##CX44 revoked for password violations Alert 1104: Highly authorized user C##CX44 revoked for password violations The report shows the user ID and accompanying programmer name that is revoked for excessive password violations. System authority granted (1105) An alert is generated when a user obtains system-level authority (SPECIAL, OPERATIONS, AUDITOR, or CLAUTH). To receive this alert, you must have SETROPTS setting AUDIT(USER) and SAUDIT enabled. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: System authority granted to C##BMR2 Alert: System authority granted to C##BMR2 System-level authority granted to user Alert id Date and time 1105 29May2000 13:25:12.42 Chapter 3. Predefined alerts 45 Authority Granted to Result RACF command User Job name System ID SPECIAL C##BMR2 MARY ROBERTSON Success ALTUSER C##BMR2 SPECIAL C##BMR1 MARY ROBERTSON C##BMR1 DINO The text message format of the alert is: Subject: Alert 1105: System authority granted to C##BMR2 by C##BMR1 Alert 1105: System authority SPECIAL granted to C##BMR2 by C##BMR1 The report shows the system authority that is granted, the user that is granted the authority, the complete RACF command, and the result of the command. Additionally, it shows the user that performed the RACF command. System authority removed (1106) An alert is sent when a system-level authority, that is, SPECIAL, OPERATIONS, AUDITOR, or CLAUTH, is removed from a user. To receive this alert, you must have SETROPTS setting AUDIT(USER) and SAUDIT enabled. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: System authority removed from C##BMR1 Alert: System authority removed from C##BMR2 System-level authority removed from user Alert id Date and time Authority Removed from Result RACF command User Job name System ID 1106 29May2000 13:25:16.15 SPECIAL C##BMR2 MARY ROBERTSON Success ALTUSER C##BMR2 NOSPECIAL C##BMR1 MARY ROBERTSON C##BMR1 DINO The text message format of the alert is: Subject: Alert 1106: System authority removed from C##BMR2 by C##BMR1 Alert 1106: System authority SPECIAL removed from C##BMR2 by C##BMR1 The report shows the removed authority, the user whose authority is removed, the complete RACF command, and the result of the command. In addition, it shows the user that performed the RACF command. Group authority granted (1107) If a group-level authorization, that is, SPECIAL, OPERATIONS, or AUDITOR, is granted to a user, an alert is generated. To receive this alert, you must have SETROPTS setting SAUDIT, AUDIT(USER), or AUDIT(GROUP) enabled. The email format of the alert is: 46 User Reference Manual From: C2POLICE at DINO Subject: Alert: Group authority granted to C##ARO2 in C##C Alert: Group authority granted to C##ARO2 in C##C CONNECT Group-level authority granted to user Alert id Date and time Authority Granted to Connected to Result RACF command User Job name System ID 1107 02Feb2003 09:47:23.29 SPECIAL C##ARO2 RICK OXSON C##C Success CONNECT C##ARO2 AUTHORITY(USE) GROUP(C##C) NOADSP NOAUDITOR NOGRPACC NOOPERATIONS OWNER(C##C) RESUME SPECIAL UACC(NONE) C##BERT ERWIN RETTICH CRRAC#17 DINO The text message format of the alert is: Subject: Alert 1107: Group authority granted to C##ARO2 in C##C Alert 1107: Group authority SPECIAL granted to C##ARO2 in C##C The generated email report shows the granted authority, the user that is granted the authority, the group the authorized user is in, the complete RACF command, the result of the command, and the user who executed the command. Note: The RACF command field shows the specified command keywords and the default keywords so it can become rather long. Group authority removed (1108) An alert is generated if a group-level authorization, that is, SPECIAL, OPERATIONS, or AUDITOR, is removed from a user, or a user with such authorizations is removed from a group. To receive this alert, you must have SETROPTS setting SAUDIT, AUDIT(USER), or AUDIT(GROUP) enabled. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Group authority removed for C##ARO2 in C##C Alert: Group authority removed for C##ARO2 in C##C Group-level authority removed from user Alert id Date and time Authority Removed from Connected to Result RACF command User Job name System ID 1108 02Feb2003 09:47:23.29 OPERATIONS AUDITOR C##ARO2 RICK OXSON C##C Success CONNECT C##ARO2 AUTHORITY(USE) GROUP(C##C) NOADSP NOAUDITOR NOGRPACC NOOPERATIONS OWNER(C##C) RESUME SPECIAL UACC(NONE) C##BERT ERWIN RETTICH CRRAC#17 DINO The text message format of the alert is: Chapter 3. Predefined alerts 47 Subject: Alert 1108: Group authority removed for C##ARO2 in C##C Alert 1108: Group authority OPERATIONS AUDITOR removed for C##ARO2 in C##C The report shows the removed authority, or <CONNECT REMOVED> if the connection is removed, the user whose authority is removed, the group that the user is in, the complete RACF command, the result of the command, and the user who executed the command. Note: The RACF command field shows the specified command keywords and the default keywords so it can become rather long. SPECIAL authority used by non-SPECIAL user (1109) This alert is generated when a user without system or group special authorization executes a command with the group or system special authorizations. It means that the user has the potential to successfully execute commands that require group or system special, but does not have SPECIAL authority itself. This condition can be set by APF-authorized software. Note: You must analyze the SMF records cut for the job up to the time the alert was issued as a first attempt to identify the responsible program. To receive this alert, you must have SETROPTS setting SAUDIT enabled. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: non-SPECIAL user C##BDV1 issued SPECIAL command Alert: non-SPECIAL user C##BDV1 issued SPECIAL command SPECIAL authority used for RACF command by user without SPECIAL Alert id Date and time User RACF command Result Job name System ID 1109 17Jan2003 03:00:16.89 C##BDV1 DIONNE VONT ADDSD ’SYS1.APF.NODATA.**’ NOSET Success C##BDV1 DINO The text message format of the alert is: Subject: Alert 1109: non-SPECIAL user C##BDV1 issued SPECIAL command Alert 1109: non-SPECIAL user C##BDV1 issued SPECIAL command ADDSD ’SYS1.APF.NODATA.**’ NOSET The report shows the user, the RACF command the user executed, and whether the command succeeded. If the command is issued without valid authorization, you must examine the cause for the special authorization and remove it. Non-OPERATIONS user accessed data set with OPERATIONS (1110) An alert is generated when a user without system or group operations accesses a data set with group or system operation authority. It implies that the user can access all data sets in the scope of the user unless explicitly denied by an ACL. This situation can arise if an APF-authorized program sets group or system operations authority in the RACF control blocks. 48 User Reference Manual Note: You must analyze the SMF records cut for the job up to the time the alert got issued as a first attempt to identify the responsible program. To receive this alert, you must have SETROPTS setting OPERAUDIT enabled. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: non-OPERATIONS user D##MUY accessed data set with OPERATIONS Alert: non-OPERATIONS user D##MUY accessed data set with OPERATIONS Successful data set access using OPERATIONS by user without OPERATIONS Alert id Date and time Data set Access User Result Job name System ID 1110 22Jan2003 10:26:16.81 D##BEV.GBS001.D##Y.DC107SCK.BV0GBS00 ALTER D##MUY Success D##MUY DINO The text message format of the alert is: Subject: Alert 1110: non-OPERATIONS user D##MUY accessed (ALTER OPERATIONS data set D##BEV.GBS001.D##Y.DC107SCK.BV0GBS00 ) with Alert 1110: non-OPERATIONS user D##MUY accessed (ALTER) with OPERATIONS data set D##BEV.GBS001.D##Y.DC107SCK.BV0GBS00 The alert shows the data set that is accessed, the access level, the accessing user, and the result of the action. If the access is non-valid, you must examine the reason why these OPERATIONS authorizations are set, and remove the cause if necessary. Invalid password attempts exceed limit (1111) An alert is sent if too many failed logon attempts are made specifying an invalid password for one specific user ID in a specific time window. The measurement interval is the sum of the REPORT options Interval and AverageInterval. See the information about the REPORT command in the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. "Too many" is defined as 5 or more. If you want to use another limit, you must copy the alert to an installation defined alert. Adapt all four instances of #history(nd,<5), #total(nd,>=5), in the new skeleton member to use the limit you want instead of 5. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Invalid password attempts exceed limit for C##BSG2 Alert: Invalid password attempts exceed limit for C##BSG2 Excessive number of password attempts by user Alert id Date and time Attempts User Result System ID 1111 03Mar2003 13:30:04.39 - 03Mar2003 13:39:23.78 6 C##BSG2 SUSAN GAYNOR Violation DINO Chapter 3. Predefined alerts 49 The text message format of the alert is: Subject: Alert 1111: Invalid password attempts exceed limit for C##BSG2 Alert 1111: Invalid password attempts exceed limit for C##BSG2 The generated email report shows the interval in which the logon attempts occurred, the number of attempts, the user ID that was used for trying to log on to the system, and the status of the logon; in this alert the logons are always violations. Currently it is not possible to display the source (terminal) of the logon attempts. Password history flushed (1112) An alert is sent if the password for a specific user ID is changed more often than the password history SETROPTS setting in a specific time window. It means that the user flushed the entire password history, enabling reuse of a previous password. The measurement interval is the sum of the REPORT options Interval and AverageInterval. See the information about the REPORT command in the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. Note: 1. Alerts 1112 and 1113 are related. When a report interval ends while a password history is being flushed, alert 1113 is triggered, while alert 1112 occurs when flushing is complete. If you receive multiple alerts 1113 for the same user, but no alert 1112, it is also likely that the history is being flushed. The user might have taken some more time for it. 2. Both alerts 1112 and 1113 depend on whether you activate the IBM Security zSecure New Password Exit. See IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. By default, the exit is installed and activated. When the New Password Exit is activated, password changes done by a JOB card or at logon result in an SMF record identical to that generated for the PASSWORD command. These password changes are counted for alert 1112 and 1113. If you do not activate the IBM Security zSecure New Password Exit, password changes done by a JOB card or logon are not detected. To receive this alert, you must have SETROPTS AUDIT(USER) enabled. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Password history flushed for C##BSG2 Alert: Password history flushed for C##BSG2 Repeated PASSWORD commands flush password history Alert id Date and time Pwd changes User System ID 1112 05Mar2003 11:47:11.21 - 03Mar2003 11:47:12.04 33 C##BSG2 SUSAN GAYNOR DINO The text message format of the alert is: Subject: Alert 1112: Password history flushed for C##BSG2 Alert 1112: Password history flushed for C##BSG2 50 User Reference Manual The generated email report shows the interval in which the password history flushing occurred, the number of password changes, and the user ID of the user who flushed the password history. Suspect password changes (1113) An alert is sent if the password for a specific user ID is changed too often in a specific time window, but not so often that the password history is flushed completely, which would result in alert 1112. "Too often" is defined as five times or more. If you want to use another limit, you must copy the alert to an installation defined alert. Adapt all four instances of #history(nd,<5) #total(nd,>=5), in the new skeleton member to use the wanted limit. To receive this alert, you must have SETROPTS AUDIT(USER) enabled. For further explanation, see “Password history flushed (1112)” on page 50. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Suspect password changes for C##BSG2 Alert: Suspect password changes for C##BSG2 Excessive number of PASSWORD commands by user Alert id Date and time Pwd changes User System ID 1113 03Mar2003 15:17:12.32 - 03Mar2003 15:17:13.11 7 C##BSG2 SUSAN GAYNOR DINO The text message format of the alert is: Subject: Alert 1113: Suspect password changes for C##BSG2 Alert 1113: Suspect password changes for C##BSG2 The generated email report shows the interval in which the password changes occurred, the number of password changes, and the user ID that has its password changed many times. Connect authority>=CREATE set (1114) An alert is sent when an authority level of CREATE or higher is set on a connection. Such a level allows decentralized administrators to add group data set profiles. If the level is CONNECT or JOIN, the user can furthermore connect any existing user to the group in question. If the level is JOIN, the user can also create subgroups and give out connect authorities for the group to other users. Furthermore, if the user has class authority (CLAUTH) in the USER class, new users can be created in the group as well. To receive this alert, you must have at least SETROPTS setting AUDIT(USER) enabled. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Connect authority JOIN set for C##BSG2 in C##B Alert: Connect authority JOIN set for C##BSG2 in C##B High authority specified when adding or altering a connect Chapter 3. Predefined alerts 51 Alert id Date and time Authority Granted to Connected to Result RACF command User Job name System ID 1114 08May2003 10:11:09.51 JOIN C##BSG2 SUSAN GAYNOR C##B Success ALTUSER C##BSG2 AUTHORITY(JOIN) GROUP(C##B) C##BERT ERWIN RETTICH CBERT#17 DINO The text message format of the alert is: Subject: Alert 1114: Connect authority JOIN set for C##BSG2 in C##B Alert 1114: Connect authority JOIN set for C##BSG2 in C##B The generated email report shows the granted group-authority, the user and the target group, the complete RACF command, the result of the command, and the user who executed the command. Note: The RACF command field shows the specified command keywords and the default keywords, so it can become rather long. Too many violations (1115) This corrective alert is generated when more violations than a configured number are recorded for a specific user ID in the interval as specified with the zSecure Alert REPORT option AverageInterval. For additional information, see the information about the REPORT command in the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. To generate this alert, RACF access violations must be recorded. Access violations are recorded depending on the LOGOPTION settings for the class and the audit settings of the profile. This alert is corrective in that you can specify to automatically revoke the violating user ID. In addition, with a zSecure Admin license you can choose to generate a CKGRACF DISABLE command instead of an ALTUSER REVOKE command. The report format of the alert depends on whether you decided to let zSecure Alert perform a corrective action. The email format of the alert without a corrective action is: From: Subject: C2POLICE at DINO Alert: 15 violations recorded for user C2RMUS01 Alert: 15 violations recorded for user C2RMUS01 Number of violation exceeds the configured 10 Alert id Date and time Violations User System ID Time 52 Intent 1115 09Mar2005 14:49:55.90 - 09Mar2005 14:54:57.89 15 C2RMUS01 DINO Allowed Class 14:49 READ NONE 14:49 READ NONE User Reference Manual Resource JESSPOOL JES2DINO.DFHSM.DFHSM.STC05782.D0000002.J ESMSGLG JESSPOOL JES2DINO.DFHSM.DFHSM.STC05782.D0000003.J ESJCL 14:50 READ NONE 14:50 READ 14:51 READ NONE NONE JESSPOOL JES2DINO.DFHSM.DFHSM.STC05782.D0000004.J ESYSMSG JESSPOOL JES2DINO.DFHSM.DFHSM.STC05782.D0000101.? JESSPOOL JES2DINO.DFHSM.DFHSM.STC05782.D0000104.? The text message format of the alert is: Subject: Alert 1115: 15 violations recorded for user C2RMUS01 Alert 1115: 15 violations recorded for user C2RMUS01 When you decide to generate an ALU REVOKE command for the violating user ID, the text is changed into: User C2RMUS01 revoked after 15 violations When you decide to generate a CKGRACF DISABLE command for the violating user ID, the text is changed into: User C2RMUS01 disabled with schedule DIS#VIOL after 15 violations This alert enables you to customize for your site. When selecting the alert, you are prompted with a panel. In the panel, you can specify the number of violations you consider excessive and whether you want to generate a corrective action. Furthermore, you can specify up to 10 user IDs or user ID masks to be excluded. See “Revocation for excessive violations (1115) configuration” on page 97. Data set alerts This section describes the predefined alerts for data set access and data set profile changes. WARNING mode access on data set (1201) A data set is accessed and access is granted because of warning mode. See also “WARNING mode access on general resource (1303)” on page 59. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: WARNING mode READ on data set CDS.SCDSSAMP Alert: WARNING mode READ on data set CDS.SCDSSAMP Data set access granted due to warning mode Alert id Date and time Data set Granted access Normal access Profile User Job name System ID 1201 21Jan2003 09:11:11.01 CDS.SCDSSAMP READ NONE CDS.SCDS* C##BMR1 MARY ROBERTSON C##BMR1 DINO The text message format of the alert is: Subject: Alert 1201: WARNING mode READ CDS.SCDSSAMP by C##BMR1 on data set Alert 1201: WARNING mode READ by C##BMR1 on data set CDS.SCDSSAMP Chapter 3. Predefined alerts 53 The reports show the data set, the user that requested access to it, the profile against which the access is checked, the access that is granted, and the normal access that would have been granted if the profile had not been in WARNING mode. A profile in WARNING mode can grant any access to the resource, including what the profile would not allow otherwise. WARNING mode is typically used to analyze what the effects of the access settings of a profile are before the access control is enforced. It functions as a temporary measure to overcome production problems. If you receive these alerts, you must verify whether the access must be granted. When confirmed, change the access settings of the profile accordingly. If this access is not supposed to occur, take remedial action as required. UACC>=UPDATE on a DATASET profile (1202) An alert is generated if a UACC equal to or higher than UPDATE is specified on a data set profile. If you want to receive alerts even when the specified UACC is equal to READ, you can use the next alert. See “UACC>NONE on a DATASET profile (1203).” To receive this alert, you must have SETROPTS setting AUDIT(DATASET) enabled. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: UACC>=UPDATE set: C##QAP2.ONZI.** Alert: UACC>=UPDATE set: C##QAP2.ONZI.** High UACC specified when adding or altering a data set profile Alert id Date and time Profile UACC Result RACF command User Job name System ID 1202 04Feb2003 01:12:18.45 C##QAP2.ONZI.** UPDATE Success ALTDSD ’C##QAP2.ONZI.**’ UACC(UPDATE) C##QAP2 ALEXANDER POUVIER C##QAP2 DINO The text message format of the alert is: Subject: Alert 1202: UACC>=UPDATE set by C##QAP2 : C##QAP2.ONZI.** Alert 1202: UACC>=UPDATE set: C##QAP2.ONZI.** UACC set to UPDATE by C##QAP2 The report shows the changed profile, the specified UACC, the complete RACF command, the result of the command, and the user who executed the command. UACC>NONE on a DATASET profile (1203) If a UACC higher than NONE is specified on a data set profile, an alert is generated. If you want to receive alerts only when the specified UACC is higher than READ, you can use the previous alert. See “UACC>=UPDATE on a DATASET profile (1202).” To receive this alert, you must have SETROPTS setting AUDIT(DATASET) enabled. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: UACC>NONE set: C##QAP2.ONZI.** Alert: UACC>NONE set: C##QAP2.ONZI.** 54 User Reference Manual High UACC specified when adding or altering a data set profile Alert id Date and time Profile UACC Result RACF command User Job name System ID 1203 04Feb2003 01:12:18.45 C##QAP2.ONZI.** UPDATE Success ALTDSD ’C##QAP2.ONZI.**’ UACC(UPDATE) C##QAP2 ALEXANDER POUVIER C##QAP2 DINO The text message format of the alert is: Subject: Alert 1203: UACC>NONE set by C##QAP2 : C##QAP2.ONZI.** Alert 1203: UACC>NONE set: C##QAP2.ONZI.** UACC set to UPDATE by C##QAP2 The report shows the changed profile, the specified UACC, the complete RACF command, the result of the command, and the user who executed the command. Update on APF data set (1204) An alert is sent when an APF authorized data set is updated. To generate this alert, RACF successful update access must be recorded. This is the case if either AUDIT(success(update)) or GLOBALAUDIT(success(update)) has been specified for the relevant profiles. The necessary commands can be created by the zSecure Audit VERIFY SENSITIVE command. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Update by C##ASCH on APF data set C##A.D.C##NEW.APF.LOAD Alert: Update by C##ASCH on APF data set C##A.D.C##NEW.APF.LOAD APF data set successfully updated Alert id Date and time Data set Access User Result Job name System ID 1204 03Feb2003 10:12:05.30 C##A.D.C##NEW.APF.LOAD ALTER C##ASCH SIRAM CHRISTIAN Success C##ASCHL DINO The text message format of the alert is: Subject: Alert 1204: Update by user C##ASCH C##A.D.C##NEW.APF.LOAD on APF data set Alert 1204: Update by user C##ASCH on APF data set C##A.D.C##NEW.APF.LOAD The alert shows the data set that was updated, the employed access level, and the user who accessed the data set. Data set added to APF list using SETPROG (1205) An alert is generated when a data set is dynamically added to the APF list using the SET PROG or SETPROG command. To generate this alert, WTO message CSV410I must be available, and selected for processing. Chapter 3. Predefined alerts 55 The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Data set added to APF list using SETPROG: SYSPROG.APF.LOAD Alert: Data set added to APF list using SETPROG:SYSPROG.APF.LOAD A data set is dynamically added to the APF list Alert id Date and time Data set Volume Console ID System ID 1205 21Feb2003 11:44:36.71 SYSPROG.APF.LOAD <SMS MANAGED> R##SLIN DINO The text message format of the alert is: Subject: Alert 1205: Data set added to APF list using SETPROG from console R##SLIN: SYSPROG.APF.LOAD Alert 1205: Data set added to APF list using SETPROG from console R##SLIN: SYSPROG.APF.LOAD on volume <SMS MANAGED> The alert shows the data set added to the APF list, on what volume the data set resides, or <SMS MANAGED> if it is managed by SMS. It shows the name of the console from which the user entered the SET PROG or SETPROG command, if entered from SDSF. The console name defaults to the user ID. Data set removed from APF list using SETPROG (1206) An alert is generated when a data set is dynamically removed from the APF list using the SET PROG or SETPROG command. To generate this alert, WTO message CSV410I must be available, and selected for processing. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Data set removed from APF list using SETPROG: SYSPROG.APF.LOAD Alert: Data set removed from APF list using SETPROG: SYSPROG.APF.LOAD A data set is dynamically removed from the APF list Alert id Date and time Data set Volume Console ID System ID 1206 21Feb2003 11:44:36.71 SYSPROG.APF.LOAD <SMS MANAGED> R##SLIN DINO The text message format of the alert is: Subject: Alert 1206: Data set removed from APF list using SETPROG from console R##SLIN: SYSPROG.APF.LOAD Alert 1206: APF Data set removed from APF list using SETPROG from console R##SLIN: SYSPROG.APF.LOAD on volume <SMS MANAGED> The alert shows the data set removed from the APF list. It also shows on what volume the data set resides, or <SMS MANAGED> if it is managed by SMS. It shows the name of the console from which the user entered the SET PROG or SETPROG command, if entered from SDSF. The console name defaults to the user ID. 56 User Reference Manual Data set addition to APF list detected (1207) This alert is generated when a data set is added to the APF list by any method. It includes use of the SET PROG or SETPROG command and use of other products. To generate this alert, Extended Monitoring must be active. This alert is based on a comparison of two system snapshots. It does not provide any information about the user ID or jobname that was used to add the data set or the process that was used to perform the addition. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Data set addition to APF list detected: SYSPROG.APF.LOAD Alert: Data set addition to APF list detected: SYSPROG.APF.LOAD An addition of a data set to the APF list has been detected Alert id 1207 Data set SYSPROG.APF.LOAD Volume <SMS MANAGED> System ID DINO The text message format of the alert is: Subject: Alert 1207: Data set addition to APF list detected: SYSPROG.APF.LOAD Alert 1207: Data set addition to APF list detected: SYSPROG.APF.LOAD on volume <SMS MANAGED> The alert shows the data set that was added to the APF list. It also shows on what volume the data set resides (or <SMS MANAGED> if it is managed by SMS). This alert is based on a comparison of two system snapshots. It does not provide any information about the user ID or jobname that was used to add the data set or the process that was used to perform the addition. Data set addition to APF list detected (1208) This alert is generated when a data set is removed from the APF list by any method. It includes use of the SET PROG or SETPROG command and use of other products. To generate this alert, Extended Monitoring must be active. This alert is based on a comparison of two system snapshots. It does not provide any information about the user ID, jobname that was used to add the data set, or the process that was used to perform the addition. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Data set addition to APF list detected: SYSPROG.APF.LOAD Alert: Data set removal from APF list detected: SYSPROG.APF.LOAD A removal of a data set from the APF list has been detected Alert id 1208 Data set SYSPROG.APF.LOAD Volume <SMS MANAGED> System ID DINO The text message format of the alert is: Subject: Alert 1208: Data set removal from APF list detected: SYSPROG.APF.LOAD Alert 1208: Data set removal from APF list detected: SYSPROG.APF.LOAD on volume <SMS MANAGED> The alert shows the data set that was removed from the APF list. It also shows on what volume the data set resides (or <SMS MANAGED> if it is managed by SMS). This alert is based on a comparison of two system snapshots. It does not provide Chapter 3. Predefined alerts 57 any information about the user ID, jobname that was used to add the data set, or the process that was used to perform the addition. General resource alerts These alerts report on the use of and changes to general resources. Catchall profile used for STC (1301) An alert is sent if a started task is checked against a catchall profile in the STARTED class. To receive this alert, you must set TRACE(YES) with an RALTER STARTED command on the catchall profile. This outputs WTO message IRR812I. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: STARTED/*.* used for STC IEFBR1A .IEFBR1B Alert: STARTED/*.* used for STC IEFBR1A.IEFBR1B A started task is checked against a catchall profile Alert id Date and time Profile Started task Started jobname System ID 1301 11Feb2003 18:14:48.78 *.* IEFBR1A IEFBR1B DINO The text message format of the alert is: Subject: Alert 1301: STARTED/*.* Alert 1301: STARTED/*.* used for STC IEFBR1A .IEFBR1B used for STC IEFBR1A .IEFBR1B The report shows the matched catchall profile and the started task member and job name. This report does not show the user who began the started task. You can remove the cause of this alert if you define the member.jobname in the STARTED class. The catchall profile is not checked anymore for this started task. Audited program has been executed (1302) Alert when a program that is audited has started execution. An audited program is protected by a profile in the PROGRAM class that has at least user or auditor auditing for READ successes. To receive this alert, you must have at least AUDIT(SUCCESS(READ)) or GLOBALAUDIT(SUCCESS(READ)) specified on the profiles. You want these profiles to be reported on in the PROGRAM class. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Audited program ASMIDFA has been executed Alert: Audited program ASMIDFA has been executed A program with auditing specified has been executed Alert id Date and time Program Data set 58 User Reference Manual 1302 07Feb2003 13:44:43.20 ASMIDFA SHARED.LINKLIB User Job name System ID Audit reason C##BDV2 DIONNE VONT C##BDV2 DINO <reason> The text message format of the alert is: Subject: Alert 1302: Audited program ASMIDFA job C##BDV2 has been executed by C##BDV2 in Alert 1302: Audited program ASMIDFA from data set SHARED.LINKLIB has been executed by C##BDV2 in job C##BDV2 The report shows the program that has started execution, the data set where the program resides, the user who executed the program, and the audit reason. WARNING mode access on general resource (1303) A profile in a general resource class is checked for access, and access is granted because of warning mode. A similar alert for data sets is available in “WARNING mode access on data set (1201)” on page 53. The e-mail format of the alert is: From: C2POLICE at DINO Subject: Alert: WARNING mode access to FACILITY IRR.LISTUSER Alert: WARNING mode READ on FACILITY IRR.LISTUSER Resource access granted due to warning mode Alert id Date and time Class Resource Granted access Normal access Profile User Job name System ID 1303 07Feb2003 14:15:09.60 FACILITY IRR.LISTUSER READ NONE IRR.LISTUSER C##BDV2 DIONNE VONT C##BDV2 DINO The text message format of the alert is: Subject: Alert 1303: WARNING mode READ FACILITY IRR.LISTUSER by C##BDV2 on Alert 1303: WARNING mode READ by C##BDV2 on FACILITY IRR.LISTUSER The report shows the class and the name of the resource accessed, the user who requested access to it, and the profile against which the access is checked. It also shows the access that is granted and the normal access that would have been granted if the profile had not been in WARNING mode. A profile in WARNING mode grants any access to the resource, including what the profile would not allow otherwise. WARNING mode is typically used to analyze what the effects of the access settings of a profile are, before the access control is enforced. It is also used as a temporary measure to overcome production problems. If you receive these alerts, you must verify whether the access must be allowed. If so, change the access settings of the profile accordingly. If this access is not supposed to occur, take remedial action as required. Chapter 3. Predefined alerts 59 UNIX alerts The following alerts are triggered when events concerning UNIX files, directories, or programs occur. UNIX file access violation (1401) An alert is sent when an access violation occurs on a UNIX file or directory. To generate this alert, SETROPTS setting LOGOPTIONS(FAILURES(DIRACC DIRSRCH FSOBJ)) must be set. Or, the relevant files must have access failure auditing specified by the chaudit command. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: UNIX access violation on ./actuator/bin/db2asc Alert: UNIX access violation on ./actuator/bin/db2asc Non-authorized UNIX file or directory access Alert id Date and time Path Access type Intended access Granted access User Job name System ID 1401 28May2000 01:10:06.67 ./actuator/bin/db2asc FACCESS --wr-x C##BOON OTTO ONSLEY C##BOON DINO The text message format of the alert is: Subject: Alert 1401: UNIX access violation (--w-) by C##BOON on ./actuator/bin/db2asc Alert 1401: UNIX access violation (--w-) by C##BOON on ./actuator/bin/db2asc The report shows the path of the file or directory, the access type, that is, FACCESS, DIRACCESS, DIRSRCH, the intended access and the granted access, and the user who tried to access the file or directory. If you use a CKFREEZE file created with parameter UNIX=YES, the UNIX path mentioned in the report is an absolute path. Global write specified when altering file access (1402) This alert is generated if write access is specified on the other group of permissions of a UNIX file or directory. To receive this alert, you must have SETROPTS setting LOGOPTIONS(ALWAYS(FSSEC)) enabled. In the absence of a CKFREEZE file created with parameter UNIX=YES and AUTOMOUNT=YES, you might also receive this alert for other non-file UNIX objects. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Global write specified on www/log/access.log Alert: Global write specified on www/log/access.log Global write specified when altering file access Alert id Date and time Path 60 User Reference Manual 1402 09Feb2003 08:07:01.66 www/log/access.log Old permissions New permissions Result User Job name System ID rw-r--r-rw-rw-rwSuccess C##BER2 ERWIN RETTICH C##BER2 DINO The text message format of the alert is: Subject: Alert 1402: Global write specified by C##BER2 on www/log/access.log Alert 1402: Global write specified by C##BER2 on www/log/access.log The alert shows the path of the file or directory and the old and new permissions. It also shows the result of the chmod command and the user who changed the permission mode. If you use a CKFREEZE file created with parameter UNIX=YES, the UNIX path in the report is an absolute path. Global read specified when altering file access (1403) This alert is sent if read access is specified on the "other" group of permissions of a UNIX file. To receive this alert, you must have SETROPTS setting LOGOPTIONS(ALWAYS(FSSEC)) enabled. In the absence of a CKFREEZE file created with parameter UNIX=YES and AUTOMOUNT=YES, you can receive this alert also for other non-file UNIX objects. The e-mail format of the alert is: From: C2POLICE at DINO Subject: Alert: Global read specified on www/log/access.log Alert: Global read specified on www/log/access.log Global read specified when altering file access Alert id Date and time Path Old permissions New permissions Result User Job name System ID 1403 09Feb2003 08:05:22.61 www/log/access.log rw------rw-r--r-Success C##BER2 ERWIN RETTICH C##BER2 DINO The text message format of the alert is: Subject: Alert 1403: Global read specified by C##BER2 on www/log/access.log Alert 1403: Global read specified by C##BER2 on www/log/access.log The alert shows the path of the file, the old and new permissions, the result of the chmod command, and the user who changed the permission mode. If you use a CKFREEZE file created with parameter UNIX=YES, the UNIX path in the report is an absolute path. Extended attribute changed (1404) An alert is generated when an extended attribute (that is, APF, program control, or BPX shareas) is set or removed from a UNIX file or program. This alert was superseded by alert 1409, available on z/OS 1.11 and later. Alert 1409 is much simpler to configure and uses considerably less resources than alert 1404. Chapter 3. Predefined alerts 61 To receive alert 1404, you must have at least SETROPTS setting LOGOPTIONS(DEFAULT(FSOBJ)) enabled. Then you can use the z/OS UNIX chaudit command to activate successful write auditing for the programs you want audited. If you have not activated successful auditing, the text of the alert as sent out is incomplete, and essential parts (like the alert number and the file identification) are missing. To avoid the need to set successful auditing for individual files, you might consider setting LOGOPTIONS(ALL(FSOBJ)). However, doing so significantly increases the number of SMF records created. To receive alerts of type 1404, you also cannot define a BPX.SAFFASTPATH profile in the FACILITY class. For alerts sent by email, an attempt is made to include the actual extended attribute that has been changed. For this to be successful, READ logging on the FACILITY profiles matching BPX.FILEATTR.APF and BPX.FILEATTR.PROGCTL is also needed. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Extended attribute changed: APF Alert: Extended attribute changed: APF APF or program control bit changed on UNIX file or directory Alert id Date and time Path User Job name System ID 1404 05Feb2003 13:17:52.49 audfrbg C##BERT ERWIN RETTICH C##BERT DINO The text message format of the alert is: Subject: Alert 1404: APF or program control bit changed by C##BERT UNIX file or directory audfrbg on Alert 1404: APF or program control bit changed by C##BERT on UNIX file or directory audfrbg The alert shows the extended attribute that is set or removed. It also shows the path of the file or directory and the user who changed the attribute. If you use a CKFREEZE file created with parameter UNIX=YES, and optionally AUTOMOUNT=YES, specified, the path in the report is an absolute path. Audited UNIX program has been executed (1405) An alert is sent if a z/OS UNIX program that has successful execution audit (user or auditor) enabled has started execution. This alert does not cover programs that have the setuid bit enabled and have a superuser as owner. For more information, see “Superuser privileged UNIX program executed (1406)” on page 63. To receive this alert, the audited program must be in an HFS file system. You must have at least SETROPTS setting LOGOPTIONS(DEFAULT(FSOBJ)) enabled, and must have no BPX.SAFFASTPATH profile defined in the FACILITY class. Additionally, you must use a CKFREEZE file created with parameter UNIX=YES, and optionally AUTOMOUNT=YES. Alerts are sent only for programs that have their information in the CKFREEZE file. You can use the z/OS UNIX chaudit command to set the successful execution auditing bits on the programs you want audited. 62 User Reference Manual The email format of the alert is: From: C2POLICE at DINO Subject: Alert: UNIX program executed: chprot Alert: UNIX program executed: chprot A UNIX program with execution auditing specified has been executed. Alert id Date and time Path User Job name System ID 1405 11Mar2003 11:05:11.49 /usr/bin/chprot C##BSG2 SUSAN GAYNOR C##BSG2 DINO The text message format of the alert is: Subject: Alert 1405: UNIX program executed by C##BSG2 : /usr/bin/chprot Alert 1405: UNIX program executed by C##BSG2: /usr/bin/chprot The alert shows the path of the program and the user who started execution of that program. Superuser privileged UNIX program executed (1406) An alert is sent if a UNIX program with setuid enabled and owned by uid 0 has started execution. The program must have successful execution audit (user or auditor) enabled. Independent of the authorization of the user, these programs run with superuser privileges, and can read and write any file or directory on the UNIX subsystem. To receive this alert, the audited program must be in an HFS file system. You must have at least SETROPTS setting LOGOPTIONS(DEFAULT(FSOBJ)) enabled, and must have no BPX.SAFFASTPATH profile defined in the FACILITY class. In addition, you must use a CKFREEZE file created with parameter UNIX=YES, and optionally AUTOMOUNT=YES. Alerts are sent only for programs that have their information in the CKFREEZE file. This alert accompanies alert 1405. That alert sends a message if an audited UNIX program without these special privileges started execution. See “Audited UNIX program has been executed (1405)” on page 62. You can use the accompanying CARLa to generate UNIX command to set auditor execution auditing on all programs that execute with superuser privileges. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Superuser privileged UNIX program executed: rdefcha Alert: Superuser privileged UNIX program executed: rdefcha An audited UNIX program started execution with superuser privileges Alert id Date and time Path User Job name System ID 1406 13May2003 21:59:05.12 /usr/local/bin/rdefcha C##BSG1 SUSAN GAYNOR C##BSG1 DINO The text message format of the alert is: Subject: Alert 1406: Superuser privileged UNIX program executed: rdefcha Alert 1406: Superuser privileged UNIX program executed: rdefcha Chapter 3. Predefined alerts 63 The alert shows the path of the program that has setuid privileges and the user who started execution of the program. Superuser privileged shell obtained by user (1407) An alert is generated when a user uses the UNIX su command to obtain a shell with superuser privileges. To receive this alert, you must have successful READ logging specified on the BPX.SUPERUSER FACILITY profile. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Superuser privileged shell obtained by user C##BSG1 Alert: Superuser privileged shell obtained by user C##BSG1 A user used su to obtain a shell with superuser privileges Alert id Date and time User Job name System ID 1407 14May2003 14:15:21.98 C##BSG1 SUSAN GAYNOR C##BSG1 DINO The text message format of the alert is: Subject: Alert 1407: Superuser privileged shell obtained by user C##BSG1 Alert 1407: Superuser privileged shell obtained by user C##BSG1 The report shows the user who used su to obtain a shell with superuser privileges. This user is able to read and write any file or directory on the UNIX subsystem. Superuser privileges set on UNIX program (1408) This alert is generated if the setuid bit is set on a program owned by a UNIX superuser. A program with these privileges executes with superuser authority, and can thus access any UNIX file or data set. Note: Changing the owner to uid 0 of a program with setuid enabled resets the setuid bit, so it is not a security exposure. To receive this alert, you must have SETROPTS setting LOGOPTIONS(ALWAYS(FSSEC)) enabled. The e-mail format of the alert is: From: C2POLICE at DINO Subject: Alert: Superuser privileges set on UNIX program collogs Alert: Superuser privileges set on UNIX program collogs The setuid bit is specified on a UNIX program owned by a superuser Alert id Date and time Path User Job name System ID 1408 28Mar2003 11:49:33.66 /usr/local/bin/collogs C##BER2 ERWIN RETTICH C##BER2 DINO The text message format of the alert is: Subject: Alert 1408: Superuser privileges set on UNIX program collogs Alert 1408: Superuser privileges set on UNIX program collogs 64 User Reference Manual The alert shows the path of the program and the user who changed the permission so that the program executes with superuser privileges. If you use a CKFREEZE file created with parameter UNIX=YES, the UNIX path in the report is an absolute path. Extended attribute changed (1409) If this alert is activated, a notification message is generated when a change is detected in the extended attributes settings (APF, program control, or _BPX_SHAREAS) for a UNIX file or program. To receive this alert, the level of the z/OS system must be at least 1.11. The e-mail format of the alert is: From: C2POLICE at DINO Subject: Alert Extended attribute changed for <Unix-filename> Alert Extended attribute changed for <Unix-filename> Alert id Previous value New value Date and time Path User Job name System id 1409 <old value> <new value> Date(9) Time(11) Unix pathname User(8)Name JobName System In the e-mail notification, old value and new value can contain a combination of the following values: Shared library, APF authorized, and Program controlled. The text message format of the alert is: Subject: Alert 1409: Extended attribute changed (APS-> APS) by <userid> for <unix file name>. Alert 1409: Extended attribute changed (APS-> APS) by <userid> for <unix file name> The extended attributes of a UNIX file unix file name changed. The old and new extended attributes are shown between the parentheses. The string APS stands for the extended attributes: APF Authorized, Program controlled, and Shared Library. The command was issued by userid. RACF control alerts These alerts report on RACF SETROPTS setting changes. Global security countermeasure activated (1501) An alert is sent when a RACF SETROPTS command tightens the security of the system. Note: The condition that triggers this alert is a subset of those conditions that trigger alert 1503. The only reason to select both alerts is when you want to send them to different recipients. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Global security countermeasure activated by C##BNA2 Alert: Global security countermeasure activated by C##BNA2 SETROPTS command tightened system security Alert id Date and time RACF command 1501 23Jan2003 12:13:34.58 SETROPTS LOGOPTIONS(NEVER(FACILITY),FAILURES(DATASET)) Chapter 3. Predefined alerts 65 User Result Job name System id C##BNA2 Success C##BNA2 DINO NICK AFTERSOCK The text message format of the alert is: Subject: Alert 1501: Global security countermeasure activated by C##BNA2 Alert 1501: Global security countermeasure activated by C##BNA2: SETROPTS LOGOPTIONS(NEVER(FACILITY),FAILURES(DATASET)) PASSWORD(NOHISTORY) The alert shows the executed RACF command, the user that executed the command, and the return status of the command. Global security countermeasure deactivated (1502) An alert is generated when a RACF SETROPTS command degraded the security of the system. This alert is available separately from 1503. It ensures a more timely notification through a cell phone message when zSecure Alert is sure that a countermeasure is being deactivated. Note: The condition that triggers this alert is a subset of those conditions that trigger alert 1503. The only reason to select both alerts is when you want to send them to different recipients. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Global security countermeasure deactivated by C##BNAT Alert: Global security countermeasure deactivated by C##BNAT SETROPTS command loosened system security Alert id Date and time RACF command User Result Job name System id 1502 23Jan2003 11:51:56.01 SETROPTS NOSAUDIT C##BNAT NICK AFTERSOCK Success C##BNAT DINO The text message format of the alert is: Subject: Alert 1502: Global security countermeasure deactivated by C##BNAT Alert 1502: Global security countermeasure deactivated by C##BNAT: SETROPTS ADSP NOSAUDIT <Ignored> The alert shows the executed RACF command, the user that executed the command, and the return status of the command. Global security countermeasure or option changed (1503) An alert is generated when a RACF SETROPTS command changed the security of the system. Note: The conditions that trigger alerts 1501 and 1502 are subsets of those conditions that trigger alert 1503. The only reason to select alerts 1501 or 1052 combined with alert 1503 is when you want to send them to different recipients. The email format of the alert is: 66 User Reference Manual From: C2POLICE at DINO Subject: Alert: Global security countermeasure changed by C##BNAT Alert: Global security countermeasure changed by C##BNAT SETROPTS command changed system security Alert id Date and time RACF command User Result Job name System id 1503 23Jan2003 11:51:56.01 SETROPTS NOSAUDIT C##BNAT NICK AFTERSOCK Success C##BNAT DINO The text message format of the alert is: Subject: Alert 1503: Global security countermeasure changed by C##BNAT Alert 1503: Global security countermeasure changed by C##BNAT: SETROPTS ADSP NOSAUDIT <Ignored> The alert shows the executed RACF command, the user that executed the command, and the return status of the command. RACF Resource class activated (1504) This alert is generated when a RACF resource class is detected to have been activated. Because this alert is based on a comparison of two system snapshots, it does not provide any information about how the change was accomplished. The email format of the alert is: From: C2POLICE at IDFX Subject: Alert: RACF resource class activated: DASDVOL Alert: RACF resource class activated: DASDVOL A change in the status of a RACF resource class has been detected Alert id 1504 CLASS DASDVOL Status Active System ID IDFX The text message format of the alert is: Subject: Alert 1504: RACF resource class activated: DASDVOL Alert 1504: RACF resource class activated: DASDVOL The alert shows the resource class that was activated. Because this alert is based on a comparison of two system snapshots, it does not provide any information about how the change was accomplished. RACF Resource class deactivated (1505) This alert is generated when a RACF resource class is detected to have been deactivated. Because this alert is based on a comparison of two system snapshots, it does not provide any information about how the change was accomplished. The email format of the alert is: From: C2POLICE at IDFX Subject: Alert: RACF resource class deactivated: DASDVOL Alert: RACF resource class deactivated: DASDVOL A change in the status of a RACF resource class has been detected Chapter 3. Predefined alerts 67 Alert id 1505 CLASS DASDVOL Status Inactive System ID IDFX The text message format of the alert is: Subject: Alert 1505: RACF resource class deactivated: DASDVOL Alert 1505: RACF resource class deactivated: DASDVOL The alert shows the resource class that was deactivated. Because this alert is based on a comparison of two system snapshots, it does not provide any information about how the change was accomplished. System alerts The following alerts are for monitoring general system events. SMF data loss started (1601) This alert is generated when WTO reports that SMF data loss has started. It is reported in messages IEE351I, IEE979W, and IEE989I. Note: You can choose to activate alert 1602 so that you are notified when the immediate exposure passes. To receive this alert, you must receive WTO messages IEE351I, IEE979W, and IEE989I. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: SMF data loss started Alert: SMF data loss started System messages report that SMF data loss has started Alert id Date and time WTO message System ID 1601 10Feb2003 16:36:27.07 IEE979W SMF DATA LOST - NO BUFFER SPACE DINO The text message format of the alert is: Subject: Alert 1601: SMF data loss started. WTO msgid: IEE979W Alert 1601: SMF data loss started. WTO msgid: IEE979W The generated email contains only the issued WTO message. SMF logging resumed after failure (1602) This alert is generated when SMF data was lost due to full buffers, but the system has resumed logging. Note: You can choose to activate this alert so that you are notified when the immediate exposure indicated by alert 1601 passes. To receive this alert, you must log SMF record type 7. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: SMF logging resumed after failure 68 User Reference Manual Alert: SMF logging resumed after failure SMF data is lost, but the system has resumed logging Alert id Start of loss Date and time #records lost System ID 1602 10Feb2003 17:35:58.97 10Feb2003 17:36:27.12 4121 DINO The text message format of the alert is: Subject: Alert 1602: SMF logging resumed after failure. 4121 records lost. Alert 1602: SMF logging resumed after failure. 4121 records lost. The generated email contains the start time (Start of loss) and end time (Resume time) of the period when data was lost. It also indicates the number of SMF records that were lost. SVC definition changed (1603) This alert is generated when a change is detected in the definition of an SVC in the SVC-table or the SVC ESR-table. Because this alert is based on a comparison of two system snapshots, it does not provide any information about how the change was accomplished. The email format of the alert is: From: C2POLICE at IDFX Subject: Alert: SVC Definition changed: SVC/ESR 220 Alert: SVC Definition changed: SVC/ESR 220 A change in the definition of an SVC has been detected Alert id 1603 SVC/ESR number 220/ Address 00147080 APF Yes System ID IDEX The text message format of the alert is: Subject: Alert 1603: SVC Definition changed: SVC/ESR 220/ Alert 1603: SVC Definition changed: SVC/ESR 220/ at address 00147080 APF This alert shows the SVC and ESR number of the SVC that was changed. The current address of the SVC code is shown together with the current APF status. Because this alert is based on a comparison of two system snapshots, it does not provide any information about how the change was accomplished. IBM Health Checker found low severity problem (1604) This alert is generated when WTO reports that IBM Health Checker found a low severity problem. It is reported in message HZS0001I. To receive this alert, you must receive WTO message HZS0001I. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: IBM Health Checker found low severity problem Alert: IBM Health Checker found low severity problem Check found a problem that should be investigated Alert id 1604 Chapter 3. Predefined alerts 69 Date and time 10Feb2010 16:36:27.07 System ID DINO WTO message HZS0001I CHECK(IBMGRS,GRS_SYNCHRES): ISGH0305E Global Resource Serialization synchronous RESERVE processing is not active. The text message format of the alert is: Subject: Alert 1604: IBM Health Checker low severity: HZS0001I CHECK(IBMGRS,GRS_SYNCHRES): Alert 1604: IBM Health Checker low severity: HZS0001I CHECK(IBMGRS,GRS_SYNCHRES): IBM Health Checker found medium severity problem (1605) This alert is generated when WTO reports that IBM Health Checker found a medium severity problem. It is reported in message HZS0002E. To receive this alert, you must receive WTO message HZS0002E, The email format of the alert is: From: C2POLICE at DINO Subject: Alert: IBM Health Checker found medium severity problem Alert: IBM Health Checker found medium severity problem Check found a problem that should be investigated Alert id 1605 Date and time 10Feb2010 16:36:27.07 System ID DINO WTO message HZS0002E CHECK(IBMASM,ASM_LOCAL_SLOT_USAGE): ILRH0107E Page data set slot usage threshold met or exceeded The text message format of the alert is: Subject: Alert 1605: IBM Health Checker medium severity: HZS0002E CHECK(IBMASM,ASM_LOCAL_SLOT_USAGE): Alert 1605: IBM Health Checker medium severity: HZS0002E CHECK(IBMASM,ASM_LOCAL_SLOT_USAGE): IBM Health Checker found high severity problem (1606) This alert is generated when WTO reports that IBM Health Checker found a high severity problem. It is reported in message HZS0003E. To receive this alert, you must receive WTO message HZS0003E, The email format of the alert is: From: C2POLICE at DINO Subject: Alert: IBM Health Checker found high severity problem Alert: IBM Health Checker found high severity problem Check found a problem that should be investigated Alert id 1606 Date and time 10Feb2010 16:36:27.07 System ID DINO WTO message HZS0003E CHECK(IBMXCF,XCF_CDS_SPOF): IXCH0242E One or more couple data sets have a single point of failure. The text message format of the alert is: 70 User Reference Manual Subject: Alert 1606: IBM Health Checker high severity: HZS0003E CHECK(IBMXCF,XCF_CDS_SPOF): Alert 1606: IBM Health Checker high severity: HZS0003E CHECK(IBMXCF,XCF_CDS_SPOF): SMF record flood detected (1607) This alert is generated when WTO reports that SMF record flood is detected. It is reported in message IFA780A. To receive this alert, you must receive WTO message IFA780A. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: SMF record flood detected Alert: SMF record flood detected System messages report SMF record flood detected Alert id 1607 Date and time 03May2010 17:50:05.46 WTO message IFA780A SMF RECORD FLOOD MSG FILTER FOR TYPE 40 EXCEEDED AT TIME= System ID NMPIPL87 The text message format of the alert is: Subject: Alert 1607: SMF record flood detected. WTO msgid:IFA780A SMF RECORD FLOOD MSG FILTER FOR TYPE 40 EXCEEDED AT TIME= Alert 1607: SMF record flood detected. WTO msgid:IFA780A SMF RECORD FLOOD MSG FILTER FOR TYPE 40 EXCEEDED AT TIME= SMF record flood detected (1608) This alert is generated when WTO reports that SMF record flood starts dropping records. It is reported in message IFA782A. To receive this alert, you must receive WTO message IFA782A. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: SMF record flood starts dropping records Alert: SMF record flood starts dropping records System messages report SMF record flood starts dropping records Alert id 1608 Date and time 03May2010 17:00:00.33 WTO message IFA782A SMF RECORD FLOOD DROP FILTER FOR TYPE 74 EXCEEDED AT TIME= System ID NMPIPL87 The text message format of the alert is: Subject: Alert 1608: SMF record flood starts dropping records. WTO msgid:IFA782A SMF RECORD FLOOD DROP FILTER FOR TYPE 74 EXCEEDED AT TIME= Alert 1608: SMF record flood starts dropping records. WTO msgid:IFA782A SMF RECORD FLOOD DROP FILTER FOR TYPE 74 EXCEEDED AT TIME= Attacks blocked by filter rules are no longer logged – audit trail incomplete (1609) This alert is generated when logging for packet filtering is no longer enabled. The email format of the alert is: Chapter 3. Predefined alerts 71 From: C2POLICE at DINO Subject: Alert: Attacks blocked by filter rules are no longer logged Alert: Attacks blocked by filter rules are no longer logged audit trail incomplete in TCP/IP stack TCPIP Alert id 1609 Changed field IPSEC_LOGENABLE(Yes->No)Stack TCPIP System ID DINO The text message format of the alert is: Subject: Alert 1609: Attacks blocked by filter rules are no longer logged - audit trail incomplete in TCP/IP stack TCPIP Alert 1609: Attacks blocked by filter rules are no longer logged audit trail incomplete in TCP/IP stack TCPIP The generated email shows that the IP_STACK field IPSEC_LOGENABLE indicates that logging is not enabled for packet filtering. The alert contains the name of the changed field (IPSEC_LOGENABLE), and the old value of the field (Yes), its new value (No), and the security direction (-). Attacks blocked by default filter rules are no longer logged – audit trail incomplete (1610) This alert is generated when logging for packets that are denied by the implicit default rules is no longer enabled. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Attacks blocked by default filter rules are no longer logged Alert: Attacks blocked by default filter rules are no longer logged audit trail incomplete in TCP/IP stack TCPIP Alert id 1610 Changed field IPSEC_LOGIMPLICIT(Yes->No)Stack TCPIP System ID DINO The text message format of the alert is: Subject: Alert 1610: Attacks blocked by default filter rules are no longer logged audit trail incomplete in TCP/IP stack TCPIP Alert 1610: Attacks blocked by default filter rules are no longer logged audit trail incomplete in TCP/IP stack TCPIP The generated email shows that the IP_STACK field IPSEC_LOGIMPLICIT indicates that logging is not enabled for packets that are denied by the implicit default rules. SMF 119 subtype is no longer written - audit trail incomplete (1611) This alert is generated when SMF 119 records are no longer written when any of the following actions occur: v A user starts the FTP client command (FTPCLIENT) v Statistics related to LINK utilization become available (IFSTAT) v A tunnel is added, removed, activated, or deactivated (IPSECURITY) v Statistics related to reserved PORT utilization become available (PORTSTAT) v A TCP connection is established (TCPINIT) 72 User Reference Manual v v v v v A TCP/IP stack is activated or terminated (TCPIPSTACK) TCP/IP statistics become available (TCPIPSTAT) A TCP connection is terminated (TCPTERM) The TSO Telnet Client code starts or ends a connection (TN3270CLIENT) A UDP socket is closed (UDPTERM) The email format of the alert is: From: C2POLICE at DINO Subject: Alert: SMF 119 FTPCLIENT is no longer written by stack name Alert: SMF 119 FTPCLIENT is no longer written audit trail incomplete in TCP/IP stack TCPIP Alert id 1611 Changed field SMF119_FTPCLIENT(Yes->No)Stack TCPIP System ID DINO The text message format of the alert is: Subject: Alert 1611: SMF 119 FTPCLIENT is no longer written - audit trail incomplete in TCP/IP stack TCPIP Alert 1611: SMF 119 FTPCLIENT is no longer written audit trail incomplete in TCP/IP stack TCPIP The generated email shows that the IP_STACK flag field corresponding with the associated SMF 119 subtype indicates that records of the given subtype will not be written. IP filtering support and IPSec tunnel support deactivated (1612) This alert is generated when IPv4 or IPv6 IP filtering support and IPSec tunnel support are no longer activated. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: IPv4 IP filtering support and IPsec tunnel support deactivated Alert: IPv4 IP filtering support and IPsec tunnel support deactivated in TCP/IP stack TCPIP Alert id 1612 Changed field IPCONFIG_IPSECURITY(Yes->No)Stack TCPIP System ID DINO The text message format of the alert is: Subject: Alert 1612: IPv4 IP filtering support and IPsec tunnel support deactivated in TCP/IP stack TCPIP Alert 1612: IPv4 IP filtering support and IPsec tunnel support deactivated in TCP/IP stack TCPIP The generated email shows that the IP_STACK field IPCONFIG_IPSECURITY indicates that IPv4 IP filtering and IPSec tunnel support are not activated, or that the IP_STACK field IPCONFIG6_IPSECURITY indicates that IPv6 IP filtering and IPSec tunnel support are not activated. Ports below 1024 are not reserved anymore (1613) This alert is generated when TCP or UDP ports 1 - 1023 are no longer reserved for users by the PORT and PORTRANGE statements. Chapter 3. Predefined alerts 73 The email format of the alert is: From: C2POLICE at DINO Subject: Alert: UDP ports below 1024 are not reserved anymore by stack name Alert: UDP ports below 1024 are not reserved anymore in TCP/IP stack TCPIP Alert id 1613 Changed field UDP_RESTRICTLOWPORTS(Yes->No)Stack TCPIP System ID DINO The text message format of the alert is: Subject: Alert 1613: UDP ports below 1024 are not reserved anymore in TCP/IP stack TCPIP Alert 1613: UDP ports below 1024 are not reserved anymore in TCP/IP stack TCPIP The generated email shows that the IP_STACK field TCP_RESTRICTLOWPORTS indicates that TCP ports 1 - 1023 are not reserved for users by the PORT and PORTRANGE statements, or that the IP_STACK field UDP_RESTRICTLOWPORTS indicates that UDP ports 1 - 1023 are not reserved for users by the PORT and PORTRANGE statements. Interface security class changed (1614) This alert is generated when the security class used for IP filtering with this interface changes. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Security class changed for interface interface Alert: Interface EELINK security class has changed in TCP/IP stack TCPIP Alert id 1614 Changed field SECCLASS(255->238) Interface EELINK Security class 238 Stack TCPIP System ID DINO The text message format of the alert is: Subject: Alert 1614: Interface EELINK stack TCPIP security class has changed in TCP/IP Alert 1614: Interface EELINK security class has changed in TCP/IP stack TCPIP The generated email contains the IPv4 or IPv6 interface name, and the security class used for IP filtering with this interface. IP filter rules changed (1615) This alert is generated when an IP filter rule is changed, added, or deleted. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: IP filter rules changed in TCP/IP stack TCPIP Alert: IP filter rules changed in TCP/IP stack TCPIP Alert id 1615 Kind of change CHGChanged fields LOG(Yes->No)- 74 User Reference Manual Source IP Source prefix length Source port Destination IP Destination prefix length Destination port Protocol Type Code Packet filter logging enabled Routing Security class Stack System ID 0 0 0 0 64 0 No LOCAL 0 TCPIP DINO The text message format of the alert is: Subject: Alert 1615: IP filter rules changed in TCP/IP stack TCPIP Alert:1615: IP filter rules changed in TCP/IP stack TCPIP The generated email contains several components of the changed, added, or deleted IP filter rule: the source IP address for the outbound rule, the prefix length for the source subnet address, the source port for the outbound rule (for TCP or UDP traffic), the destination IP address for the outbound rule, the destination subnet address prefix length, the destination port for the outbound rule (matching the source port for the generated inbound rule), the type of traffic that the rule applies to, the ICMP value (for ICMP traffic), an indication whether packet filter logging is enabled for the default filter rule, the type of packet routing that the rule applies to, and the security class of the rule. Group alerts Connected to an important group (1701) This alert is generated when a userid is connected to an important group. To receive this alert, you must have SETROPTS setting SAUDIT, AUDIT(USER), or AUDIT(GROUP) enabled. The e-mail format of the alert is: From: Subject: C2POLICE at DINO Alert: C2RMUS02 issued connect to important group SYS1 for C2RMUS01 Alert: C2RMUS02 issued connect to important group SYS1 for C2RMUS01 User connected to an important group Alert id 1701 Date and time 09Mar2005 14:49:55.90 User C2RMUS01 Group SYS1 Result Success Issued by C2RMUS02 Job name C2RMUS0 System ID DINO Command CONNECT C2RMUS01 GROUP(SYS1) The text message format of the alert is: Subject: Alert 1701: Alert 1701: C2RMUS02 issued connect to important group SYS1 for C2RMUS01 C2RMUS02 issued connect to important group SYS1 for C2RMUS01 Chapter 3. Predefined alerts 75 The generated e-mail report shows which userid is connected to which important group. This alert enables you to customize the groups for your site. When selecting the alert, you are prompted with a panel where you specify up to 20 important groups. It also shows the command that was employed to connect the userid, as well as the issuer of the command. See “Important groups (1701) configuration” on page 98. Predefined ACF2 alerts This chapter describes the ACF2 alerts that are shipped with zSecure Alert. User alerts The following alerts are used to monitor events that pertain to specific users and for auditing changes to users. Logon with emergency logonid (2102) An alert is sent if a logonid that is meant for emergencies is used for TSO logon or batch job submission. To receive this alert, you must log SMF record type 30 subtype 1. The e-mail format of the alert is: From: C2POLICE at DINO Subject: Alert: Emergency user IBMUSER logged on Alert: Emergency user IBMUSER logged on Successful logon or job submit with a logonid meant for emergencies Alert id Date and time User Job name + id System ID 2102 03Feb2006 09:38:44.94 IBMUSER IBM DEFAULT USER IBMUSER TSU05900 DINO The text message format of the alert is: Subject: Alert 2102: emergency user IBMUSER logged on Alert 2102: emergency user IBMUSER logged on The generated e-mail report shows the logonid used to log on to the system and whether the logon succeeded. This alert enables you to configure the panel for your site. When selecting the alert, you are prompted with a panel. You can enter up to 10 logonids that must only be used in case of emergencies. See “Emergency user configuration (alerts 1102 and 2102)” on page 96. Highly authorized user revoked for password (2104) This alert is triggered when a user with a system-level authority (SECURITY, NON-CNCL, or READALL) is revoked because of excessive invalid password attempts. The alert can be caused by an intruder trying to guess the password. Note: You must take care not all your users with system authority get revoked at the same time. You must have some procedure to make sure at least one unrevoked logonid with SECURITY authority is reinstated. 76 User Reference Manual The e-mail format of the alert is: From: C2POLICE at DINO Subject: Alert: Highly authorized user C##CX44 revoked for password violations Alert: Highly authorized user C##CX44 revoked for password violations System-level authorized user revoked due to excessive password attempts Alert id Date and time User System ID 2104 07Feb2006 14:58:27.13 C##CX44 TEST USER DINO The text message format of the alert is: Subject: Alert 2104: Highly authorized user C##CX44 revoked for password violations Alert 2104: Highly authorized user C##CX44 revoked for password violations The report shows the logonid and accompanying name that is revoked for excessive password violations. System authority granted (2105) An alert is generated when a user obtains system-level authority (SECURITY, NON-CNCL, or READALL). The email format of the alert is: From: C2POLICE at DINO Subject: Alert: System authority granted to C##BMR2 Alert: System authority granted to C##BMR2 System-level authority granted to user Alert id Date and time Authority Granted to Logonid Job name System ID 2105 29May2006 13:25:12.42 SECURITY C##BMR2 MARY ROBERTSON C##BMR1 MARY ROBERTSON C##BMR1 DINO The text message format of the alert is: Subject: Alert 2105: System authority granted to C##BMR2 by C##BMR1 Alert 2105: System authority SECURITY granted to C##BMR2 by C##BMR1 The report shows the system authority that is granted, the user that is granted the authority, and the user that performed the ACF2 command. System authority removed (2106) An alert is sent when a system-level authority (SECURITY, NON-CNCL, or READALL) is removed from a user. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: System authority removed from C##BMR1 Alert: System authority removed from C##BMR2 System-level authority removed from user Alert id Date and time Authority 2106 29May2006 13:25:16.15 SECURITY Chapter 3. Predefined alerts 77 Removed from Logonid Job name System ID C##BMR2 MARY ROBERTSON C##BMR1 MARY ROBERTSON C##BMR1 DINO The text message format of the alert is: Subject: Alert 2106: System authority removed from C##BMR2 by C##BMR1 Alert 2106: System authority SECURITY removed from C##BMR2 by C##BMR1 The report shows the authority that is removed, the user whose authority is removed, and the user that performed the ACF2 command. Invalid password attempts exceed limit (2111) An alert is sent if too many failed logon attempts are made with an invalid password for one specific logon ID in a specific time window. The measurement interval is the sum of the REPORT options Interval and AverageInterval. See the information about the REPORT command in the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. Too many is defined as 5 attempts or more. If you want to use another limit, you must copy the alert to an installation defined alert. You must adapt all four instances of #history(nd,<5), #total(nd,>=5), in the new skeleton member to use the limit you want instead of 5. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Invalid password attempts exceed limit for C##BSG2 Alert: Invalid password attempts exceed limit for C##BSG2 Excessive number of password attempts by user Alert id Date and time Attempts User Result System ID 2111 03Mar2006 13:30:04.39 - 03Mar2003 13:39:23.78 6 C##BSG2 SUSAN GAYNOR Violation DINO The text message format of the alert is: Subject: Alert 2111: Invalid password attempts exceed limit for C##BSG2 Alert 2111: Invalid password attempts exceed limit for C##BSG2. This alert is also raised for password phrase violations. It takes into account a combined number of violations for passwords and password phrases. The generated email report shows the interval in which the logon attempts occurred and the number of attempts. It also shows the logon ID that was used for trying to log on to the system and the status of the logon. In this alert, the logons are always violations. Password history flushed (2112) An alert is sent if the password for a specific logon ID is changed more often than the password history GSO setting in a specific time window. It means that the user flushed the entire password history, enabling reuse of a previous password. The measurement interval is the sum of the REPORT options Interval and 78 User Reference Manual AverageInterval. See the information about the REPORT command in the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. Note: Alert 2112 and 2113 are related. When a report interval ends while a password history is being flushed, alert 2113 is triggered; alert 2112 occurs when flushing completes. If you receive multiple alerts 2113 for the same user without alert 2112, it is likely that the history is flushed or being flushed, but the user might have taken some more time for it. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Password history flushed for C##BSG2 Alert: Password history flushed for C##BSG2 Repeated PASSWORD commands flush password history Alert id Date and time Pwd changes User System ID 2112 05Mar2006 11:47:11.21 - 03Mar2006 11:47:12.04 33 C##BSG2 SUSAN GAYNOR DINO The text message format of the alert is: Subject: Alert 2112: Password history flushed for C##BSG2 Alert 2112: Password history flushed for C##BSG2 The generated email report shows the interval in which the password history flushing occurred, the number of password changes, and the logon ID of the user that flushed the password history of the user. Suspect password changes (2113) An alert is sent if the password for a specific logon ID is changed five times or more in a specific time window. The password change is not so often that the password history has been flushed completely, which would result in alert 2112. If you want to use another limit, you must copy the alert to an installation defined alert. Adapt all four instances of #history(nd,<5) #total(nd,>=5), in the new skeleton member to use the wanted limit instead of five. For further explanation, see "Password history flushed (2112)" in “Password history flushed (2112)” on page 78. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Suspect password changes for C##BSG2 Alert: Suspect password changes for C##BSG2 Excessive number of PASSWORD commands by user Alert id Date and time Pwd changes User System ID 2113 03Mar2006 15:17:12.32 - 03Mar2006 15:17:13.11 7 C##BSG2 SUSAN GAYNOR DINO The text message format of the alert is: Chapter 3. Predefined alerts 79 Subject: Alert 2113: Suspect password changes for C##BSG2 Alert 2113: Suspect password changes for C##BSG2 The generated email report shows the interval in which the password changes occurred, the number of password changes, and the logon ID that has its password changed many times. Too many violations (2115) This alert is generated when more violations than a configured number are recorded for a specific logon ID in the interval as specified with the REPORT option . See the information about the REPORT command in the IBM Security zSecure CARLa-Driven Components: Installation and Deployment Guide. The email format of the alert is: From: Subject: C2POLICE at DINO Alert: 15 violations recorded for user C2RMUS01 Alert: 15 violations recorded for user C2RMUS01 Number of violation exceeds the configured 10 Alert id Date and time Violations User System ID 2115 09Mar2006 14:49:55.90 - 09Mar2006 14:54:57.89 15 C2RMUS01 DINO The text message format of the alert is: Subject: Alert 2115: 15 violations recorded for user C2RMUS01 Alert 2115: 15 violations recorded for user C2RMUS01 This alert allows customization for your site. When selecting the alert you are prompted with a panel where you specify the number of violations you consider excessive. Furthermore, you can specify up to 10 logon IDs (or logon ID masks) to be excluded. See “Number of violations and logonids to exclude (2115) configuration” on page 99. SECURITY authority used by non-SECURITY logon ID (2116) An alert is generated when a user without SECURITY accesses a data set with SECURITY authority. It implies that the user without SECURITY authority can access all data sets and has the potential to successfully execute commands that require SECURITY. This condition can be set by APF-authorized software. Note: You must analyze the SMF records cut for the job up to the time the alert was issued as a first attempt to identify the responsible program. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: non-SECURITY user C##BDV1 accessed data set with SECURITY Alert: non-SECURITY user C##BDV1 accessed data set with SECURITY Successful data set access using SECURITY by user without SECURITY Alert id Date and time Data set Access 80 User Reference Manual 2116 17Jan2003 03:00:16.89 D##BEV.GBS001.D##Y.DC107SCK.BV0GBS00 UPDATE User Result Job name System ID C##BDV1 DIONNE VONT LOGGING C##BDV1 DINO The text message format of the alert is: Subject: Alert 2116: non-SECURITY user C##BDV1 accessed (UPDATE SECURITY data set D##BEV.GBS001.D##Y.DC107SCK.BV0GBS00 Alert 2116: non-SECURITY user C##BDV1 accessed (UPDATE data set D##BEV.GBS001.D##Y.DC107SCK.BV0GBS00 ) with ) with SECURITY NON-CNCL authority used by non-NON-CNCL logon ID (2117) An alert is generated when a user without NON-CNCL accesses a data set with NON-CNCL authority. It implies that the user can access all data sets. This condition can be set by APF-authorized software. Note: You must analyze the SMF records cut for the job up to the time the alert was issued as a first attempt to identify the responsible program. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: non-NON-CNCL user C##BDV1 accessed data set with NON-CNCL Alert: non-NON-CNCL user C##BDV1 accessed data set with NON-CNCL Successful data set access using NON-CNCL by user without NON-CNCL Alert id Date and time Data set Access User Result Job name System ID 2117 17Jan2003 03:00:16.89 D##BEV.GBS001.D##Y.DC107SCK.BV0GBS00 UPDATE C##BDV1 DIONNE VONT LOGGING C##BDV1 DINO The text message format of the alert is: Subject: Alert 2117: non-NON-CNCL user C##BDV1 accessed (UPDATE NON-CNCL data set D##BEV.GBS001.D##Y.DC107SCK.BV0GBS00 Alert 2117: non-NON-CNCL user C##BDV1 accessed (UPDATE data set D##BEV.GBS001.D##Y.DC107SCK.BV0GBS00 ) with ) with NON-CNCL READALL authority used by non-READALL logon ID (2118) An alert is generated when a user without READALL accesses a data set with READALL authority. It implies that the user can read all data sets. This condition can be set by APF-authorized software. Note: You must analyze the SMF records cut for the job up to the time the alert was issued as a first attempt to identify the responsible program. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: non-READALL user C##BDV1 accessed data set with READALL Alert: non-READALL user C##BDV1 accessed data set with READALL Successful data set access using READALL by user without READALL Alert id Date and time Data set 2118 17Jan2003 03:00:16.89 D##BEV.GBS001.D##Y.DC107SCK.BV0GBS00 Chapter 3. Predefined alerts 81 Access User Result Job name System ID READ C##BDV1 LOGGING C##BDV1 DINO DIONNE VONT The text message format of the alert is: Subject: Alert 2118: non-READALL user C##BDV1 accessed (READ READALL data set D##BEV.GBS001.D##Y.DC107SCK.BV0GBS00 Alert 2118: non-READALL user C##BDV1 accessed (READ data set D##BEV.GBS001.D##Y.DC107SCK.BV0GBS00 ) with ) with READALL Data set alerts This section describes the predefined alerts for data set access. WARNING mode access on data set (2201) A data set is accessed and access is granted because of warning mode. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: WARNING mode READ on data set CDS.SCDSSAMP Alert: WARNING mode READ on data set CDS.SCDSSAMP Data set access granted due to warning mode Alert id Date and time Data set Granted access Rule User Job name System ID 2201 21Jan2006 09:11:11.01 CDS.SCDSSAMP READ CDS.C##BMR1 MARY ROBERTSON C##BMR1 DINO The text message format of the alert is: Subject: Alert 2201: WARNING mode READ CDS.SCDSSAMP by C##BMR1 on data set Alert 2201: WARNING mode READ by C##BMR1 on data set CDS.SCDSSAMP The report shows the data set, the user that requested access to it, the rule against which the access is checked, and the access that is granted. A rule in WARNING mode grants any access to the resource, including what the rule would not allow otherwise. WARNING mode is typically used to analyze what the effects of the access settings of a rule are before the access control is enforced. It is used as a temporary measure to overcome production problems. If you receive these alerts, you must verify whether the access can be allowed. If so, change the access settings of the rule accordingly. If this access is not supposed to occur, take remedial action as required. Update on APF data set (2204) An alert is sent when an APF authorized data set is updated. The e-mail format of the alert is: From: C2POLICE at DINO Subject: Alert: Update by C##ASCH on APF data set C##A.D.C##NEW.APF.LOAD Alert: Update by C##ASCH on APF data set C##A.D.C##NEW.APF.LOAD 82 User Reference Manual APF data set successfully updated Alert id Date and time Data set Access User Result Job name System ID 2204 03Feb2003 10:12:05.30 C##A.D.C##NEW.APF.LOAD UPDATE C##ASCH LOGGING C##ASCHL DINO The text message format of the alert is: Subject: Alert 2204: Update by user C##ASCH C##A.D.C##NEW.APF.LOAD on APF data set Alert 2204: Update by user C##ASCH on APF data set C##A.D.C##NEW.APF.LOAD The alert shows the data set that was updated, the employed access level, and the user who accessed the data set. Data set added to APF list (2205) An alert is generated when a data set is dynamically added to the APF list using the SET PROG or SETPROG command. To generate this alert, WTO message CSV410I must be available and selected for processing. The e-mail format of the alert is: From: C2POLICE at DINO Subject: Alert: Data set added to APF list: SYSPROG.APF.LOAD Alert: Data set added to APF list: SYSPROG.APF.LOAD A data set is dynamically added to the APF list Alert id Date and time Data set Volume Console ID System ID 2205 21Feb2003 11:44:36.71 SYSPROG.APF.LOAD <SMS MANAGED> R##SLIN DINO The text message format of the alert is: Subject: Alert 2205: Data set added to APF list from console R##SLIN: SYSPROG.APF.LOAD Alert 2205: Data set added to APF list from console R##SLIN: SYSPROG.APF.LOAD on volume <SMS MANAGED> The alert shows the data set that was added to the APF list, on what volume the data set resides, or, <SMS MANAGED> if it is managed by SMS, and the name of the console from which the user entered the SET PROG or SETPROG command, if entered from SDSF, the console name defaults to the logonid of the user. Data set removed from APF list (2206) An alert is generated when a data set is dynamically removed from the APF list using the SET PROG or SETPROG command. To generate this alert, WTO message CSV410I must be available and selected for processing. Chapter 3. Predefined alerts 83 The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Data set removed from APF list: SYSPROG.APF.LOAD Alert: Data set removed from APF list: SYSPROG.APF.LOAD A data set is dynamically removed from the APF list Alert id Date and time Data set Volume Console ID System ID 2206 21Feb2003 11:44:36.71 SYSPROG.APF.LOAD <SMS MANAGED> R##SLIN DINO The text message format of the alert is: Subject: Alert 2206: Data set removed from APF list from console R##SLIN: SYSPROG.APF.LOAD Alert 2206: APF Data set removed from APF list from console R##SLIN: SYSPROG.APF.LOAD on volume <SMS MANAGED> The alert shows the data set that was removed from the APF list, on what volume the data set resides, or, <SMS MANAGED> if it is managed by SMS, and the name of the console from which the user entered the SET PROG or SETPROG command, if entered from SDSF, the console name defaults to the logon ID of the user. Data set addition to APF list detected (2207) This alert is generated when a data set is added to the APF list by any method. It includes use of the SET PROG or SETPROG command and use of other products. To generate this alert, Extended Monitoring must be active. Because this alert is based on a comparison of two system snapshots, no information is available about the user ID, jobname that was used to add the data set, or the process that was used to perform the addition. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Data set addition to APF list detected: SYSPROG.APF.LOAD Alert: Data set addition to APF list detected: SYSPROG.APF.LOAD An addition of a data set to the APF list has been detected Alert id Data set Volume System ID 2207 SYSPROG.APF.LOAD <SMS MANAGED> DINO The text message format of the alert is: Subject: Alert 2207: Data set addition to APF list detected: SYSPROG.APF.LOAD Alert 2207: Data set addition to APF list detected: SYSPROG.APF.LOAD on volume <SMS MANAGED> The alert shows the data set that was added to the APF list and the volume where the data set resides. If the data set is managed by SMS, the volume field shows <SMS MANAGED>. Because this alert is based on a comparison of two system snapshots, it does not provide any information about the user ID, jobname that was used to add the data set, or the process that was used to perform the addition. Data set removal from APF list detected (2208) This alert is generated when a data set is removed from the APF list by any method. It includes use of the SET PROG or SETPROG command and use of other 84 User Reference Manual products. To generate this alert, Extended Monitoring must be active. Because this alert is based on a comparison of two system snapshots, it does not provide any information about the userid, jobname that was used to remove the data set, or the process that was used to perform the addition. The e-mail format of the alert is: From: C2POLICE at DINO Subject: Alert: Data set removal from APF list detected: SYSPROG.APF.LOAD Alert: Data set removal from APF list detected: SYSPROG.APF.LOAD A removal of a data set from the APF list has been detected. Alert id Data set Volume System ID 2208 SYSPROG.APF.LOAD <SMS MANAGED> DINO The text message format of the alert is: Subject: Alert 2208: Data set removal from APF list detected: SYSPROG.APF.LOAD Alert 2208: Data set removal from APF list detected: SYSPROG.APF.LOAD on volume <SMS MANAGED> The alert shows the data set that was removed from the APF list and on what volume the data set resides (or <SMS MANAGED> if it is managed by SMS). Because this alert is based on a comparison of two system snapshots, it does not provide any information about the userid, jobname that was used to remove the data set, or the process that was used to perform the removal. General resource alerts These alerts report on the use of general resources. Default STC logon ID used for STC (2301) An alert is sent if a started task uses the default STC logon ID. To generate this alert, WTO message ACF9CCCD must be available and selected for processing. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: STC default LID ACFSTCID used for STC IEFBR14A Alert: STC default LID ACFSTCID used for STC IEFBR14A A started task uses the STC default logonid Alert id Date and time Logonid Started task System ID 2301 11Feb2003 18:14:48.78 ACFSTCID IEFBR14A DINO The text message format of the alert is: Subject: Alert 2301: STC default LID ACFSTCID used for STC IEFBR14A Alert 2301: STC default LID ACFSTCID used for STC IEFBR14A The report shows the ACF2 default logon ID used and the started task member name. This report does not show the user who began the started task. Chapter 3. Predefined alerts 85 You can remove the cause of this alert if you define a GSO STC record for this started task. The default logon ID is not checked anymore for this started task. UNIX alerts The following alerts are triggered when a UNIX superuser privilege is obtained. Superuser privileged shell obtained by user (2407) An alert is generated when a user used the UNIX su command to obtain a shell with superuser privileges. To receive this alert, you must have successful READ logging specified on the BPX.SUPERUSER FACILITY rule entry. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Superuser privileged shell obtained by user C##BSG1 Alert: Superuser privileged shell obtained by user C##BSG1 A user used su to obtain a shell with superuser privileges Alert id Date and time User Job name System ID 2407 14May2003 14:15:21.98 C##BSG1 SUSAN GAYNOR C##BSG1 DINO The text message format of the alert is: Subject: Alert 2407: Superuser privileged shell obtained by user C##BSG1 Alert 2407: Superuser privileged shell obtained by user C##BSG1 The report shows the user who used su to obtain a shell with superuser privileges. This user is able to read and write any file or directory on the UNIX subsystem. Extended attribute changed (2409) If this alert is activated, a notification message is generated when a change is detected in the extended attributes settings (APF, program control, or _BPX_SHAREAS) for a UNIX file or program. To receive this alert, the level of the z/OS system must be at least 1.11. The email format of the alert is: From: C2POLICE at DINO Subject: Alert Extended attribute changed for <Unix-filename> Alert Extended attribute changed for <Unix-filename> Alert id Previous value New value Date and time Path User Job name System id 2409 <old value> <new value> Date(9) Time(11) Unix pathname User(8)Name JobName System In the email notification, old value and new value can contain a combination of the following values: Shared library, APF-authorized, and Program controlled. The text message format of the alert is: 86 User Reference Manual Subject: Alert 2409: Extended attribute changed (APS-> APS) by <userid> for <unix file name>. Alert 2409: Extended attribute changed (APS-> APS) by <userid> for <unix file name> The extended attributes of a UNIX file unix file name changed. The old and new extended attributes are shown between the parentheses. The string APS stands for the extended attributes: APF Authorized, Program controlled, and Shared Library. The command was issued by userid. ACF2 control alerts These alerts report on ACF2 GSO setting changes. Global security countermeasure added (2501) An alert is sent when an ACF2 GSO setting is added. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Global security countermeasure added by C##BNA2 Alert: Global security countermeasure added by C##BNA2 ACF2 command used to add GSO setting Alert id Date and time Rule key Field/value User Job name System id 2501 23Jan2003 12:13:34.58 C-GSO-CRM PSWD WRNDAYS/5 C##BNA2 NICK AFTERSOCK C##BNA2 DINO The text message format of the alert is: Subject: Alert 2501: Global security countermeasure added by C##BNA2 Alert 2501: Global security countermeasure added by C##BNA2: C-GSO-CRM PSWD The alert shows the GSO rule key, the GSO field and its value, and the user that executed the command. For SNMP, only one GSO rule key, GSO field, and value is sent with variable whatParm. Global security countermeasure deleted (2502) An alert is sent when an ACF2 GSO setting is deleted. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Global security countermeasure deleted by C##BNA2 Alert: Global security countermeasure deleted by C##BNA2 ACF2 command used to delete GSO setting Alert id Date and time Rule key Field/value User Job name System id 2502 23Jan2003 12:13:34.58 C-GSO-CRM PSWD WRNDAYS/5 C##BNA2 NICK AFTERSOCK C##BNA2 DINO The text message format of the alert is: Subject: Alert 2502: Global security countermeasure deleted by C##BNA2 Alert 2502: Global security countermeasure deleted by C##BNA2: C-GSO-CRM PSWD Chapter 3. Predefined alerts 87 The alert shows the GSO rule key, the GSO field and its value, and the user that executed the command. For SNMP, only one GSO rule key, GSO field, and value is sent with variable whatParm. Global security countermeasure changed (2503) An alert is sent when an ACF2 GSO setting is changed. The e-mail format of the alert is: From: C2POLICE at DINO Subject: Alert: Global security countermeasure changed by C##BNA2 Alert: Global security countermeasure changed by C##BNA2 ACF2 command used to change GSO setting Alert id Date and time Rule key Field/Old/New User Job name System id 2503 23Jan2003 12:13:34.58 C-GSO-CRM PSWD WRNDAYS/5/10 C##BNA2 NICK AFTERSOCK C##BNA2 DINO The text message format of the alert is: Subject: Alert 2503: Global security countermeasure changed by C##BNA2 Alert 2503: Global security countermeasure changed by C##BNA2: C-GSO-CRM PSWD The alert shows the GSO rule key, the GSO field and its old and new values, and the user that executed the command. For SNMP, only one GSO rule key, GSO field, and value is sent with variable whatParm. System alerts The following alerts are for monitoring general system events. SMF data loss started (2601) This alert is generated when WTO reports that SMF data loss has started. It is reported in messages IEE351I, IEE979W, and IEE989I. Note: You can choose to activate alert 2602 so that you are notified when the immediate exposure passes. To receive this alert, you must receive WTO messages IEE351I, IEE979W, and IEE989I. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: SMF data loss started Alert: SMF data loss started System messages report that SMF data loss has started Alert id Date and time WTO message System ID 88 User Reference Manual 2601 10Feb2003 16:36:27.07 IEE979W SMF DATA LOST - NO BUFFER SPACE DINO The text message format of the alert is: Subject: Alert 2601: SMF data loss started. WTO msgid: IEE979W Alert 2601: SMF data loss started. WTO msgid: IEE979W The generated email contains only the issued WTO message. SMF data loss started (2602) This alert is generated when SMF data was lost due to full buffers, but the system has resumed logging. Note: You can choose to activate this alert so that you are notified when the immediate exposure indicated by alert 2601 passes. To receive this alert, you must log SMF record type 7. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: SMF logging resumed after failure Alert: SMF logging resumed after failure SMF data is lost, but the system has resumed logging Alert id Start of loss Date and time #records lost System ID 2602 10Feb2003 17:35:58.97 10Feb2003 17:36:27.12 4121 DINO The text message format of the alert is: Subject: Alert 2602: SMF logging resumed after failure. 4121 records lost. Alert 2602: SMF logging resumed after failure. 4121 records lost. The generated email contains the start time (Start of loss) and end time (Resume time) of the period when data was lost. It also shows the number of SMF records that were lost. SVC definition changed (2603) This alert is generated when a change is detected in the definition of an SVC in the SVC-table or the SVC ESR-table. Because this alert is based on a comparison of two system snapshots, it does not provide any information about how the change was accomplished. The email format of the alert is: From: C2POLICE at IDFX Subject: Alert: SVC Definition changed: SVC/ESR 220/ Alert: SVC Definition changed: SVC/ESR 220/ A change in the definition of an SVC has been detected Alert id SVC/ESR number Address APF System ID 2603 220/ 00147080 Yes IDFX The text message format of the alert is: Chapter 3. Predefined alerts 89 Subject: Alert 2603: SVC Definition changed: SVC/ESR 220/ Alert 2603: SVC Definition changed: SVC/ESR 220/ at address 00147080 APF This alert shows the SVC and ESR number of the SVC that was changed. The current address of the SVC code is shown together with the current APF status. Because this alert is generated based on a comparison of two system snapshots, no information is available about how the change was accomplished. IBM Health Checker found low severity problem (2604) This alert is generated when WTO reports that IBM Health Checker found a low severity problem. It is reported in message HZS0001I. To receive this alert, you must receive WTO message HZS0001I. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: IBM Health Checker found low severity problem Alert: IBM Health Checker found low severity problem Check found a problem that should be investigated Alert id 2604 Date and time 10Feb2010 16:36:27.07 System ID DINO WTO message HZS0001I CHECK(IBMGRS,GRS_SYNCHRES): ISGH0305E Global Resource Serialization synchronous RESERVE processing is not active. The text message format of the alert is: Subject: Alert 2604: IBM Health Checker low severity: HZS0001I CHECK(IBMGRS,GRS_SYNCHRES): Alert 2604: IBM Health Checker low severity: HZS0001I CHECK(IBMGRS,GRS_SYNCHRES): IBM Health Checker found medium severity problem (2605) This alert is generated when WTO reports that IBM Health Checker found a medium severity problem. It is reported in message HZS0002E. To receive this alert, you must receive WTO message HZS0002E, The email format of the alert is: From: C2POLICE at DINO Subject: Alert: IBM Health Checker found medium severity problem Alert: IBM Health Checker found medium severity problem Check found a problem that should be investigated Alert id 2605 Date and time 10Feb2010 16:36:27.07 System ID DINO WTO message HZS0002E CHECK(IBMASM,ASM_LOCAL_SLOT_USAGE): ILRH0107E Page data set slot usage threshold met or exceeded The text message format of the alert is: 90 User Reference Manual Subject: Alert 2605: IBM Health Checker medium severity: HZS0002E CHECK(IBMASM,ASM_LOCAL_SLOT_USAGE): Alert 2605: IBM Health Checker medium severity: HZS0002E CHECK(IBMASM,ASM_LOCAL_SLOT_USAGE): IBM Health Checker found high severity problem (2606) This alert is generated when WTO reports that IBM Health Checker found a high severity problem. It is reported in message HZS0003E. To receive this alert, you must receive WTO message HZS0003E, The email format of the alert is: From: C2POLICE at DINO Subject: Alert: IBM Health Checker found high severity problem Alert: IBM Health Checker found high severity problem Check found a problem that should be investigated Alert id 2606 Date and time 10Feb2010 16:36:27.07 System ID DINO WTO message HZS0003E CHECK(IBMXCF,XCF_CDS_SPOF): IXCH0242E One or more couple data sets have a single point of failure. The text message format of the alert is: Subject: Alert 2606: IBM Health Checker high severity: HZS0003E CHECK(IBMXCF,XCF_CDS_SPOF): Alert 2606: IBM Health Checker high severity: HZS0003E CHECK(IBMXCF,XCF_CDS_SPOF): SMF record flood detected (2607) This alert is generated when WTO reports that SMF record flood is detected. It is reported in message IFA780A. To receive this alert, you must receive WTO message IFA780A. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: SMF record flood detected Alert: SMF record flood detected System messages report SMF record flood detected Alert id 2607 Date and time 03May2010 17:50:05.46 WTO message IFA780A SMF RECORD FLOOD MSG FILTER FOR TYPE 40 EXCEEDED AT TIME= System ID NMPIPL87 The text message format of the alert is: Subject: Alert 2607: SMF record flood detected. WTO msgid:IFA780A SMF RECORD FLOOD MSG FILTER FOR TYPE 40 EXCEEDED AT TIME= Alert 2607: SMF record flood detected. WTO msgid:IFA780A SMF RECORD FLOOD MSG FILTER FOR TYPE 40 EXCEEDED AT TIME= SMF record flood detected (2608) This alert is generated when WTO reports that SMF record flood starts dropping records. It is reported in message IFA782A. To receive this alert, you must receive WTO message IFA782A. Chapter 3. Predefined alerts 91 The email format of the alert is: From: C2POLICE at DINO Subject: Alert: SMF record flood starts dropping records Alert: SMF record flood starts dropping records System messages report SMF record flood starts dropping records Alert id 2608 Date and time 03May2010 17:00:00.33 WTO message IFA782A SMF RECORD FLOOD DROP FILTER FOR TYPE 74 EXCEEDED AT TIME= System ID NMPIPL87 The text message format of the alert is: Subject: Alert 2608: SMF record flood starts dropping records. WTO msgid:IFA782A SMF RECORD FLOOD DROP FILTER FOR TYPE 74 EXCEEDED AT TIME= Alert 2608: SMF record flood starts dropping records. WTO msgid:IFA782A SMF RECORD FLOOD DROP FILTER FOR TYPE 74 EXCEEDED AT TIME= Attacks blocked by filter rules are no longer logged – audit trail incomplete (2609) This alert is generated when logging for packet filtering is no longer enabled. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Attacks blocked by filter rules are no longer logged Alert: Attacks blocked by filter rules are no longer logged audit trail incomplete in TCP/IP stack TCPIP Alert id 2609 Changed field IPSEC_LOGENABLE(Yes->No)Stack TCPIP System ID DINO The text message format of the alert is: Subject: Alert 2609: Attacks blocked by filter rules are no longer logged - audit trail incomplete in TCP/IP stack TCPIP Alert 2609: Attacks blocked by filter rules are no longer logged audit trail incomplete in TCP/IP stack TCPIP The generated email shows that the IP_STACK field IPSEC_LOGENABLE indicates that logging is not enabled for packet filtering. The alert contains the name of the changed field (IPSEC_LOGENABLE), as well as the old value of the field (Yes), its new value (No), and the security direction (-). Attacks blocked by default filter rules are no longer logged – audit trail incomplete (2610) This alert is generated when logging for packets that are denied by the implicit default rules is no longer enabled. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Attacks blocked by default filter rules are no longer logged Alert: Attacks blocked by default filter rules are no longer logged audit trail incomplete in TCP/IP stack TCPIP 92 User Reference Manual Alert id Changed field Stack System ID 2610 IPSEC_LOGIMPLICIT(Yes->No)TCPIP DINO The text message format of the alert is: Subject: Alert 2610: Attacks blocked by default filter rules are no longer logged audit trail incomplete in TCP/IP stack TCPIP Alert 2610: Attacks blocked by default filter rules are no longer logged audit trail incomplete in TCP/IP stack TCPIP The generated email shows that the IP_STACK field IPSEC_LOGIMPLICIT indicates that logging is not enabled for packets that are denied by the implicit default rules. SMF 119 subtype is no longer written - audit trail incomplete (2611) This alert is generated when SMF 119 records are no longer written when any of the following actions occur: v v v v v A user invokes the FTP client command (FTPCLIENT) Statistics related to LINK utilization become available (IFSTAT) A tunnel is added, removed, activated, or deactivated (IPSECURITY) Statistics related to reserved PORT utilization become available (PORTSTAT) A TCP connection is established (TCPINIT) v A TCP/IP stack is activated or terminated (TCPIPSTACK) v TCP/IP statistics become available (TCPIPSTAT) v A TCP connection is terminated (TCPTERM) v The TSO Telnet Client code starts or ends a connection (TN3270CLIENT) v A UDP socket is closed (UDPTERM) The e-mail format of the alert is: From: C2POLICE at DINO Subject: Alert: SMF 119 FTPCLIENT is no longer written by stack name Alert: SMF 119 FTPCLIENT is no longer written audit trail incomplete in TCP/IP stack TCPIP Alert id 2611 Changed field SMF119_FTPCLIENT(Yes->No)Stack TCPIP System ID DINO The text message format of the alert is: Subject: Alert 2611: SMF 119 FTPCLIENT is no longer written - audit trail incomplete in TCP/IP stack TCPIP Alert 2611: SMF 119 FTPCLIENT is no longer written audit trail incomplete in TCP/IP stack TCPIP The generated e-mail shows that the IP_STACK flag field corresponding with the associated SMF 119 subtype indicates that records of the given subtype will not be written. IP filtering support and IPSec tunnel support deactivated (2612) This alert is generated when IPv4 or IPv6 IP filtering support and IPSec tunnel support are no longer activated. Chapter 3. Predefined alerts 93 The email format of the alert is: From: C2POLICE at DINO Subject: Alert: IPv4 IP filtering support and IPsec tunnel support deactivated Alert: IPv4 IP filtering support and IPsec tunnel support deactivated in TCP/IP stack TCPIP Alert id 2612 Changed field IPCONFIG_IPSECURITY(Yes->No)Stack TCPIP System ID DINO The text message format of the alert is: Subject: Alert 2612: IPv4 IP filtering support and IPsec tunnel support deactivated in TCP/IP stack TCPIP Alert 2612: IPv4 IP filtering support and IPsec tunnel support deactivated in TCP/IP stack TCPIP The generated email shows that the IP_STACK field IPCONFIG_IPSECURITY indicates that IPv4 IP filtering and IPSec tunnel support are not activated, or that the IP_STACK field IPCONFIG6_IPSECURITY indicates that IPv6 IP filtering and IPSec tunnel support are not activated. Ports below 1024 are not reserved anymore (2613) This alert is generated when TCP or UDP ports 1 - 1023 are no longer reserved for users by the PORT and PORTRANGE statements. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: UDP ports below 1024 are not reserved anymore by stack name Alert: UDP ports below 1024 are not reserved anymore in TCP/IP stack TCPIP Alert id 2613 Changed field UDP_RESTRICTLOWPORTS(Yes->No)Stack TCPIP System ID DINO The text message format of the alert is: Subject: Alert 2613: UDP ports below 1024 are not reserved anymore in TCP/IP stack TCPIP Alert 2613: UDP ports below 1024 are not reserved anymore in TCP/IP stack TCPIP The generated email shows that the IP_STACK field TCP_RESTRICTLOWPORTS indicates that TCP ports 1 - 1023 are not reserved for users by the PORT and PORTRANGE statements, or that the IP_STACK field UDP_RESTRICTLOWPORTS indicates that UDP ports 1 - 1023 are not reserved for users by the PORT and PORTRANGE statements. Interface security class changed (2614) This alert is generated when the security class used for IP filtering with this interface changes. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: Security class changed for interface interface Alert: Interface EELINK security class has changed in TCP/IP stack TCPIP 94 User Reference Manual Alert id Changed field Interface Security class Stack System ID 2614 SECCLASS(255->238) EELINK 238 TCPIP DINO The text message format of the alert is: Subject: Alert 2614: Interface EELINK stack TCPIP security class has changed in TCP/IP Alert 2614: Interface EELINK security class has changed in TCP/IP stack TCPIP The generated email contains the IPv4 or IPv6 interface name, and the security class used for IP filtering with this interface. IP filter rules changed (2615) This alert is generated when an IP filter rule is changed, added, or deleted. The email format of the alert is: From: C2POLICE at DINO Subject: Alert: IP filter rules changed in TCP/IP stack TCPIP Alert: IP filter rules changed in TCP/IP stack TCPIP Alert id 2615 Kind of change CHGChanged fields LOG(Yes->No)Source IP Source prefix length 0 Source port 0 Destination IP Destination prefix length 0 Destination port 0 Protocol Type 64 Code 0 Packet filter logging enabled No Routing LOCAL Security class 0 Stack TCPIP System ID DINO The text message format of the alert is: Subject: Alert 2615: IP filter rules changed in TCP/IP stack TCPIP Alert:2615: IP filter rules changed in TCP/IP stack TCPIP The generated email contains several components of the changed, added, or deleted IP filter rule: the source IP address for the outbound rule, the prefix length for the source subnet address, the source port for the outbound rule (for TCP or UDP traffic), the destination IP address for the outbound rule, the destination subnet address prefix length, the destination port for the outbound rule (matching the source port for the generated inbound rule), the type of traffic that the rule applies to, the ICMP value (for ICMP traffic), an indication whether packet filter logging is enabled for the default filter rule, the type of packet routing that the rule applies to, and the security class of the rule. Predefined alert configuration This section explains how some of the predefined alerts can be configured with installation-specific names. Chapter 3. Predefined alerts 95 Alert definition - specify action When you select Specify action on the alert definition panel, the following panel is displayed: Menu Options Info Commands Setup _______________________________________________________________________________ zSecure Suite - Setup - Alert Command ===> _________________________________________________________________ Specify action _ TSO-RACF command _ Write TSO-RACF command to C2RCMD DD Specify command (Press Help key in this field for help) ___________________________________________________________________________ Enter up to 5 EXCLUDE condition sets (use EGN masks) X ____________________________________________________________________________ X ____________________________________________________________________________ X ____________________________________________________________________________ X ____________________________________________________________________________ X ____________________________________________________________________________ Figure 18. Setup Alert panel: Specify action The following fields are displayed: TSO-RACF command Select this field to generate a TSO-RACF command for this alert. Write TSO-RACF command to C2RCMD DD When both this field and TSO-RACF command are tagged, the generated commands are not issued, but written to the C2RCMD DD. Specify command Enter the command you want to issue for this alert. Enclose the fixed command string parts in single quotation marks ('). For example: ’ALU’ USER(0) ’REVOKE’ Enter up to 5 EXCLUDE condition sets (use EGN masks)/(use ACF2 masks). In these fields, you can enter up to 5 exclude condition sets for which no commands should be generated. For example: USER=(IBMUSER,SYS*) Emergency user configuration (alerts 1102 and 2102) The alert 1102 or 2102 means logon with emergency user. When it is selected, the following panel is displayed. You can enter up to 10 emergency users. 96 User Reference Manual Menu Options Info Commands Setup ------------------------------------------------------------------------------zSecure - Setup - Alert Command ===> _________________________________________________________________ Enter emergency users User 1 . . . . . . . IBMUSER User 2 . . . . . . . ________ User 3 . . . . . . . ________ User 4 . . . . . . . ________ User 5 . . . . . . . ________ User 6 . . . . . . . ________ User 7 . . . . . . . ________ User 8 . . . . . . . ________ User 9 . . . . . . . ________ User 10 . . . . . . . ________ Figure 19. Setup Alert panel: Configuring emergency users (alerts 1102 and 2102) panel Note: zSecure Alert expects at least one emergency user to be entered. If no input is provided, IBMUSER is used as default. Revocation for excessive violations (1115) configuration Alert 1115 means too many violations in addition to just sending the alert. This alert enables you to revoke the offending user. To be able to take the requested corrective action, the user running the started task needs sufficient authorization for the following tasks: v RACF revoke, RACF system-wide special, or group special, and so on. See RACF documentation. v CKGRACF DISABLE command authorization. The users to be managed must fall in the CKGRACF scope of the started task user. See IBM Security zSecure Admin and Audit for RACF: User Reference Manual. The following panel displays when you select this alert: Menu Options Info Commands Setup ------------------------------------------------------------------------------zSecure - Setup - Alert Command ===> _________________________________________________________________ Configure alert 1115: Too many violations Number of violations _ _ 10 Issue RACF ALTUSER REVOKE command Disable user with CKGRACF revoke schedule Exclude User 1 User 2 User 3 User 4 User 5 User 6 User 7 User 8 User 9 User 10 the . . . . . . . . . . . . . . . . . . . . following . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ________ users from revocation ________ ________ ________ ________ ________ ________ ________ ________ ________ ________ Figure 20. Setup Alert panel: Configuring revocation for excessive violations (Alert 1115) The following fields are displayed: Chapter 3. Predefined alerts 97 Number of violations The minimum number of violations allowed in the history interval as specified on the Alert Configuration general settings panel by the field Average. When the number of violations specified is exceeded, the started task might issue either a RACF or CKGRACF command to revoke the violating user. Valid values are numbers in the range 1 - 999. When not specified, a default value of 10 is used. Issue RACF ALTUSER REVOKE command When this field is selected, a RACF ALTUSER REVOKE command is issued when the number of violations specified is exceeded. Disable user with CKGRACF revoke schedule If this field is selected, a CKGRACF USER DISABLE command is issued when the number of violations specified is exceeded. This field is only available when a zSecure Admin license has been found. When this option is selected, you are required to specify the name of the revoke schedule as well. This option is mutually exclusive with Issue RACF ALTUSER REVOKE command User 1-10 These fields enable you to specify user IDs which must be excluded from revocation. It is possible to use a filter to select more than one user ID. Filters can contain %, that is, any one character, and can end in *, that is, zero or more characters. Important groups (1701) configuration When alert 1701, which means connection to an important group, is selected, the following panel is displayed: Menu Options Info Commands Setup -----------------------------------------------------------------------------zSecure - Setup - Alert Command ===> _________________________________________________________________ Specify important group(s) Group . . . . . . . SYS1 ________ ________ ________ ________ ________ ________ ________ ________ ________ ________ ________ ________ ________ ________ ________ ________ ________ ________ ________ Figure 21. Setup Alert panel: Configuring important groups (Alert 1701) This panel enables you to enter up to 20 important groups. It is possible to use a filter pattern to select more than one group. Filter patterns can contain a percent sign %, that is, one character, or can end with an asterisk *, that is, zero or more characters. 98 User Reference Manual Number of violations and logonids to exclude (2115) configuration The following panel is displayed when you select this alert: Menu Options Info Commands Setup ------------------------------------------------------------------------------zSecure - Setup - Alert Command ===> _________________________________________________________________ Configure alert 1115: Too many violations Number of violations Exclude User 1 User 2 User 3 User 4 User 5 User 6 User 7 User 8 User 9 User 10 the . . . . . . . . . . . . . . . . . . . . following . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 users from revocation . ________ . ________ . ________ . ________ . ________ . ________ . ________ . ________ . ________ . ________ Figure 22. Setup Alert panel: Configuring the number of violations and logonids to exclude (Alert 2115) The following fields are displayed: Number of violations The minimum number of violations allowed in the history interval as specified on the Alert Configuration general settings panel by the field Average. Valid values are numbers in the range 1 - 999. When not specified, a default value of 10 is used. User 1-10 These fields enable you to specify the users that must be excluded from revocation. It is possible to use a filter to select more than one user. Filters can contain *, that is, any one character, and can end in -, that is, zero or more characters. Chapter 3. Predefined alerts 99 100 User Reference Manual Chapter 4. Periodical overview A periodical overview can be sent as a reminder for the recipients and possibly served as a check on correct or changed settings. For this purpose, job C2PJRECI and procedure C2PCRECI are supplied. You must copy job C2PJRECI to a data set that is used by your job scheduling software and adapt it to your needs. Specifically, you must adapt the parameter ACONF to reflect your Alert configuration and the parameter CONFIG to reflect your zSecure Alert-enabled zSecure configuration. For general instructions for customizing zSecure-supplied jobs, see IBM Security zSecure Admin and Audit for RACF: User Reference Manual. © Copyright IBM Corp. 2002, 2012 101 102 User Reference Manual Chapter 5. Problem determination guide This chapter provides information to identify and troubleshoot problems with zSecure Alert. A general outline describes how to distinguish zSecure Collect and zSecure Alert problems from problems in zSecure Alert, and how to resolve the problems. It provides a reference for common zSecure Alert abend codes and an explanation on how to diagnose license problems. It also gives you some troubleshooting hints for situations when zSecure Alert does not generate the alerts. Information for problem diagnosis If you encounter a problem in the ISPF interface, see Chapter 2, “zSecure Alert configuration,” on page 3, or see IBM Security zSecure Admin and Audit for RACF: User Reference Manual. Information about CKFnnn messages from zSecure Collect and abends in the C2PCOLL started task (program CKFCOLL) can be found in the IBM Security zSecure Admin and Audit for RACF: User Reference Manual. For other problems, the first step is to look at the output of the zSecure Alert started task. You must decide whether you have a problem in zSecure Alert or in zSecure Audit. The zSecure Alert started task output is partially written to the spool and partially to data sets as specified in the JCL of the started task C2POLICE. CKRnnnn messages are issued by zSecure Audit. They are documented in IBM Security zSecure: Messages Guide. C2Pnnnn messages are issued by zSecure Alert. They are documented in IBM Security zSecure: Messages Guide. Message numbers in the range 0 - 999 point to the zSecure Alert started task. If the zSecure Alert started task abends, you have a zSecure Alert problem. If you get summary dumps for program C2POLICE, you have a zSecure Alert problem. If you get summary dumps for program CKRCARLA, you have a zSecure Audit problem. zSecure Audit problem diagnosis If you have a zSecure Audit problem, the next step is to figure out whether you have a problem in the stage 1 preparation subtask or in the reporting subtask. A zSecure Audit run produces SYSPRINT output. The output for the most recent stage 1 run is available in the data set allocated to the SYSPRST1 DD-name in the zSecure Alert JCL. Likewise the output for the most recent reporting run can be found from SYSPRRPT. Look at the JCL of the zSecure Alert started task to obtain the names of these data sets. Consider making a copy immediately, since these data sets are reused when zSecure Alert invokes zSecure Audit again. If zSecure Alert is still running, they might have been reused already. They might still reflect the previous completed run rather than the current one. In addition, the SYSPRINT output from any zSecure Audit invocation that ends in a nonzero Return Code is added to the C2PDEBUG file. © Copyright IBM Corp. 2002, 2012 103 The SYSPRINT must contain the input commands sent to zSecure Audit and indicative CKRnnnn messages. For diagnosing a problem report, this information is always crucial. v If the SYSPRINT for a reporting run contains an error that relates to an unresolved LIKELIST keyword reference, this points to a problem in the stage 1 run. v If the CKR messages indicate a syntax error, the most likely cause is an error in a skeleton member. See IBM Security zSecure Admin and Audit for RACF: User Reference Manual for further information. zSecure Alert problem diagnosis If zSecure Alert abends, see “General problems and abends.” If you get C2P messages that point to buffer size problems, see Chapter 2, “zSecure Alert configuration,” on page 3. For other problems, contact IBM software support and provide the following information: v A description of the circumstances under which the problem occurred v The C2POLICE message log or the relevant part of the SYSLOG v The JCL used, and the listing of the input commands. General problems and abends This section is for abends that occur in zSecure Alert. If they occur in zSecure Collect or zSecure Audit, see IBM Security zSecure Admin and Audit for RACF: User Reference Manual. The following section lists the most common system abend codes encountered with zSecure Alert and provides a suggestion for the possible cause and remedy. You must also first check the appropriate message manual for your operating system, which tells you the exact meaning of the abend and reason code. 001 Problems with blocksize. Look at the message in your joblog to determine the DD-name. If you used a concatenation for this DD-name, make sure that the largest blocksize comes first. Or, specify the larger blocksize on a DCB=BLKSIZE= parameter on the first DD statement. 047 Load module is started from a non-APF authorized library. Make sure that the C2POLICE STEPLIB is APF-authorized. 322 CPU time limit exceeded. Check the job log for prior abend messages with a different abend code. If a prior abend occurred, solve this abend. 722 Too many output lines. 80A878 GETMAIN error. Try to increase the REGION parameter on the EXEC statement. If you reached the maximum of your site, contact your system programmer. 913 104 User Reference Manual Access denied to one of the data sets. Review the ICH408I or ACF99913 messages in the job log to determine which data set. D37 B37 One of the output data sets was too small, or there was no space left on the volume to extend the data set. Look at the message in your job log to determine the DD-name. EC6 An abend EC6 means that an abend occurred while in a UNIX service. You must have the reason code to know what it is about (like CPU time limit reached - reason FD1D). For assistance with a problem by IBM Security zSecure, you must generally provide at least the SYSMDUMP, the JCL used, and the listing of the input commands. License problems zSecure Alert needs one of the zSecure Alert features to be installed and not disabled in z/OS PARMLIB member IFAPRDxx on the system where it runs. The features indicate the External Security Monitor and are represented by product codes ALERTRACF and ALERTACF2. If you have a license problem with the zSecure Alert engine (C2POLICE), look in the C2PDEBUG file. Verify whether the information shown corresponds to what you expected. Expected alerts do not show up If the expected alerts do not show up, check for these possible configuration issues: v zSecure Alert is configured to send the alert to a file, that is, option SE.A.A action R v The alert is not in the active configuration. You can find the name of the active configuration from the operator command MODIFY C2POLICE,DISPLAY . You can look for C2P messages 127, 128 and 135. Recall that you cannot dynamically change which alert configuration is used: the Refresh action does not activate a different member. The member contents might have been changed since the last stage 1 run. If you changed it, you must consider the following questions: – Did you Verify the alert configuration? – Did you issue a Refresh action to bring the configuration online? – Did the refresh succeed? You can verify it in the JESMSGLG file of the zSecure Alert started task C2POLICE, or in SYSLOG. v The alert is in the active configuration but it is not selected v The SMF logging required for the alert is not activated. You must check whether SMFPRMxx specifies that the needed SMF record types are written. For the requirements for a predefined alert, see its description in Chapter 3, “Predefined alerts,” on page 39. You can find the current SMF options from the operator command DISPLAY SMF,O. For an installation defined alert, you must check whether you specify correct filter criteria. You must also check whether the C2PCUST data set member <set name>VP contains the corresponding filter criteria. v The WTOs required for the alert are not found. You must check whether the WTO is intercepted by MPFLSTxx or by one of the MPF-related exits. It can be either IEAVMXIT or an exit routine you name on the USEREXIT parameter in PARMLIB(MPFLSTxx). For more information, see MVS Init and Tuning Reference. Chapter 5. Problem determination guide 105 In the SYSPRINT output from a reporting run, which you can see “zSecure Audit problem diagnosis” on page 103, you can see whether the alert was issued. For a WTO, CKR1239 is issued. For an SNMP trap, CKR1227 is issued. If you find this message, check on the receiving end. For an email or text message, CKR1225 is issued. If you find this message, check if the email or text message is still on the spool in the C2REMAIL file of the zSecure Alert started task C2POLICE. If so, check the SMTP settings under option SE.7 and ask your system programmer for the correct parameters. If these settings are good, you might have an SMTP problem. If the email or text message is not on the spool, it was sent by SMTP. Check the SMTP log for further diagnosis. If the SYSPRINT reveals that the alert was not issued, check for message CKR1240 (Could not resolve to any SNMP receivers). Check any messages on WTO with a nonzero Severity. If no alert is being sent and you cannot find a reason, check in the SMF log or SYSLOG for WTOs. See whether the event you are looking for was logged. For a "moving window" alert, verify that the threshold was exceeded in the time window. If none of these actions help, contact IBM software support with a description of the circumstances and the problem, the SYSPRINT from the reporting subtask, and if it seems applicable the SYSPRINT from the Stage-1 subtask as well, the JCL used, and any unexpected results encountered in the preceding diagnosis steps. 106 User Reference Manual Appendix A. SNMP output You can define your own SNMP traps. To define your SNMP traps, the LIST/SORTLIST-output must have a special form. zSecure Alert can automatically process the LIST/SORTLIST-output using NEWLIST SNMP. The special form of the output must be: specific-trap ['-c community'] ['-g global-trap'.] ['-e enterprise'] /, variable_1 <contents to be assigned to variable_1> /, variable_2 <contents to be assigned to variable_2> /, ... variable_n <contents to be assigned to variable_n> The CARLa output conforming to this template is a set of assignment statements. It is processed by NEWLIST SNMP when generating the SNMP trap. The assignments can use following predefined variables and in the Management Information Base SCKRCARL(C2PMIB)as well as integers that represent user-defined variables. The range 400000 - 699999 is reserved for user-defined variables. You must use the four digits of the SNMP trap number followed by two digits of your own choice. Your SNMP-generating code can contain: ’eventIntegral’ ’short description of the specific trap at hand’ /, ’eventWhen’ datetime(datetimezone,0) /, Here is an example of the CARLa that generates the required output: )CM SNMP sortlist )SEL &C2PERCTP = SNMP sortlist, recno(nd), ’&c2pemem.’ /, ’eventIntegral’, ’Alert: APF list changed by SETPROG APF command’ ’-’, ’System messages report that SETPROG APF command is issued’ /, ’eventWhen’ datetime(datetimezone,0) /, ’&c2pemem.00’ MsgTxt1(0,hor) /, ’whereSYSTEM’ system(0) )ENDSEL The variables in this example are ’eventIntegral’, ’eventWhen’, ’&c2pemem.00’, and ’whereSYSTEM’. The variables ’eventIntegral’, ’eventWhen’, and ’whereSYSTEM’ are predefined, while ’&c2pemem.00’ is an installation defined variable. The contents of a variable must not contain line breaks. It might have to be enforced with a repeat group format modifier firstonly, or hor. Between ’&c2pemem.’, which is called the specific-trap field, and /, on the line after recno(nd), you can insert the options -c community, -g global-trap, and -e enterprise. The default value of community is public while global-trap defaults to 6, indicating an enterprise-specific trap, and enterprise defaults to 1.3.6.1.4.1.9399.1.2, indicating enterprises.consul.software.zAlert. For information about the specific-trap, community, global-trap, and enterprise parameters, you must consult SNMP literature like RFC 1215. The following predefined variables can appear in SNMP output. © Copyright IBM Corp. 2002, 2012 107 Table 7. Predefined variables that can appear in SNMP output 108 Variable Description eventIntegral Human-readable alert title. Mostly the same as the title of the email report. eventWhen Date and time. fromWhereCONSOLE The console from which the user entered the command. fromWhereTERMINAL Terminal ID. onWhatACCESS RACF allowed access. onWhatALLOWED The access level allowed by the security rules, except for access granted because of WARNING mode; see onWhatGRANTED. onWhatAUTHORITY System-level authority that is granted or removed. onWhatCLASS The class in which a general profile resides. onWhatDSNAME Depending on the alert, the data set that is updated, on which an access attempt is made, or that is the origin of a program. onWhatGRANTED The access level granted. It includes access granted because of WARNING mode; see onWhatALLOWED. onWhatGROUP-AUTHORITY Group-level authority that is granted or removed. onWhatINTENT The access level requested. onWhatNEW-PERMISSIONS The permissions of a UNIX file or directory after a chmod command. onWhatOLD-PERMISSIONS The permissions of a UNIX file or directory before a chmod command. onWhatPATH1 Requested path name (corresponding with extended-length relocate section 263). onWhatPROFILE The general resource or data set profile that is used for access checks. onWhatRACFCMD-AUTH Connect authority used in a RACF command. onWhatRACFCMD-GROUP Group that is used in a RACF command. onWhatRACFCMD-NAME Programmer name of the user that is used in a RACF command. onWhatRACFCMD-USER User ID of the user that is used in a RACF or ACF2 command. onWhatRESOURCE The resource on which RACF or ACF2 makes access checks. This resource can be a general resource. It also can be the resource that is created from a data set name using the RACF Naming Convention Table. For SMF describing class PROGRAM, it is the name of the program that is run. onWhatUNIX-ACCESS-ALLOWED Allowed UNIX access. onWhatUNIX-ACCESS-INTENT Intended UNIX access. User Reference Manual Table 7. Predefined variables that can appear in SNMP output (continued) Variable Description onWhatUNIX-PATHNAME The absolute or relative path of a file or directory. If the CKFREEZE file used was made with UNIX=YES (and AUTOMOUNT=YES) and contains the file or directory, it is an absolute path name. onWhatVOLUME The volume on which a data set resides or <SMS MANAGED> if the data set is managed by SMS. onWhatWORKTYPE 'TSO' or 'OMVS' depending on the type of logon. whatATTEMPTS The number of attempts made. whatCOMPCODE Job or step completion code. whatCOMPSTAT Job or step completion status. whatCOUNT-SMF-LOST The number of SMF records that were lost due to full buffers. whatDESC Depending on the status of the event, this field contains Success, Undefined user, Violation, or Warning, depending on the status of the event. whatEVENT Human readable event ID. whatEVENTDESC The name of the event, an indication of the result (Success, Warning, Failure, or Undefined), and a short explanation of the event qualifier (Invalid password, for example). whatEVENTQUAL Numeric event qualifier. whatJOBID Job ID of the job in which the event triggered or which is created because of the event. whatJOBNAME Job name of the job in which the event triggered or which is created because of the event (for example, in a logon). whatJOBTAG System ID, job name, reader date, and reader time. whatLOGSTR SAF log string. whatPARM ACF2 GSO field, old value, and new value whatPROGRAM Program name. whatPWDCHANGES The number of password changes made in the last measurement interval whatRACFCMD RACF command that triggered the alert. Ignored (because of insufficient authority) keywords are labeled <IGNORED>. whatRECORDDESC A descriptive string that summarizes the record. whatRULE ACF2 rule whatSTC The name of a started task procedure. whatSTEPNAME Step name. whatSUBTYPE SMF record subtype. whatTYPE SMF numeric record type. Appendix A. SNMP output 109 Table 7. Predefined variables that can appear in SNMP output (continued) 110 Variable Description whatUACC The UACC set on a profile. whatVIOLATIONS Number of violations. whatWTO-MESSAGE The first line of output of a WTO. This line starts with the WTO message ID. whenSMF-FAILURE The start date and time of the period in which SMF data was lost due to full buffers. The end date and time can be found in the eventWhen field. whenStart Start date and start time. whereSYSTEM System name. whereSYSTYPE Operating system type. whoNAME Programmer name of the user in whoUSERID. whoUSERID User ID of the user that caused the SMF or WTO record to be written. User Reference Manual Appendix B. Tivoli Enterprise Console and NetView configuration Use the information in this appendix to: v Configure the Tivoli Enterprise Console v Configure NetView on AIX and Windows for zSecure Alert v Add a user-defined alert to a Management Information Base v Create a user-defined BAROC file with Tivoli Enterprise Console classes v Create addtrap commands for AIX and Windows systems Configuring Tivoli Enterprise Console About this task This section explains how Tivoli Enterprise Console can be configured to properly display zSecure Alert traps and user-defined zSecure Alert traps. It involves carrying out a shell script to import certain trap aspects into an SNMP trap configuration file, and importing a Basic Representation of Object in C (BAROC) Tivoli Enterprise Console configuration file into a Tivoli rule base. While you can find detailed explanation in IBM-supplied Tivoli Enterprise Console documentation at publib.boulder.ibm.com/tividd/td/EnterpriseConsole3.9.html. Some of the necessary steps are highlighted for you. Tivoli Enterprise Console version 3.9 was employed on AIX 5.2. It is assumed that you already created and activated a rule base, which is called crm_rb in this text. It is also assumed that a NetView Server Daemon (nvserverd) is running, and that the NetView trap configuration file (/usr/OV/conf/tecint.conf) indicates that the NetView Server Daemon must forward events to Tivoli Enterprise Console. Older Tivoli Enterprise Console setups might not include a nvserverd adapter. They might require some OID and CDS configuration files in addition to those scripts mentioned in this text. Such setups are not discussed here. In this text, zSecure-Alert-addtraps.sh is used as a shorthand for the IBM-supplied trap configuration shell script. Similarly, user-addtraps.sh is used as a shorthand for a user-defined trap configuration script. The Windows versions of these files are called zSecure-Alert-addtraps.bat and user-addtraps.bat. Furthermore, zSecure-Alert.baroc is a shorthand for the IBM-supplied BAROC file, while user-Alert.baroc is a shorthand for a user-defined BAROC file. Creation of user-Alert.baroc is discussed in “User-defined BAROC files with Tivoli Enterprise Console classes” on page 117 and creation of user-addtraps.sh is discussed in “Addtrap commands for AIX” on page 118. You can download the most recent versions of the IBM-supplied files in the zSecure Information Center available online at http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/ index.jsp?topic=/com.ibm.zsecure.doc_1.13/samples.html. You can also download them from the latest IBM Security zSecure: Documentation CD. The files are accessible from the "Sample (Tivoli Enterprise Console and NetView Configuration, XSLT)" entry under zSecure in the Contents panel. © Copyright IBM Corp. 2002, 2012 111 Most of the commands in the following steps require superuser privileges. It is also necessary to have the wrb and addtrap commands in your $PATH. It can be achieved by carrying out the following command, which starts with a dot and a space: . /etc/Tivoli/setup_env.sh The following commands pertain to IBM-supplied and user-defined traps. When you have no user-defined traps, you can ignore any steps that involve user-addtraps.sh and user-Alert.baroc. Procedure 1. Stop the Tivoli Enterprise Console if it is running. 2. Locate a directory with the latest version of the zSecure-Alert-addtraps.sh file. You can download this file and other configuration files to a local directory from the IBM Security zSecure information center available online. Or, you can download it from the latest IBM Security zSecure: Documentation CD. 3. Locate a directory with the latest version of the user-addtraps.sh file. 4. From the folder which contains the zSecure-Alert-addtraps.sh file, carry out sh zSecure-Alert-addtraps.sh. It puts IBM-supplied zSecure Alert definitions in the NetView trap configuration file (/usr/OV/conf/C/trapd.conf). If you carried out this step before, it replaces older IBM-supplied zSecure Alert definitions with new ones. 5. From the folder which contains the user-addtraps.sh file, carry out sh user-addtraps.sh. It puts user-defined zSecure Alert definitions in the NetView trap configuration file (/usr/OV/conf/C/trapd.conf). If you carried out this step before, it replaces older user-defined definitions with new ones. 6. Remove existing user-defined Tivoli Enterprise Console classes; this step is necessary only if you have imported user-Alert.baroc before. You must remove these classes before the next step is carried out. wrb -delrbclass user-Alert.baroc crm_rb 7. Remove existing zSecure Alert Tivoli Enterprise Console classes; this step is necessary only if you imported zSecure-Alert.baroc before: wrb -delrbclass zSecure-Alert.baroc crm_rb 8. Check whether netview.baroc has been imported. The file must be imported before the next steps can be carried out. Using the Tivoli Enterprise Console Server, you can check whether netview.baroc has been imported. In the Tivoli Enterprise Console Server Desktop for Administrator window, double-click the Event Server icon. Then in the Event Server Rule Bases window, right click the crm_rb icon, and select Import. In the Import Into Rule Bases window, the imported classes are listed below the Position to insert imported class file text. The netview.baroc file must be listed there. If it is not listed, you must import the file. 9. Import the zSecure Alert BAROC file zSecure-Alert.baroc into Tivoli: wrb -imprbclass zSecure-Alert.baroc crm_rb 10. Import the user-defined BAROC file user-Alert.baroc into Tivoli. Importing succeeds only if the previous step has been carried out. wrb -imprbclass user-Alert.baroc crm_rb 11. Compile and load the crm_rb rule base: wrb -comprules crm_rb wrb -loadrb crm_rb 12. Run the following commands to stop and restart the Tivoli Enterprise Console Event Server: 112 User Reference Manual wstopesvr wstartesvr 13. Start the Tivoli Enterprise Console. To check whether the Tivoli Enterprise Console server is running again, issue the wstatesvr command. 14. You can send a sample trap using the snmptrap command, in which you must replace 10.10.3.52 with the IP number of your computer. /usr/OV/bin/snmptrap -p 162 10.10.3.52 \ .1.3.6.1.4.1.9399.1.2 "" 6 1601 "" \ .1.3.6.1.4.1.9399.1.2.1 OctetString "Variable eventIntegral sample" \ .1.3.6.1.4.1.9399.1.2.2 OctetString "Variable eventWhen sample" \ .1.3.6.1.4.1.9399.1.2.31 OctetString "Variable whatWTO-MESSAGE sample" \ .1.3.6.1.4.1.9399.1.2.6 OctetString "Variable whereSYSTEM sample" 15. You can check whether the trap was correctly processed. You can issue the wtdumprl command and view the last few lines of its output. You can also check this using the Tivoli Enterprise Console. Configuring NetView on AIX and Windows About this task To configure NetView on AIX for zSecure Alert, you must load the (possibly user-extended) zSecure Alert MIB into NetView. Then you must carry out the sh zSecure-Alert-addtraps.sh and sh user-addtraps.sh commands. These commands are discussed in “Configuring Tivoli Enterprise Console” on page 111. It put some zSecure Alert definitions in the NetView trap configuration file /usr/OV/conf/C/trapd.conf. If you carried out these commands before, existing zSecure Alert trap definitions are replaced with new ones. Tivoli NetView version 7.1.5 was employed on AIX 5.2 to carry out the NetView configuration. You must use NetView version 7.1.5 or above. To configure NetView on Windows for zSecure Alert, you must load the (possibly user-extended) zSecure Alert MIB into NetView. Then you must perform the following steps. If you have no user-defined traps, you can ignore the steps that involve user-addtraps.bat. 1. Locate a directory with the latest version of the zSecure-Alert-addtraps.bat file. One such directory is samples on the latest IBM Security zSecure: Documentation CD. 2. Locate a directory with the latest version of the user-addtraps.bat file. 3. From the folder which contains the zSecure-Alert-addtraps.bat file, carry out zSecure-Alert-addtraps.bat. It puts the zSecure Alert definitions in the right place. If you carried out this step before, it replaces older zSecure Alert definitions with new ones. 4. From the folder which contains the user-addtraps.bat file, carry out user-addtraps.bat. It puts user-defined zSecure Alert definitions in the right place. If you carried out this step before, it replaces older user-defined definitions with new ones. To carry out these steps, NetView version 7.1.5 was employed on Microsoft Windows 2000 (Service Pack 4). If you want NetView on Windows to forward events to Tivoli Enterprise Console, you need additional configuration. To add the zSecure Alert events, you must add entries for them in the tecad_nv6k.cds and tecad_nv6k.oid files. Then rerun the configurator again or edit the conf file to include them. See IBM Tivoli Enterprise Appendix B. Configure Tivoli Enterprise Console and NetView 113 Console Adapters Guide for details on how to edit the CDS, OID, and CONF files for NetView for Windows. Add a user-defined alert to an MIB This section describes the extension of a Management Information Base (MIB) with a user-defined alert, also called a trap. An MIB can be imported by using NetView running on AIX or Windows. It is discussed in “Configuring NetView on AIX and Windows” on page 113. zSecure Alert supplies the original MIB file that is going to be extended. Its name looks like zSecure-Alert-v113.mib. The main components of a trap are variables. Although you can define a trap by using only variables defined in the zSecure Alert MIB, it is also possible to define and use additional variables. In “Variables,” it shows how variables can be defined in an MIB. These variables can be used in traps, whose definition is discussed in “TRAPS” on page 115. “Add a user-defined alert to an MIB” indicates how several MIB files can be merged. This is necessary if you have a zSecure Alert-supplied but user-extended MIB, and then receive a new zSecure Alert MIB. Variables You can choose the variables that are part of a trap from the variables already defined in the zSecure Alert-supplied MIB, but you can also define new variables, add them to the MIB, and use them in a trap. The full variable definition syntax can be found in RFC 1212 (www.faqs.org/rfcs). The following example presents you a simplified variable definition syntax and a variable definition: name OBJECT-TYPE | user-whatATTEMPTS OBJECT-TYPE SYNTAX syntax | SYNTAX DisplayString (SIZE (0..1023)) ACCESS access | ACCESS read-only STATUS status | STATUS mandatory DESCRIPTION | DESCRIPTION description | "Number of password attempts" ::= { Alert number } | ::= { Alert 400047 } A variable has the following components: name The name must start with a lowercase letter. It must consist of lowercase letters, uppercase letters, digits, and dashes (-) only. An example variable name is user-whatATTEMPTS The variable names already defined by zSecure Alert are short descriptions of alert aspects. If there are several words in a variable name, each word except the first starts with an uppercase letter justLikeThis. You can use these conventions as well. To avoid clashes with any future zSecure Alert-supplied variable names, you can put user or user- in front of each user-defined variable name, as in the sample variable user-whatATTEMPTS. Most zSecure Alert-supplied variable names contain who, what, onWhat, when, where, whereTo, or fromWhere, giving an indication of the aspect domain. Also, if there is a direct correspondence between a variable and a CARLa, or CARLa Auditing and Reporting Language, field, the variable name ends with the field name written in uppercase letters. syntax The syntax can have several forms but it typically is DisplayString (SIZE (0..1023)) 114 User Reference Manual With this form, the variable can contain 1023 characters at most. access The access can have several forms but it typically is read-only status The status can have several forms but it typically is mandatory description The description is a quoted string like "this description" number The number is a positive integer like 432100 The variable name and number must be unique in the MIB you want to extend. The MIB defines several variables with OBJECT-TYPE statements. Each statement starts with name OBJECT-TYPE and ends with ::= { Alert number } The new variable must get a name which does not yet occur in front of any OBJECT-TYPE keyword in the MIB. The new variable must get a number which does not yet occur in a ::= { Alert number } in the MIB. You must use the four digits of the trap number followed by two digits of your own choice. As indicated in “TRAPS,” a user-defined trap number must be in the range 4000-6999. Therefore, the number of a user-defined variable must be in the range 400000-699999, which is the range reserved for user-defined variables. Variable numbers outside of this range are reserved for IBM. Note: These reservations pertain to enterprise tree iso.org.dod.internet.private.enterprises.consul.software.zAlert, coded as 1.3.6.1.4.1.9399.1.2. When you determine the components of a variable definition, you add the definition to the MIB by inserting it right after an existing variable definition. The definition ends with ::= { Alert n }, in the MIB. For your convenience, sort variable definitions so their variable numbers appear in increasing order. Sorting makes it easy to see which variable numbers are already reserved. The sorting order is not mandatory. For detailed information about variables, see RFC 1212 at www.faqs.org/rfcs. TRAPS The full trap definition syntax can be found in RFC 1215 (www.faqs.org/rfcs). A simplified trap definition syntax and a sample trap definition look like this example: name TRAP-TYPE ENTERPRISE Alert VARIABLES { v1, | smfDataLost TRAP-TYPE | ENTERPRISE Alert | VARIABLES { | eventIntegral, Appendix B. Configure Tivoli Enterprise Console and NetView 115 v2, ... vm | | | } | DESCRIPTION | description | ::= number | eventWhen, whatWTO-MESSAGE, whereSYSTEM } DESCRIPTION "SMF data is lost" ::= 1601 As in the trap definition syntax, a trap definition has several components: name The name of a trap must start with a lowercase letter. It must consist of lowercase letters, uppercase letters, digits, and dashes (-) only. An example trap name is smfDataLost list of variables Variables v1, v2, . . ., vm to be sent as part of the trap. Each variable listed in the VARIABLES section of a trap must have been defined as an OBJECT-TYPE. You can read about variable definitions in “Variables” on page 114. Note: according to the MIB syntax rules, a trap with zero variables cannot have a VARIABLES { ... } section. description The trap names already defined by zSecure Alert are short descriptions of alerts. If there are several words in a trap name, each word except the first starts with an uppercase letter justLikeThis. You can use these trap naming conventions as well. The description is a quoted string like "this description" number The number is a positive integer such as: 1601 The trap name and number must not yet occur in the MIB you want to extend. To create a user-defined trap, you can simply copy a zSecure Alert-supplied trap definition. Keep the variable names and overwrite the name, description, and number with unique values. Take the following zSecure Alert-supplied trap as a starting point. smfDataLost TRAP-TYPE ENTERPRISE Alert VARIABLES { eventIntegral, eventWhen, whatWTO-MESSAGE, whereSYSTEM } DESCRIPTION "System messages report that SMF data is lost (5)" ::= 1601 The italic parts of the trap definition can be changed to obtain the following definition: mirrorGroupConnected TRAP-TYPE ENTERPRISE Alert VARIABLES { eventIntegral, eventWhen, user-whatMirrorGroup 116 User Reference Manual } DESCRIPTION "Connect to mirror group defined" ::= 4001 As you can see, two zSecure Alert-supplied variables have been retained and the other variables have been replaced by a user-defined variable userwhatMirrorGroup. Each user-defined variable must have been defined as an OBJECT-TYPE see “Variables” on page 114. The trap name and number must be unique across the zSecure Alert-defined and user-extended MIB. A new trap must get a name which does not yet occur in front of any TRAP-TYPE keyword in the MIB. The new trap must get a number which does not yet occur after any TRAP-TYPE ... ::= in the MIB. The number must be in the range 4000-6999, which is the range reserved for user-defined traps. Trap numbers outside of this range are reserved for IBM. (These reservations pertain to enterprise tree iso.org.dod.internet.private.enterprises.consul.software.zAlert, coded as 1.3.6.1.4.1.9399.1.2.) The trap number must be the same as the alert number which you see in the ISPF zSecure Alert interface. The range 4000 - 4999 is intended for RACF alerts. The range 5000 - 5999 is intended for ACF2 alerts. The range 6000 6999 is intended for ACF2 alerts. A new trap can be added to an MIB by inserting its definition after some trap ending with ::= n, where n is the trap number, which is already present in the MIB. You can sort trap definitions so their numbers appear in increasing order. Sorting makes it easy to see which trap numbers are already reserved. The sorting order is not mandatory. For detailed information about traps, refer to RFC 1215, which can be found on www.faqs.org/rfcs. MIB file merging When you add some traps and variables to an MIB and get a replacement or upgrade MIB from IBM, you must copy the customer defined traps in the range 4000-6999 and variables in the range 400000- 699999 from the old MIB to the new MIB. That ensures that the customer defined traps and variables are still recognized when you unload the old MIB file and load the new MIB file. User-defined BAROC files with Tivoli Enterprise Console classes This section describes the creation of a user-defined BAROC file. This file can be imported by Tivoli Enterprise Console as discussed in “Configuring Tivoli Enterprise Console” on page 111. While it is possible to extend the zSecure Alert BAROC file (zSecure-Alert.baroc) with classes and variables, you must create a separate BAROC file instead. You can call that file user-Alert.baroc here, but you must give it another specific name. Users must keep the zSecure Alert-supplied and the user-defined BAROC files as separate entities. You must take the definitions of the following sample user-Alert.baroc file as a starting point. Here, v1, v2, ..., vm is a list of all user-defined variables. Each # character starts a comment which runs to the end of the line. Occurrences of Appendix B. Configure Tivoli Enterprise Console and NetView 117 USER_DEFINED_ALERT can be replaced with some more appropriate phrase, like MY_COMPANY_ALERT. It is important to note that the user-defined user-Alert.baroc file depends on the zSecure-Alert.baroc file, which provides several zSecure Alert BAROC classes. TEC CLASS: USER_DEFINED_ALERT DEFINES { v1: STRING; # v2: STRING; # ... vm: STRING; # }; END ISA ZSECURE_ALERT e.g. user-whatATTEMPTS: STRING; e.g. user-whatMirrorGroup: STRING; e.g. user-whoManager: STRING; TEC CLASS: USER_DEFINED_ALERT_HARMLESS ISA USER_DEFINED_ALERT DEFINES { severity: default = HARMLESS; }; END TEC CLASS: USER_DEFINED_ALERT_UNKNOWN ISA USER_DEFINED_ALERT DEFINES { severity: default = UNKNOWN; }; END TEC CLASS: USER_DEFINED_ALERT_WARNING ISA USER_DEFINED_ALERT DEFINES { severity: default = WARNING; }; END TEC CLASS: USER_DEFINED_ALERT_MINOR ISA USER_DEFINED_ALERT DEFINES { severity: default = MINOR; }; END TEC CLASS: USER_DEFINED_ALERT_CRITICAL ISA USER_DEFINED_ALERT DEFINES { severity: default = CRITICAL; }; END TEC CLASS: USER_DEFINED_ALERT_FATAL ISA USER_DEFINED_ALERT DEFINES { severity: default = FATAL; }; END Addtrap commands for AIX This section describes the creation of a shell script with user-defined addtrap commands. The script is intended for execution on an AIX computer that runs Tivoli Enterprise Console or NetView, as discussed in “Configuring Tivoli Enterprise Console” on page 111. “Addtrap commands for Windows” on page 120 describes the creation of a script with user-defined addtrap commands for Windows computers. Each addtrap command corresponds with a single user-defined trap present in the zSecure Alert-supplied and user-extended MIB. It is discussed in “Add a user-defined alert to an MIB” on page 114. You must put the list of addtrap commands in a script separate from the zSecure Alert-supplied script. Your list of addtrap commands cannot then be accidentally lost when IBM provides a new 118 User Reference Manual script version. The script to be created can be called user-addtraps.sh in this text but you must give it another specific name. Suppose the trap numbers (to be found right after ::= operators) in the MIB are n1, n2, ..., and nm. Each of these numbers should lie in the range of 4000-6999 reserved for user-defined traps. Trap numbers outside of this range, like 1601, are reserved for IBM. Suppose the corresponding user-defined trap names, which can be found right before TRAP-TYPE keywords, in the MIB are name1, name2, ..., and namem. First assign a severity si to each user-defined trap i. A severity can be any of the following codes: 0 harmless/cleared 1 indeterminate or unknown 2 warning 3 minor 4 critical 5 major or fatal Suppose that you assign the severities s1, s2, ..., and sm to the user-defined traps. Each severity si corresponds with a class name cni: Table 8. Severity levels assigned to class names Severity Description Class name 0 harmless/cleared USER_DEFINED_ALERT_HARMLESS 1 indeterminate/unknown USER_DEFINED_ALERT_UNKNOWN 2 warning USER_DEFINED_ALERT_WARNING 3 minor USER_DEFINED_ALERT_MINOR 4 critical USER_DEFINED_ALERT_CRITICAL 5 major/fatal USER_DEFINED_ALERT_FATAL The correspondence between severities and class names is specified in the BAROC file, whose creation is described in “User-defined BAROC files with Tivoli Enterprise Console classes” on page 117. Next, devise a succinct description di of the trap. You can use the MIB description of the trap. Finally, make a list of names of variables of the traps in the order in which they occur in the MIB: vi,1, vi,2, ..., vi,j. Then for each name namei, corresponding trap number ni, severity si, class name ci, description di, and variables vi,1, vi,2, ..., vi,j, add the following lines to user-addtraps.sh: addtrap -l -i -c -D -E namei -s ni -S si -g 6 -n Alert \ 1.3.6.1.4.1.9399.1.2 -o A \ "Status Events" -e ci \ di \ ’vi,1’ -V ’$V1’ \ Appendix B. Configure Tivoli Enterprise Console and NetView 119 -E ’vi,2’ -V ’$V2’ \ ... -E ’vi,j’ -V ’$Vj’ \ -t O -f - -F ’$S $1’ Here is an example of an addtrap command, derived from the sample user-defined mirrorGroupConnected trap presented in “TRAPS” on page 115. The trap has severity 3 (-S 3), which corresponds with the USER_DEFINED_ALERT_MINOR class. addtrap -l -i -c -D -E -E -E -t mirrorGroupConnected -s 4001 -S 3 -g 6 -n Alert \ 1.3.6.1.4.1.9399.1.2 -o A \ "Status Events" -e USER_DEFINED_ALERT_MINOR \ "Connect to mirror group defined" \ ’eventIntegral’ -V ’$V1’ \ ’eventWhen’ -V ’$V2’ \ ’user-whatMirrorGroup’ -V ’$V3’ \ O -f - -F ’$S $1’ For other sample addtrap commands, you can look at the zSecure-Alertaddtraps.sh script. Note: 1. The addtrap command and its options are case-sensitive. 2. Each backslash in the command indicates that the command is continued on the next line. 3. Each variable name in that script starts with an underscore (_), unlike the variable names in the zSecure Alert-supplied MIB. The underscores ensure that the variables are grouped in trap displays. You can also put underscores in front of variable names in user-addtraps.sh. When you already have a user-addtraps.sh script and have added a number of new traps to your MIB file, you must extend user-addtraps.sh by appending lines corresponding with the new user-defined traps. Similarly, after removing a trap from the MIB, you must also remove the corresponding addtrap line from user-addtraps.sh. Finally, when you want to change some aspects of a trap such as severity, you can change the corresponding addtrap line. After creating or changing user-addtraps.sh, you must run the script to notify Tivoli Enterprise Console of new or changed traps. If you have changed aspects of user-defined traps in the Tivoli Enterprise Console user interface, you can rerun the user-addtraps.sh file to revert these aspects to the user-addtraps.shprovided values. If you do not want to change the aspects of a certain trap (for example, with name namei), you must remove the addtrap -l namei ... lines from the user-addtraps.sh file before you rerun it. Even better, do not remove the addtrap command but adjust it to reflect the current trap aspects. Addtrap commands for Windows This section describes the creation and use of a file with addtrap commands corresponding with user-defined traps in an MIB. The file is intended to be executed on a Windows computer running NetView. It is discussed in “Configuring NetView on AIX and Windows” on page 113. “Addtrap commands for AIX” on page 118 describes the creation of a script with user-defined addtrap commands for AIX computers. You must create a file user-addtraps.bat other than the zSecure Alert-supplied zSecure-Alert-addtraps.bat file with addtrap commands. This way, your 120 User Reference Manual user-defined addtrap commands cannot be lost when IBM provides a new version of zSecure-Alert-addtraps.bat. Although the file to be created can be called user-addtraps.bat in this text, you can give it another more specific name. Suppose the user-defined trap numbers, which can be found right after ::= operators, in the zSecure Alert-supplied and user-extended MIB (for example, zSecure-Alert-v113.mib) are n1, n2, ..., and nm. Each of these numbers must lie in the range of 4000-6999 reserved for user-defined traps. Trap numbers outside of this range are reserved for IBM. First assign a severity to each user-defined trap. A severity can be 0 (harmless or cleared), 1 (indeterminate or unknown), 2 (warning), 3 (minor), 4 (critical), or 5 (major or fatal). Suppose severities s1, s2, ..., and sm are assigned to the traps corresponding with trap numbers n1, n2, ..., and nm. Suppose the corresponding user-defined trap names (to be found right before TRAP-TYPE keywords) in the MIB are name1, name2, ..., and namem. Next, for each name namei, corresponding trap number ni, and corresponding severity si, add the following line to user-addtraps.bat: addtrap -l namei -s ni -S si -g 6 -n Alert -i 1.3.6.1.4.1.9399.1.2 -o A -c "Status Events" -t 0 -f - -F "$S $1\n$# args: $*" Here is an example of an addtrap command, derived from the sample user-defined mirrorGroupConnected trap presented in “TRAPS” on page 115. The trap has severity 3 (minor). addtrap -l mirrorGroupConnected -s 4001 -S 3 -g 6 -n Alert -i 1.3.6.1.4.1.9399.1.2 -o A -c "Status Events" -t 0 -f - -F "$S $1\n$# args: $*" For other sample addtrap commands, you can look at the zSecure-Alertaddtraps.bat script. The addtrap command and its options are case-sensitive. After loading the MIB, you must run user-addtraps.bat to notify NetView of certain aspects (like severity) of the user-defined traps. When you already have a file called user-addtraps.bat and a number of new user-defined traps, you can extend the user-addtraps.bat file with lines corresponding with the new user-defined traps. When you remove a user-defined trap from the MIB, you must also remove the corresponding addtrap line from the user-addtraps.bat file. Finally, when you want to change some aspects of a user-defined trap, you can change the corresponding addtrap line. After changing user-addtraps.bat, you must rerun the file to notify NetView of new or changed user-defined trap aspects. Note: If you have changed aspects of user-defined traps in NetView, you can rerun the user-addtraps.bat file to revert these aspects to the user-addtraps.bat file-provided values. If you do not want to change the aspects of a certain trap, (for example, with name namei), you must remove the addtrap -l namei ... line from the user-addtraps.bat file before you rerun it. Appendix B. Configure Tivoli Enterprise Console and NetView 121 122 User Reference Manual Notices This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. For license inquiries regarding double-byte (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan, Ltd. 1623-14, Shimotsuruma, Yamato-shi Kanagawa 242-8502 Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement might not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web © Copyright IBM Corp. 2002, 2012 123 sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact: IBM Corporation 2Z4A/101 11400 Burnet Road Austin, TX 78758 U.S.A. Such information may be available, subject to appropriate terms and conditions, including in some cases payment of a fee. The licensed program described in this document and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement or any equivalent agreement between us. Any performance data contained herein was determined in a controlled environment. Therefore, the results obtained in other operating environments may vary significantly. Some measurements may have been made on development-level systems and there is no guarantee that these measurements will be the same on generally available systems. Furthermore, some measurement may have been estimated through extrapolation. Actual results may vary. Users of this document should verify the applicable data for their specific environment. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. All statements regarding IBM's future direction or intent are subject to change or withdrawal without notice, and represent goals and objectives only. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrate programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not 124 User Reference Manual been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM‘s application programming interfaces. If you are viewing this information in softcopy form, the photographs and color illustrations might not be displayed. Trademarks IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml. Adobe, the Adobe logo, Acrobat, PostScript, and the PostScript logo are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries. IT Infrastructure Library is a registered trademark of the Central Computer and Telecommunications Agency which is now part of the Office of Government Commerce. Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo, Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office. UNIX is a registered trademark of The Open Group in the United States and other countries. Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the United States, other countries, or both and is used under license therefrom. Linear Tape-Open, LTO, the LTO Logo, Ultrium and the Ultrium Logo are trademarks of HP, IBM Corp. and Quantum in the U.S. and other countries. Other company, product, and service names may be trademarks or service marks of others. Notices 125 126 User Reference Manual Index A abend, problem determination 104 accelerator keys xi accessibility accelerator keys xi shortcut keys xi ACF2 data set alerts 82 ACF2 predefined alerts 76 ACF2 user alerts 76 add alerts 27 address lists for email 25 alert configuration process 3 layout, email 42 Alert category 20 alert configuration destinations 16 general settings 12 manage configurations 10 parameters 6 refresh 24 select alert categories 20 verify 22 Alert configuration configuration name 11 description 10 Alert Configuration Reset existing destination settings 16 Alert configuration steps 11 alert definition panel 96 alert destinations 16 Alert Destinations line command 16 alert format email 27 SNMP 27 text message 27 WTO 27 alert ID 28 Alert panel 16 alerts 1 activation guidelines 5 add user-defined to an MIB 114 Attacks blocked by default filter rules are no longer logged 72, 92 Attacks blocked by filter rules (1609) 71 Attacks blocked by filter rules are no longer logged 92 audit trail incomplete (1609) 71 audit trail incomplete (1610) 72 audit trail incomplete (1611) 72 audit trail incomplete (2609) 92 audit trail incomplete (2610) 92 audit trail incomplete (2611) 93 Audited program has been executed 58 Audited UNIX program has been executed 62 buffers 6 Catchall profile used for STC 58 © Copyright IBM Corp. 2002, 2012 alerts (continued) condition classes 5 Connect authority>=CREATE set 51 Connected to an important group 75 create 27 Data set added to APF list 83 Data set added to APF list using SETPROG 55 Data set addition to APF list detected 84 Data set addition to APF list detected (1207) 57 Data set addition to APF list detected (1208) 57 Data set removal from APF list detected 84 Data set removed from APF list 83 Data set removed from APF list using SETPROG 56 data source 28 Default STC logon ID used for STC 85 define conditions to issue 34 Extended attribute changed 61, 65, 86 Global read specified when altering file access 61 Global security countermeasure activated 65 Global security countermeasure added 87 Global security countermeasure changed 88 Global security countermeasure deactivated 66 Global security countermeasure deleted 87 Global security countermeasure or option changed 66 Global write specified when altering file 60 Group authority granted 46 Group authority removed 47 Highly authorized user revoked for password 45, 76 IBM Health Checker found high severity problem 70, 91 IBM Health Checker found low severity problem 69, 90 IBM Health Checker found medium severity problem 70, 90 installation defined 27 Interface security class changed 74, 94 intervals 6 Invalid password attempts exceed limit 49 Invalid password attempts for one specific logon ID exceed limit 78 IP filter rules changed 74, 95 alerts (continued) IP filtering support and IPSec tunnel support deactivated 73, 93 Logon by unknown user 43 Logon of user ID 44 logon with emergency logonid 76 Logon with emergency user ID 44 NON-CNCL authority used by non-NON-CNCL logon ID 81 Non-OPERATIONS user accessed data set with OPERATIONS 48 Password history flushed 50, 78 Ports below 1024 are not reserved anymore 73, 94 predefined 39 problem determination 105 RACF Resource class activated 67 RACF Resource class deactivated 67 READALL authority used by non-READALL logon ID 81 SECURITY authority used by non-SECURITY logon ID 80 SMF 119 subtype is no longer written 72, 93 SMF data loss started 68 SMF data loss started (2601) 88 SMF data loss started (2602) 89 SMF logging resumed after failure 68 SMF record flood detected (1607) 71 SMF record flood detected (1608) 71 SMF record flood detected (2607) 91 SMF record flood detected (2608) 91 SPECIAL authority used by non-SPECIAL user 48 specify destination 3 Superuser privileged shell obtained by user 64, 86 Superuser privileged UNIX program executed 63 Superuser privileges set on UNIX program 64 Suspect password changes 51, 79 SVC definition changed 69, 89 System authority granted 77 System authority removed 77 System-level authority granted 45 System-level authority removed 46 Too many violations 52, 80 types 3 UACC>=UPDATE on a DATASET profile 54 UACC>NONE on a DATASET profile 54 UNIX file access violation 60 Update on APF data set 55, 82 WARNING mode access on data set 82 WARNING mode access on data set alert 53 WARNING mode access on general resource 59 127 Attacks blocked by default filter rules are no longer logged alert 72, 92 Attacks blocked by filter rules (1609) alert 71 Attacks blocked by filter rules are no longer logged alert 92 audit trail incomplete (1609) alert 71 audit trail incomplete (1610) alert 72 audit trail incomplete (1611) 72 audit trail incomplete (2609) alert 92 audit trail incomplete (2610) alert 92 audit trail incomplete (2611) alert 93 Audited program has been executed alert 58 Audited UNIX program has been executed alert 62 AVERAGEINTERVAL buffers 6 configuration 6 User interface 14 BAROC file 117 BCC 16 books see publications vii, x buffer usage, monitor 6 Buffer number User interface 15 buffer size 6 calculating 6 configuration 6 Buffer size User interface 14 buffers for alerts 6 BUFSIZE 6 configuration 6 User interface 14 C 128 User Reference Manual D Data set added to APF list alert 83 Data set added to APF list using SETPROG alert 55 Data set addition to APF list detected (1207) alert 57 Data set addition to APF list detected (1208) alert 57 Data set addition to APF list detected alert 84 data set alerts ACF2 82 RACF 53 Data set removal from APF list detected alert 84 Data set removed from APF list alert 83 Data set removed from APF list using SETPROG alert 56 DEBUG BUFFER 6 Default STC logon ID used for STC alert 85 destination of alerts 3 B C2RSYSLG DD 16 Catchall profile used for STC alert categories of alerts 20 CC 16 CKFREEZE collect time 15 User interface 15 classes of alert conditions 5 Collect name User interface 15 Collect time User interface 15 COLLECTSTCNAME User interface 15 COLLECTTIME User interface 15 command in alert definition 37 condition classes of alerts 5 configuration alert 1102 96 alert 1701 98 alert 2102 96 alert 2115 99 configuration (continued) emergency users 96 guidelines 6 Number of violations and logonids to exclude alert 99 configuration data set 3 configurationRevocation for excessive violations alert alert 1115 97 configure alerts 3 Connect authority>=CREATE set alert 51 Connected to an important group alert 75 control alerts ACF2 87 create an alert 27 58 Environment refresh (continued) User interface 14 Extended attribute changed alert 86 61, 65, F FROM 16 G general resource alerts ACF2 85 RACF 58 Global read specified when altering file access alert 61 Global security countermeasure activated alert 65 Global security countermeasure added alert 87 Global security countermeasure changed alert 88 Global security countermeasure deactivated alert 66 Global security countermeasure deleted alert 87 Global security countermeasure or option changed alert 66 global skeleton 34 Global write specified when altering file alert 60 group alerts 75 Group authority granted alert 46 Group authority removed alert 47 GSO setting changes 87 H Highly authorized user revoked for password alert 45, 76 E I e-mail alert format 27, 42 BCC address 16 C2RSMTP DD 16 CC address 16 Font size 16 From address 16 layout 35 Output format 16 Recipient address 16 Replyto address 16 User interface 16 education see technical training xi email address lists 25 emergency user configuration 96 environment dependent selection criteria 33 Environment refresh configuration 6 problem determination 103 IBM Health Checker found high severity problem alert 70 IBM Health Checker found high severity problem alret 91 IBM Health Checker found low severity problem alert 69, 90 IBM Health Checker found medium severity problem alert 70, 90 IBM Support Assistant xii Important groups 98 in-memory buffer usage 6 information for problem diagnosis 103 installation defined alert ISPF Skeleton 28 SMF filter 28 WTO filter 28 installation defined alerts 33 add custom 27 command section 37 email layout 35 ISPF Skeleton 32 LIKELIST 34 installation defined alerts (continued) pre-selection filter 34 SNMP layout 36 stage 1 member 32 text message layout 36 UNIX syslog layout 36 installation-specific names 95 Interface security class changed alert 74, 94 INTERVAL buffers 6 configuration 6 User interface 14 intervals for alerts 6 Invalid password attempts exceed limit alert 49 Invalid password attempts for one specific logon ID exceed limit alert 78 IP filter rules changed alert 74, 95 IP filtering support and IPSec tunnel support deactivated alert 73, 93 ISPF Skeleton installation defined alert 28 issue an alert 34 L license problem diagnosis 105 licensed publications xi LIKELIST pre-selection filter 34 problem determination 104 Logon by unknown user alert 43 Logon of user ID alert 44 logon with emergency logonid alert 76 Logon with emergency user ID alert 44 M MAILFONTSIZE 16 MAILTO 16 manage alert configurations 10 manuals see publications vii, x members from verification 22 MIB file merging 117 monitor general system events 88 monitor user events ACF2 user 76 RACF user 43 Moving window buffers 6 configuration 6 User interface 14 N NetView configuration 113 NON-CNCL authority used by non-NON-CNCL logon ID alert 81 Non-OPERATIONS user accessed data set with OPERATIONS alert 48 notification methods 1 number of buffers buffers 6 number of buffers configuration NUMBUFS buffers 6 configuration User interface (continued) 6 6 15 O online publications accessing x OPTION parameter 6 ordering publications xi P panel Setup Alert 9, 20, 22, 25 panels Alert 16 parameters OPTION 6 REPORT 6 values 6 Password history flushed alert 50, 78 periodical overview 101 Ports below 1024 are not reserved anymore alert 73, 94 predefined alerts ACF2 76 ACF2 control 87 ACF2 data set 82 ACF2 system 88 ACF2 user 76 data set access 53 data set profile 53 format 42 general resource ACF2 85 general resource RACF 58 group 75 installation-specific names 95 list 39 RACF 43 RACF control 65 RACF user 43 severity levels 39 system 68 UNIX ACF2 86 UNIX RACF 60 problem determination find information for diagnosis 103 guidance 103 license 105 problem diagnosis for zSecure Alert 104 problem diagnosis for zSecure Audit 103 publications vii accessing online x licensed xi ordering xi R RACF control alerts 65 data set alerts 53 RACF (continued) predefined alerts 43 user alerts 43 RACF Resource class activated alert 67 RACF Resource class deactivated alert 67 READALL authority used by non-READALL logon ID alert 81 Refresh User interface 24 refresh alert configuration 24 REFRESH command 24 REPLYTO 16 REPORT parameter 6 Reporting interval buffers 6 configuration 6 User interface 14 Reporting run, problem determination 103 S sddtrap commands AIX 118 Windows 120 SECURITY authority used by non-SECURITY logon ID alert 80 selection criteria 33 Setup Alert panel 9, 20, 22, 25 shortcut keys xi Skeleton Global 16 SMF 119 subtype is no longer written alert 72, 93 SMF data loss started (2601) alert 88 SMF data loss started (2602) alert 89 SMF data loss started alert 68 SMF filter installation defined alert 28 SMF logging resumed after failure alert 68 SMF record flood detected (1607) alert 71 SMF record flood detected (1608) alert 71 SMF record flood detected (2607) alert 91 SMF record flood detected (2608) alert 91 SMFx User interface 28 SMTPTOFILE 16 SNMP alert format 27 C2RSNMP DD 16 layout 36 output 107 Recipient address 16 traps 107 User interface 16 SNMPTO 16 SNMPTOFILE 16 SPECIAL authority used by non-SPECIAL user alert 48 stage 1 member installation defined alert 32 Index 129 stage 1 member (continued) verify 23 STAGE1INTERVAL configuration 6 User interface 14 Superuser privileged shell obtained by user alert 64, 86 Superuser privileged UNIX program executed alert 63 Superuser privileges set on UNIX program alert 64 Support Assistant xii Suspect password changes alert 51, 79 SVC definition changed alert 69, 89 system alerts ACF2 88 general 68 System authority granted alert 77 System authority removed alert 77 System-level authority granted alert 45 System-level authority removed alert 46 22 W WARNING mode access on data set alert 53, 82 WARNING mode access on general resource alert 59 WTO alert format 27 C2RWTO DD 16 User interface 16 WTO filter installation defined alert 28 WTOTOFILE 16 WTOx User interface 28 Z zSecure Alert configure 9, 10, 12, 16 T Technical training xi text message alert format 27 From address 16 layout 36 Recipient 16 Replyto address 16 User interface 16 Tivoli Enterprise Console configuration 111 Tivoli Information Center x Too many violations alert 52, 80 training, technical xi traps definition syntax 115 variables 114 U UACC>=UPDATE on a DATASET profile alert 54 UACC>NONE on a DATASET profile alert 54 UNIX alerts ACF2 86 RACF 60 UNIX file access violation alert 60 UNIX syslog address 16 C2RSYSLG DD 16 layout 36 User interface 16 Update on APF data set alert 55, 82 user alerts ACF2 76 RACF 43 user-defined alert add to an MIB 114 V values for parameters 130 Verify User interface 6 User Reference Manual Printed in USA SC22-5467-00 ">

Public link updated
The public link to your chat has been updated.
Advertisement
Key features
- Real-time monitoring
- Alerts on important security events
- Integration with zSecure Audit
- Support for RACF and ACF2
- Multiple alert delivery methods
Frequently asked questions
IBM Security zSecure Alert is a real-time monitor for z/OS systems that issues alerts for important security events.
zSecure Alert supports both RACF and ACF2 security systems.
zSecure Alert can deliver alerts via email, text message, WTO, SNMP traps, and UNIX syslog.