SMF record enrichment

Many SMF record types were designed by IBM primarily for accounting chargeback or performance analysis purposes and not with security monitoring as a primary consideration. In many cases data that would be useful in a security context are not present in a particular record type.

BMC AMI Defender addresses this shortcoming by providing the missing data with each SMF record, including non-IBM SMF records, with the exception of  DB2 SMF records.

Primarily, these additional fields are documented under SMF-Common-fields. The added fields are identified with names beginning with Event (mixed case) not followed by an underscore, 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 changes 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 such an alert pre-configured.

APF status enrichment

One critical piece of data that is not present in any SMF record is the APF authorization status of any referenced data set. 

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).

BMC AMI Defender is able to avoid these false positives only if both (a.) the authorized library is not SMS-managed and (b.) the SMF record contains a volume serial number (or, of course, if you do not have duplicate APF-authorized library names).

Other limitations

BMC AMI Defender builds its table of APF-authorized data sets at startup from the current APF-authorization and LNKLST lists. On z/OS release V2R2, and assuming SMF type 90 subtype 37 is active and being 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. You should check CZAPRINT following BMC AMI Defender startup for messages CZA0286W and or CZA0358W and resolve any warnings indicated. If you have any concerns, contact BMC Support.

BMC AMI Defender has the setting of LNKAUTH and if LNKAUTH=LNKLST 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 and to have BMC AMI Defender report accesses to it as APF-authorized then you should either 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 you should add them explicitly to the APF list in PROGxx.

You might wish 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.