1 DB2 Access Recording Services Auditing DB2 on z/OS with “DBARS” A product developed by Software Product Research

Reasons for implementing DBARS Information stored in DB2 databases is of enormous value to corporations. Misuse of this information can launch competitive and legal and penalties. In many countries, laws have been instituted to protect against unauthorized disclosure of such information. While mainframe security software and DB2 privileges protect against unauthorized access to DB2 tables, they do little to report all accesses to DB2 tables and what was done within those tables. The additional layer of audit protection provided by DBARS helps companies monitor DB2 access and prevent illegitimate use.

DBARS Highlights Monitors and audits all DB2 accesses to achieve compliance with auditors and government regulations. Provides reporting facilities to support business audits and forensic investigations. Implements a customizable access blocking facility to prevent illegitimate use of the database system. Implements a customizable alerting facility to report illegitimate use of the database system. Can be integrated with external security managers. As a result of its proprietary interfaces to DB2, resource consumption is low, while performing all of the audit needs, and scaling to very high throughput environments. DBARS does not depend on DB2 tracing or the DB2 log.

DBARS Highlights (continued) Records all accesses to sensitive data in auditable DB2 tables by recording the SQL statements that perform the access. Records all DML access (SELECT, DELETE, INSERT and UPDATE). Records all DDL access (CREATE, ALTER, etc) and DB2 utilities. Records the content of input variables used by the SQL statement. Recording is performed for the DB2 tables specified in the AUDITNAMES section of the DBARS startup parameters. Stores the intercepted SQL statements into the Recorder, which is a VSAM cluster or a sequential BSAM dataset. Provides a powerful Scan utility to filter and report on audited data accesses, captured in the Recorder. Provides User Exits for customization.

Using DBARS as an Access Recorder Even when DBARS is not used in an auditing context, it still can provide valuable recording services. In development and QA environments, DBARS can show whether applications perform adequately and whether correct SQL statements are submitted. In operational environments, DBARS will record all DB2 accesses for designated tables. Using the DBARS archiving facilities, these recordings can be kept for an unlimited period of time.

DBARS Components DB2 Initiator Interface Audit Queue Writer Recorder Executes in the DB2 address space Intercepts and queues all SQL statements executed into a storage queue Blocks illegitimate DB2 access when requested by a policy rule Dynamically installed during DBARS startup with no change to the DB2 code or library Audit Queue Owned by the DBARS address space A 64-bit object, residing above the 2 Gigabyte bar Writer Executes in the DBARS address space Processes the Audit Queue entries Writes the audit records to the DBARS Recorder Issues alerts when requested by a policy rule Recorder A VSAM cluster or sequential dataset containing the audited SQL requests A shared or central Recorder is available for monitoring multiple DB2 subsystems

DBARS Utility Programs DBARSFTP Transfers the DBARS Recorder to an external FTP server. DBARSLOG Sends DBARS Alert entries to a Windows Event Log. DB2TSCAN Searches a designated database for a specified string. All tables in the database will be examined in a single program run.

DBARS Overview

Captured Audit Data Date and time of access Creator and name of the accessed table Name of DB2 subsystem accessed DB2 userid performing the access Z/OS userid performing the access DB2 connection (Batch, TSO, DDF,CICS) DB2 system sending the SQL statement Application and workstation name if distributed access Name of program performing the SQL statement Result of statement execution (SQLCODE) Number of rows modified Text of the recorded SQL statement

Alerting & Blocking Access The DBARS “Rules” dataset defines the conditions for alerting or blocking a given DB2 access. When DBARS blocks an access, the entire unit of work is rolled back. When DBARS issues an alert for a given access, the access is stored in the “Exceptions” table; if provided, a user alert exit is also invoked. A function is provided to store DBARS alerts in a Windows event log, where they can be retrieved by third-party systems (big data software for instance). Data recorded by DBARS may also be alerted and reported on by interfacing with external distributed security software. Following rule ensures that only users in the accounts receivable department can update the customer table: Block when table acr.customer and access not select and user not acr

Archive and Retrieval of DB2 audit data Procedures are provided to automatically archive the Recorder to a sequential data set or a DB2 table. Audit recording continues throughout the archiving process. The DBARS scan utility is provided for filtering and reporting of archived audit data.

DBARS Deployment Process DBARS deploys easily into existing infrastructure components. Pre/Post-Installation tasks can be performed in less than one day of effort. The required operational tasks are well within the competency of the z/OS and DB2 mainframe teams. Ongoing system maintenance is minimal as a new DB2 version or release requires only a re-bind of the DBARS packages.

Performance Benchmarks Background Information Performed alongside customer in major bank facility Workload manager priority equal to DB2 subsystem 16 GB memory available to audit queue (roughly 20% used) Conducted over 24 hour period; 4 hour batch window DBARS ALLTABLES parameter turned on resulting in over 8,000 objects from the DB2 LPAR being monitored Results Audited 220 million SQL transactions during batch window Audited 610 million SQL transactions during 24 hour test period CPU peak for batch window equaled 4% CPU over 24 hour period less than 1%

Summary – Competitive Differences DBARS does not depend on DB2 Audit tracing or the DB2 logs. Only one DBARS address space is required per DB2 subsystem. Low resource consumption while performing all of the audit needs, and scaling to very high throughput environments. A DBARS deployment fits into existing infrastructure. SPR's flexible resources continue to develop towards customer’s requirements, and are always amenable to adding new features usually in a matter of weeks.

Getting more information You may read the DBARS summary document here:: http://www.sprdb2.com/dbars/summary.htm You may request additional information here: http://www.sprdb2.com/form1.htm

End of Presentation