SMF record enrichment

Many system management facilities (SMF) record types were designed by IBM for accounting chargeback or performance analysis purposes, not for security monitoring. In many cases, data that would be useful in a security context is not present in a particular record type. For example, SMF record type 42 (DFSMS statistics and configuration) does not contain the job ID (job number) to uniquely identify a job, and the first character does not distinguish between batch jobs, TSO sessions, and started tasks. Likewise, most records (other than RACF-generated records) do not contain any indication of the port of entry by the job entered the system.

BMC AMI Defender addresses this shortcoming by providing the missing data with each SMF record, including non-IBM SMF records. IBM Db2 SMF records (SMF record types 100, 101, and 102) are an exception—the records are complete and the Db2 environment is stable and well-known. Db2 SMF records generally originate from Db2 and not from the calling programs.

For more information about the fields that BMC AMI Defender adds, see SMF-Common-fields and the FIELDS parameter reference in Supported-API-event-types-SMF-types-and-associated-process-tags. The added fields are identified with names beginning with Event and the name without a space, for example, EventJobID.

Privilege escalation detection

Privilege escalation is the act of exploiting a bug, design flaw, or configuration oversight in an operating system or software application to gain elevated access to resources that are normally protected from an application or user. Privilege escalation is theoretically impossible on a properly configured z/OS system, according to the IBM z/OS System Integrity Statement. However, defense in depth is considered a best security practice, and in accordance with defense in depth, BMC AMI Defender implements a mechanism for detecting a certain privilege escalation technique where attackers maliciously change the in-memory privilege bits of their executing process, thereby granting themselves additional z/OS privileges (and without any audit trail). If a z/OS user has generated one or more routine BMC AMI Defender events such as by logging on or submitting jobs and then uses this technique to escalate his privileges, an appropriately configured BMC AMI Defender is sending a specific tagged field value (PrivStat: E -) to the SIEM on the very next event (file access) you generate. See the field EventPrivilege. It is expected that you would configure your SIEM to generate a high-priority alert on receipt of this indication. The BMC AMI Command Center for Security SIEM contains a preconfigured alert for this purpose.

APF status enrichment

One critical piece of data that is not present in any SMF record is the authorized program facility (APF) authorization status of any referenced data set. For example, a programmer storing a program in a load library is a common and routine event but a programmer storing a program in an APF-authorized library is an event that might be critical to the integrity of your system.

SMF provides no facility to distinguish the two events. For each SMF record type that contains a data set name, BMC AMI Defender adds the APF status of the data set to the fields available. These fields have names identical or similar to the data set name field with _APF appended, such as SMF18NDS_APF. These are Boolean fields, typically formatted as APF: Yes when appropriate. (The format is controlled by the BOOLValues parameter; see The Options Statement.) These fields are documented in FIELDS-parameter with the other fields of the relevant SMF record type. They are formatted by default for each SMF record type that represents a modification of an APF-authorized library and optionally for SMF types that represent read references to APF-authorized libraries. (See the FIELDS parameter of each SMF statement in the General-SMF-record-type-statement section.) You can also filter on the APF Status fields; see Boolean-filters. You can disable APF status enrichment if you WANT; see NOAPFENRich.

Duplicate data set names and false positives

If you have non-authorized libraries with the same data set name as an authorized library then BMC AMI Defender might report accesses to the non-authorized libraries as authorized library accesses (false positives).

For example, if you had an APF-authorized library named SYS1.CRITICAL.LOADLIB on volume 111111 and also a non-authorized library with the same name on volume 222222, then BMC AMI Defender would in most circumstances report accesses to the library on 222222 as APF-authorized accesses.

BMC AMI Defender avoids these false positives if both of the following conditions are true:

• The authorized library is not SMS-managed.
• The SMF record contains a volume serial number.

Other limitations

BMC AMI Defender builds its table of APF-authorized data sets at startup from the current APF-authorization and LNKLST lists. In IBM z/OS release V2R2, if SMF record type 90 subtype 37 is active and processed by BMC AMI Defender, it updates the APF-authorized library list following each SET PROG= and SETPROG APF command (for more information, see the IBM documentation). After BMC AMI Defender startup, you can check CZAPRINT for messages CZA0286W and CZA0358W and resolve any warnings. If you have any concerns, contact BMC Support.

If the BMC AMI Defender setting LNKAUTH=LNKLST, it treats all data sets in any LNKLST set (active or inactive at the time of BMC AMI Defender startup) as APF-authorized. z/OS has no facility to notify running programs of changes to the active LNKLST, unlike APF list changes with SMF type 90 subtype 37. If you add a library to the active LNKLST set, BMC AMI Defender reports accesses to it as APF-authorized if you explicitly APF-authorize it with SETPROG APF, ADD or refresh BMC AMI Defender APF-authorized list manually with the SET(APF) command (see MODIFY-command).

The data sets SYS1.CSSLIB and SYS1.MIGLIB, or their replacements as specified in the SYSLIB statement in the PROGxx member of the parmlib concatenation, are always treated by z/OS as APF-authorized. If you want to have accesses to these data sets reported by BMC AMI Defender as APF-authorized then add them explicitly to the APF list in PROGxx.

You might want to explicitly APF-authorize the data sets of your LPALIB concatenation.

ACF2-specific enrichment

In addition, for installations running the System Authorization Facility (SAF) product CA ACF2, BMC AMI Defender provides a number of ACF2-specific enrichment fields, including the possibility of installation-specific user LID fields. See ACF2-Specific-SMF-Common-fields and CONFIG-statement.