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

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

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

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

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

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

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

8. DBARS Overview

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

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

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

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

13. 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%

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

15. Getting more information
You may read the DBARS summary document here::
You may request additional information here:

16. End of Presentation