IBM Security Z Security

 View Only

IBM Security zSecure and Security Information and Event Management (SIEM): A History

By Jeroen Tiggelman posted Mon December 23, 2019 05:56 AM

  

This article is about the various aspects of security information and event management in connection to the mainframe. As zSecure was active in this area before it was called SIEM--and indeed even before the product was called zSecure--a look at the development of the past 20 years can be used to illustrate these aspects.


Security Information and Event Management

A Security Information and Event Management (SIEM) solution is one that deals with both Security Event Management (SEM)--that is, real-time monitoring, correlation of events, notifications, and console views--and Security Information Management (SIM)--that is, the longer term storage, analysis and reporting of those (basic and collated) events.

The acronym "SIEM" for the consolidation of the prior SEM and SIM markets as one was introduced by analyst firm Gartner in 2005.


zSecure

IBM Security zSecure is a suite of software products to help protect the IBM Z mainframe. It is rooted in development work for predecessor products that started in the late 1980s. The point products in the suite that are related to SIEM today (zSecure Audit, zSecure Alert, and zSecure Adapters for SIEM) originally hit the market as Consul/Audit (1.3.0, in 1993), Consul/zAlert (1.4.5, in 2003), and IBM Security zSecure Adapters for QRadar SIEM (2.1.1, in 2014).

The name zSecure was introduced in 2001 (when the name "z/OS" was introduced for the operating system). At the time "Consul/zSecure 1.1" indicated the combination of "Consul/zAdmin 1.1" and "Consul/zAudit 1.1". Over time "Consul zSecure suite" became a name for all the products. Following the acquisition of Consul Risk Management by IBM's Tivoli brand in 2007, all the little "z"s were expanded to "zSecure" and so it became part of the official names of each individual product.


Consul and SIM

Consul started out providing software for the IBM mainframe, but conceived in the early 1990s that there could be a market for cross-platform security administration. After reviewing the market conditions, however, it decided that it did not want to compete with the likes of Tivoli and went for cross-platform security auditing instead, delivering software originally called Consul/Enterprise Audit.

This software would collect security logs (and configuration information) from many end points on a central server and interpret them into a central security model (the General Event Model, later known as "W7") that evolved into having 7 main dimensions (Who, When, What, onWhat, ...) to categorize events. This information could be queried and also supported forensic investigations.

The need for collecting security data in one place was not primarily felt on the mainframe side, but Consul/Enterprise Audit 2.1 (1999) nevertheless delivered an "OS/390 event source". ("OS/390" was then the name of the mainframe operating system we know as "z/OS" today. An "event source" was basically an interpreter for a particular log format generated from a particular kind of end point.)

Although "log management" was considered one of the cornerstones of SIM at the time, Consul did not believe that sending full System Management Facilities (SMF) security event extract logs over the network was a viable approach. And the IBM mainframe already had good tools in place to manage SMF extracts, so there was no real need to send the data to another box. Instead, Consul/Audit pre-processed the data and wrote an alternate (proprietary) log format. (That is, a CARLa script[1] selected and formatted the relevant events from SMF.) This approach also allowed enriching the data with information gathered from the security database and the system and I/O configuration information contained in the IOCONFIG (nowadays CKFREEZE) files used with the product.

In the fourth quarter of 2005, Forrester Research cited Consul as a Leader in the SIM space with the Best Overall Strategy in its Forrester Wave. (The acquisition of a SEM solution to be integrated with Consul InSight Security Manager might have played a role in that, as by that time, the consolidated market was clearly asking for real-time event responses; but the main differentiator was InSight's focus on compliance standards like SOX and HIPAA.) Gartner cited Consul that year as a Challenger in the SIEM space. In 2006 substantial tweaking to improve performance led to the "z/OS event source", which did well in production on large enterprise systems.


Security Event Management

The focus of Security Event Management is on real-time alerting to things that happen that need a response. Correlating events that happen around the same time and detecting a pattern that should raise an alert can be a part of this.

When we speak of SEM we usually refer to a cross-platform solution that can take care of all the systems in the enterprise. For a large platform like the mainframe it is of course also possible to take care of this more locally.

zSecure Alert is the real-time monitor component of the zSecure suite. It listens to SMF events in real-time and can also pick up Write To Operator (WTO) messages. It can correlate events and send out real-time alerts through e-mail, text message, WTO console messages, Simple Network Management Protocol (SNMP) traps, or UNIX syslog receiver events. zSecure Alert can also issue commands (for example RACF commands) when an alert condition is met. The WTOs can be used to trigger your automated operations package and SNMP traps can be picked up by IBM Z Netview for z/OS or your network console. The UNIX syslog protocol can be used to send the alerts to a cross-platform SIEM solutions like IBM QRadar SIEM or Micro Focus ArcSight; the Log Event Extended Format (LEEF) and Common Event Format (CEF) expected by these products is provided out-of-the-box for the predefined alerts.

So it is possible to provide a SEM solution using zSecure:
- directly with zSecure Alert;
- by zSecure Alert sending alerts to a console or SIEM solution;
- by zSecure Audit or zSecure Adapters for SIEM sending (uncorrelated) events to a SIEM solution and rely on the SIEM solution to correlate the events.


QRadar SIEM

IBM QRadar SIEM consolidates log source event data from thousands of device endpoints and applications distributed throughout a network. It normalizes information from many Log Sources through Device Support Modules (DSMs), which are pluggable components.

The use of Log Event Extended Format (LEEF)  means that additional properties are available beyond the standard normalized set.  The DSM Configuration Guide explains how to use these (see under "IBM z/OS"). Custom event properties can be added to the QRadar SIEM reports as described in technical note "QRadar custom event properties for IBM z/OS". 

Integration with zSecure Alert was established in December 2012, via the "IBM zSecure Alert" DSM, using the "Syslog" protocol. (This is an "alert" feed.)

Integration with zSecure Audit was established in July 2012, via separate DSMs for z/OS, RACF, ACF2, Top Secret, DB2, and CICS events. Just like with the Consul SIEM solution (which after the acquisition by IBM was known as Tivoli Security Information and Event Manager) a CARLa script selects and formats relevant events from SMF (now as LEEF). There are exit points for serviceability, limiting the event selection, and adding custom events for your own SMF records. This integration originally employed file polling and FTP as the transmission method ("Log File" protocol); on the mainframe side, a job was provided to add to your job scheduling package. (This is an "event" feed.)

In December 2016 a second transmission method ("Syslog" protocol--either TCP or UDP can be employed) was provided to enable a real-time feed. A sample procedure CKQRADAR shows you how to run the (64-bit enabled) CARLa engine as a started task, using a CARLa configuration member CKQSPECL and invoking the main CARLa script CKQLEEFL (which is functionally equivalent to CKQLEEF, which is used with the other method, and imbeds the same exit points). When run as a started task, the CARLa engine will periodically restart itself automatically and listens to operator commands (such as MODIFY,RESTART). This original real-time integration required the use of SMF log streams (as opposed to data sets), as that was a requirement for the SMF in-memory (INMEM) feature used[2].

In May 2018 a new program CKQEXSMF (the zSecure SMF collector) was introduced via the zSecure 2.3.0 service stream. This eliminated the requirement to use SMF log streams for the real-time feed. The CKQEXSMF task intercepts SMF records using SMF exits. (It shares some amount of infrastructure with zSecure Alert.)

For set-up details, see section "Data preparation for SIEM" in the zSecure Installation and Deployment Guide.


Other SIEMs

It might be possible to configure some other SIEMs to consume LEEF and use the "QRadar" infrastructure directly with them. If another data format is required, this can in general be achieved by modifying the CARLa statements that specify how the selected events/alerts are formatted.

In the case of zSecure Alert, the relevant CARLa statements are in a section in the alert skeleton in the SCKRSLIB library, for example C2PS1101 for alert 1101. In 2017 another section was added to generate the Common Event Format expected by Micro Focus ArcSight out of the box (and the User Interface was adjusted for ease of use).

In 2018 CARLa script CKQCEFG was added to zSecure Audit (and zSecure Adapters for SIEM) to provide CEF output for the event feed. (This script supports both transmission methods.)


Choosing a configuration

In summary, there are ways of doing SIEM on the mainframe side or doing them in a central place for the enterprise network. What set-up works best for your installation, depends on your requirements.

If you have a SIEM solution like QRadar SIEM in place and are not particularly interested in setting up more in-depth operations on the mainframe side, then you might find that the IBM Security zSecure Adapters for SIEM product meets your needs. This product was introduced in September 2014  for clients that want to do SIEM but do not require the full power of the zSecure Audit product: it provides a functional subset that is sufficient for using the event feeds described in this article. Like zSecure Audit, it comes with separate RACF, ACF2, and Top Secret features. (The z/OS, Db2 and CICS events will be sent with any of these.)

If you want to do very in-depth event correlation, then you might want to consider a general SIEM solution (which is focused on these kinds of things). You could use zSecure Audit to send over the event data in real-time and do the rest of your processing in the SIEM solution. Of course, this means that someone in your installation needs to add appropriate rules to the SIEM solution for the (mainframe-specific) special conditions you are interested in.

If you prefer for mainframe-specific alert conditions to be specified on the mainframe side, send alerts directly to automated operations packages (or to NetView), or are not interested in sending large amounts of data across the network, then you should consider if zSecure Alert meets your needs. Note: zSecure Alert can also base alerts on zSecure Admin Access Monitor data. The Access Monitor component can summarize access requests, thus condensing security information when full SMF auditing might result in unmanageable amounts of output.

Note: if you have the zSecure Compliance and Auditing or the zSecure Compliance and Administration solution package running, then the zSecure Audit and zSecure Alert components are available as a part of that.


Staying current

zSecure regularly adds support for additional events and enhances other information in the various feeds, recently for example for z/OS Connect events and fromWhereTERMINAL alert information. Keeping current with zSecure releases is generally a good idea.

These source-side updates do not cause problems for the SIEM solutions, but in case new properties are being sent over, it is possible that those are not visible in the SIEM reports unless you also update the SIEM solution. Note: If you enable the autoupdate feature of QRadar SIEM, the DSMs will be updated to the latest levels to support additional events as soon as the QRadar SIEM support becomes available. 



If you have any questions, please ask them here or on the zSecure support forum. The IBM Security zSecure today article serves as a starting point to reach all the latest zSecure announcements.


Jeroen J.-W. Tiggelman
Software Development Manager zSecure suite
The author joined Consul as an assembler programmer for Consul/RACF and Consul/Audit in 1995


[1] The CARLa Auditing and Reporting Language (CARLa) is the common query language employed by zSecure Admin, zSecure Audit, zSecure Manager for RACF z/VM, zSecure Alert, zSecure Visual, and zSecure Adapters for SIEM. 
[2] zSecure 2.2.1 and 2.3.0 also allowed obtaining the data via IBM Common Data Provider for z/OS (CDP); this would in turn also invoke INMEM. This alternate method has been abandoned with zSecure 2.3.1.

Editorial note: Link to the acquisition news was changed to the domain of one of the venture capitalists that invested in Consul as the press release is no longer available on the IBM website.

Addition: A real-time SIEM feed with RACF events is available for z/VM as of IBM Security zSecure Manager for RACF z/VM 2.5.1 (June 2022)

0 comments
59 views

Permalink