Collection releases

Version 1.1.0

Release 1.1.0 of the ibm.ibm_eda_zos collection adds new rulebooks for detecting READ/UPDATE access to sensitive data sets and SMF record flood events. The security_alerts event filter is extended with dataset, resource, smf, and UNIX authority fields for richer event data extraction. This release also includes a Slack notification playbook for real-time alerting to security teams.

Major Changes

  • Added rulebooks for detecting READ-or-higher access to sensitive data sets (alert 1212).

  • Added rulebooks for detecting UPDATE-or-higher access to sensitive data sets (alert 1213).

  • Added rulebook for detecting SMF record flood events using two-event correlation between the IFA780A WTO message and zSecure alert C2P1607I.

  • Extended the security_alerts event filter with richer dataset, resource, SMF, and UNIX metadata extraction.

  • Added a Slack notification playbook for security alert distribution.

Minor Changes

Event filter

  • Added dataset sub-object fields: dataset_name, pds_member, volume_serial, and program_name.

  • Added resource sub-object fields: resource_class and resource_name.

  • Added smf sub-object fields: smf_record_type, smf_subsystem, smf_records_lost, and wto_msgid.

  • Added unix_path, access_level, authority_type, and user_category extraction fields.

Rulebooks

  • Added rulebook for detecting READ-or-higher access to sensitive data sets (alert 1212).

  • Added rulebook for detecting UPDATE-or-higher access to sensitive data sets (alert 1213).

  • Added rulebook for detecting SMF record flood events using two-event correlation between the IFA780A WTO message and zSecure alert C2P1607I.

Playbooks

  • Added send_slack_message playbook for sending Slack notifications to security administrators.

  • Added 1607_diagnostic playbook to display SMF output and extract the flooded SMF record type from the correlated IFA780A event.

Templates

  • Added HTML email template for SMF flood alert notifications including summary and diagnostic output.

Documentation

  • Added documentation and examples for the new monitoring scenarios.

Availability

Reference

  • Supported by IBM Ansible Content for IBM Z.

Version 1.0.0

Initial release of the ibm.ibm_eda_zos collection, that provides Event Driven Ansible solutions for IBM Z security monitoring and automated response capabilities. This collection integrates with zSecure alerts and provides comprehensive security event handling for z/OS environments.

Major Changes

  • Added security_alerts event filter plugin for processing zSecure alerts from Kafka.

  • Initial release of ibm.ibm_eda_zos collection for Event Driven Ansible on IBM Z.

Minor Changes

Documentation

  • Add documentation for collection usage and examples.

Rulebooks

  • Added rulebook for detecting invalid password limit exceeded events (alert 1111).

  • Added rulebook for detecting logon attempts by unknown users (alert 1101).

  • Added rulebook for monitoring superuser logon events (alert 1103).

  • Added rulebook for tracking group authorization status changes (alerts 1107/1108).

Playbooks

  • Created gather_listuser_information playbook for user account details.

  • Created gather_password_policy_information playbook for policy compliance checks.

  • Created quarantine_user playbook for automated account suspension.

  • Created remove_uid_access playbook for emergency access revocation.

  • Created send_alert_email playbook for security notification distribution.

  • Created setr_jes_batchallracf playbook for JES batch security configuration.

  • Created unquarantine_user playbook for account restoration.

Templates

  • Added HTML email templates for formatted security alert notifications with alert-specific layouts.

  • Included base template with consistent styling and reusable components for RACF user information.

Availability

Reference

  • Supported by IBM Ansible Content for IBM Z.

Known Issues

Alert Format Compatibility

The security_alerts event filter extracts attributes based on user-specific zSecure alert message patterns. Some custom or non-standard alert formats may not be fully parsed.

Workaround: For unsupported formats, you can use Ansible-supported operators in rule conditions to identify specific alerts, and Jinja2 filters (including Python string methods) in the action section to extract data for playbook variables.

Example for Event Structure

Below is an example of an incoming Kafka event for alert “Update on APF data set (1204)”:

{
  "headerName": "zOS-SYSLOG-Console:1.0.0",
  "hasHeaderTopic": "true",
  "metadata": "sample_host.ibm.com,SYSLOG,1.0.0,zOS-SYSLOG-Console,ZOS_HOST-SYSLOG,-0400,XESDEV,ZOS_HOST,1774419235120",
  "message": "NC,002B,26083 23.13.55.120 -0700,ZOS_HOST,TSU00121,USRT004 ,00000000000000000000000000000000,00000210,USRT004 ,80,\" C2P1204I Update by user C##ASCH on APF data set C##A.D.C##NEW.APF.LOAD\""
}

Custom Parsing Example

The following rulebook demonstrates how to parse custom alert formats using Ansible operators in conditions and Jinja2 filters in actions:

- name: Process APF dataset alert
  hosts: all
  sources:
    - ansible.eda.kafka:
        host: localhost
        port: 9092
        topic: zsecure-alerts
  rules:
    - name: Extract username and dataset from APF alert
      # Condition: Use Ansible operator to match specific alert code C2P1204I
      condition: event.body.message is search("C2P1204I", ignore_case=false)

      action:
        run_playbook:
          name: handle_apf_alert.yml
          extra_vars:
            # Action: Use Jinja2 filters to extract username (C##ASCH) and
            # dataset name (C##A.D.C##NEW.APF.LOAD) to pass to playbook
            username: "{{ event.body.message.split('user')[1].strip().split()[0] }}"
            dataset_name: "{{ event.body.message.split('data set')[1].strip().split()[0] }}"
            full_event: "{{ event }}"

This approach allows you to handle any alert format by customizing the parsing logic in your rulebooks.