S-TAP for DB2 on z/OS V10€¦ · © 2016 IBM Corporation 6 Audited events collected Security Guardium S-TAP for DB2 collects and correlates the following types of data – DML (Data

© 2016 IBM Corporation

Best practices for optimizing data collection

Chris BornDevelopment for Database Tools Monitoring Compliance z/OS LabRocket Software

May 25, 2016

S-TAP for DB2 on z/OS V10.0

2© 2016 IBM Corporation

A smarter way to tackle data security: Guardiumenhancements

Speakers:David Rozenblat, Guardium Director of DevelopmentKathy ZeidensteinDate and time: June 2, 201608:00 AM PDT, 11:00 AM EDTRegister here: http://ibm.biz/GTech10one

Upcoming Tech Talks

http://ibm.biz/GTech10one

http://ibm.biz/GTech10one


Agenda

Overview of Guardium components for z/OS

Data collection

Collection profile policy

Logging rule and special action

Multistream and failover


Collect audit events of access to DB2 Databases on z/OS

DB2 S-TAP on Z

– Collects and correlates data access information from a variety of DB2 resources to produce a comprehensive view

of business activity for auditors

– Collection based on collection profile policy, filtered at collection point

• Authorization IDs, Objects, Plans, Programs, connection information etc.

– Collection via shared DB2 Subsystem intercepts and IFI Audit Trace

– TCP/IP stream audit events to Guardium System

Guardium System (aka Appliance, Collector)

– Policy definitions

– Hardened hardware or virtual appliance to securely store audit events

– Reporting and audit processes (workflow)

– Alerting

– Analytics


Collection


Audited events collected

Security Guardium S-TAP for DB2 collects and correlates the following types of data

– DML (Data Manipulation Language)

• Modifications(changes) to an object (SQL UPDATE, INSERT, DELETE)

• Reads of an object (SQL SELECT)

– DCL (Data Control Language)

• Explicit GRANT and REVOKE operations

– DDL (Data Definition Language)

• CREATE, ALTER, and DROP operations against an object (such as a table)

– Assignment or modification of an authorization ID

– Authorization attempts that are denied because of inadequate authorization

– Utility access to an object (IBM utilities only)

– DB2 commands entered, including which users are issuing specific commands

– User selected DB2 negative SQL events

– Commits and Rollbacks events (optional - config parm controlled)


Data Gathering

The DB2 S-TAP is responsible for gathering the DB2 SQL requests and filtering those requests against

collection policies that have been established by the Guardium/Audit administrator

– As an SQL statement is processed by DB2, the S-TAP intercept, captures the SQL and a variety of additional fields

to characterize the event for downstream processing

– All SQL statements must be minimally inspected to determine if they are events of interest based on collection

policy

– For all SQL collection, DB2 S-TAP on Z uses the IBM DB2 Data Access Common Collector for z/OS (CQC)

– The DB2 IFI Audit Trace is used for:

• “IBM DB2 Utilities” (Audit Trace class 8)

• “Failed Changed AuthID (IFCID 83 and 87)” and “Successful Translation(IFCID 169 )” (Audit Trace Class 1 –

IFCID 83, 87, 169


IBM DB2 Data Access Common Collector for z/OS (CQC)

IBM DB2 Data Access Common Collector for z/OS is a delivery vehicle for common collector technology

leveraged across multiple IBM offerings

– CQC is a prerequisite product for IBM DB2 Query Monitor for z/OS, IBM Security Guardium S-TAP for DB2 on z/OS

and IBM InfoSphere Optim Workload Replay for DB2 for z/OS


Architecture


Capturing of a SQL Event is comprised of 3 main processing phases

Filtering Phase

Determination if the event is eligible to be

collected

Collection Phase

Collection of the event (buffer allocation, data

field copy, etc.)

Streaming Phase

Streaming(formatting and sending over TCP

connection) of the event to the appliance

Collection overhead/CPU Usage can be minimized by optimizing or avoiding phases

– The filtering phase can be optimized by using Stage 1 filters which minimize filtering overhead

– The Collection and Streaming phases can be avoided completely by excluding the event from the collected

data


Collection Policy (aka Collection Profile Policy)


Filtering performance Stage 1

Once an SQL event is gathered by the SQL intercept, it needs to be inspected and filtered against the

configuration policies that have been established in the collection profiles

Filtering is performed at two levels or “stages”

– The S-TAP will perform filtering very efficiently in the DB2 address space at the point of inspection, using S-TAP

stage 1 compiled filtering

• Stage 1 filtering is the most basic and efficient form of filtering where the user can filter based on all filter fields

except objects

• This filtering is done in the DB2 address space at the point of inspection

– The following fields would be Stage 1 filtering criteria

– CONNTYPE (NET PRTCL) Specifies the appliance connection type to DB2

– Plan Name (APP.USER, PLAN=) Specifies a valid DB2 plan name

– Program Name (APP.USER, PROG=) Specifies a valid DB2 program name

– Primary AUTHID (OS USER) Specifies the original operator user ID that is used to connect to DB2

– Current SQLID (DB USER) Specifies the primary AUTHID that is used for authorization within DB2

– WSNAME (CLIENT INFO, WKSTN=) Specifies a valid user workstation name

– WSTRAN (CLIENT INFO, APPL=) Specifies a valid program (or user workstation transaction)

WSUSER (CLIENT INFO, USER=) Specifies a valid user name


Filtering performance Stage 2

Stage 2 filtering is required for explicit objects

– Any filtering that cannot be done by a stage 1 filter is performed in a stage 2 filter in the S-TAP address space

outside of DB2

• Examples of stage 2 filters are those that operate on an object (such as a table).

• An event that cannot be completely evaluated at stage 1 will need to be moved from the DB2 address space to

the S-TAP address space for stage 2 evaluation

– If all rules in the active collection profile are able to be filtered in Stage 1, then no Stage 2 filtering will occur

– This will result in CPU reduction for the collection and filtering process


Event types and filtering stages

Event type Stage 1 Stage 2

SELECT/UPDATE/INSERT/

DELETE (SUID)

Yes Yes

CREATE/ALTER/DROP Yes No

GRANT/REVOKE Yes No

SET CURRENT SQLID No No

DB2 COMMANDS No No

DB2 UTILITIES Yes

DB User Stage 1 filter is used

No

FAILED LOGINS (83/87) Yes

DB User Stage 1 filter is used

No

NEGATIVE SQLCODEs No No

COMMIT/ROLLBACK No No


Enable collection of specific event types

SELECT/UPDATE/INSERT/DELETE (SUID), CREATE/ALTER/DROP, SET CURRENT SQLID,

DB2 COMMANDS

– Collection is enabled through the presence of a Stage 1 filter or a non-blank wildcard value in the Object

field of the rule

GRANT/REVOKE, DB2 UTILITIES, FAILED LOGINS (83/87)

– Collection is enabled via like entry in COMMAND setting

NEGATIVE SQLCODES

– Collection is enabled through the presence of a negative SQLCODE list

COMMIT/ROLLBACK

– Collection is enabled by setting the COLLECT_COMMIT_ROLLBACK config file parameter to Y


Collection Rule logic

– Collection of SELECT/UPDATE/INSERT/DELETE (SUID) audit events

• The following policy rule fields are and-ed for collection logic









– OBJECT Schema.Table name

– DATABASE


Collection Rule logic

– Collection of CREATE/ALTER/DROP and GRANT/REVOKE audit events

• The following policy rule fields are and-ed for collection









– Collection of DB2 UTILITIES and FAILED LOGINS (83/87) audit events

• Only Current SQLID (DB USER) fields is and-ed for collection

– Collection of SET CURRENT SQLID, DB2 COMMANDS, NEGATIVE SQLCODEs and

COMMIT/ROLLBACK

• Are not filtered by any filter fields for collection


Filtering performance

Most common types of Collection Rules

– Privileged Users for all objects

• Filtering would be done in Stage 1 if only rule

– List of tables containing sensitive data touched by any Users

• Would require filtering to be done in Stage 2



The Compile of the Collection Policy Rules will results in a Stage 1 or Stage 2 filtering ability

– S-TAP provides log messaging to reflect results of the compile

• ADHK101I Compiling filt. Flags1 0xC0; Compile Trace FALSE; Runtime Trace Flag 0x0; Runtime Trace FALSE;

Stage 1 Requested TRUE

• ADHK205I No valid stage zero or stage one filter criteria found

– The STAP command either via console modify command or batch diagnostics job can also provide Filter Stage

• ADHQ3270I STAP INFO: STAGE1 FILTER IS............... ACTIVE

• ADHQ3270I STAP INFO: STAGE2 FILTER IS............... NOTACTIV

– STAP command can also provide us with block count showing Filter Stage used

• ADHQ3270I STAP INFO: TOTAL SQL CALLS DETECTED....... 00000000000006E5

• ADHQ3270I STAP INFO: PASSED STAGE1 FILTERING........ 00000000000006A5

• ADHQ3270I STAP INFO: AUDS BLOCKS QUEUED............. 00000000000000C3

• ADHQ3270I STAP INFO: AUDS BLOCKS PASSED STAGE2...... 0000000000000000

• ADHQ3270I STAP INFO: AUDS BLOCKS SENT TO APPLIANCE.. 00000000000000C3



Using just Rule 1(PRIV USERS) from our example Collection Policy Rules will results in a Stage 1

filtering



Using just Rule 2 (NPI OBJECTS) from our example Collection Policy Rules will results in a Stage 2

filtering



Using both Rules (PRIV USERS & NPI OBJECTS) from our example Collection Policy Rules will

results in a Stage 2 filtering



– NOT best performance


Filtering performance ART-101

If possible we want to modify our NPI OBJECT Rule to results in some work being doing in STAGE 1

To do this we can add a stage 1 filter criteria to rule

– Here we added a NOT list of PRIV USERS to NPI OBJECT Rule

– PRIV USERS rule will pick up any work by these users on NPI tables and make part of NPI OBJECTS rule Stage 1


Filtering performance ART-101

This ‘no collection impact’ change results in both STAGE 1 and STAGE 2 filtering being active

Events are being filtered by stage 1 first then stage 2 results in fewer events being moved to S-TAP

address space for evaluation and less overhead



• ADHQ3270I STAP INFO: TOTAL SQL CALLS DETECTED....... 000000000000B78F

• ADHQ3270I STAP INFO: PASSED STAGE1 FILTERING........ 0000000000007EB3

• ADHQ3270I STAP INFO: AUDS BLOCKS QUEUED............. 0000000000000060

• ADHQ3270I STAP INFO: AUDS BLOCKS PASSED STAGE2...... 0000000000000005

• ADHQ3270I STAP INFO: AUDS BLOCKS SENT TO APPLIANCE.. 000000000000005B

• ADHQ3270I STAP INFO: AUDS BLOCKS NOT SENT TO APPL... 0000000000000000

• ADHQ3270I STAP INFO: AUDS BLOCKS FREED ............. 0000000000000060

• ADHQ3270I STAP INFO: AUDS BLOCKS FREED LOST ........ 0000000000000000

• ADHQ3270I STAP INFO: BYTES SENT..................... 0000000000046DB3


DB Name Filter

Using just DB Name filter will results in Stage 2 filtering

If a DBNAME filter meets certain criteria, an “optimization” can be performed

The optimization allows the event to be filtered post-STAGE1 (but still in in-DB2 processing)

For the optimization to occur, all of the following criteria must be met:

– Every rule has the exact same list of DBNAMES

– The DBNAMES list is either “all include” or “all exclude”

– The DBNAMES in the list must not include wildcards

Message - ADHQ2017I CURRENTLY ACTIVE POLICY RESULTS IN DBNAMES OPTIMIZATION

If any of the criteria isn’t met, the optimization cannot occur, and the DBNAME filtering is deferred until

STAGE2

READ/CHANGE defaults for Data Base selection


How to use DB Name Filter

If you need to audit a number of NPI tables

– Policy rule would list the schema.tables in object field which will results in a lot of Stage 2 filtering

Review your NPI Object list for the Data Bases the tables reside in

– If you find that all these object are in just a few Database consider changing policy rule to use DB list

Balance point is how many additional non-NPI tables are also in these Data Bases

Customer experience has been very positive in reducing overhead using Data Base filter instead of

OBJECT filter


SAMPLE collection policy rules concepts

Exclude CICS activity

– Single rule: Net Prtcl = NOT CICS

– Pro: Stage 1 filter, filtering cpu cost low while potentially having significant impact on removing volume of data

– Con: All other activity flows to appliance which can be significant if CICS activity low

Exclude CICS activity, collect Distributed activity for specific workstations

– Rule 1: Net Prtcl = NOT CICS

– Rule2: Net Prtcl = DRDA, Client Wrkstation = WS%

– Pro: Stage 1 filter, filtering cpu cost low while potentially having significant impact on removing volume of data,

isolate collection of activity further to distributed activity with WS%.

– Con: Activity from other workstations not collected.

Exclude trusted users, Include activity for PLAN=DSNTEP2 and Object(Table) Filter.

– Rule 1: DB User = NOT ADMIN1, NOT ADMIN2, NOT ADMIN3

– Rule2: Object = %/REGION1.RECEIVABLES

– Pro: Structurally simple.

– Con: ALL activity is queued to STAGE2 resulting in significant CPU Usage.


Failed Access / Negative SQL

DB2 S-TAP now collects negative SQL returns codes

– List of codes can be entered into collection rule via FAILURE CODES field

– Only codes listed will be collected

If policy does NOT have an entry/list for field FAILURE CODES

– But does have entry in a policy rule COMMAND field

• “ALL FAILED AUTHORIZATIONS” or “FAILED AUTHID CHANGES”

• negative SQL -551/-552/-553 will be collected


Failed Access / Negative SQL

A policy with only single rule of negative SQL collection will results in disable collection“ADHQ2010I CURRENTLY ACTIVE POLICY RESULTS IN DISABLED COLLECTION”

A policy with multiple rules– Do not recommend a rule with just negative SQL collection selected

• With all other filter fields blank will cases collection of unwanted SQL events

• If your object is to collect only negative SQL events ……

– This can be accomplished by including a no-opt Net Protocol filter of a value of ‘PRIV’ which is valid syntax but is no longer used by DB2

– Effect of this filter value is the exclusion of ALL events for this rule except negative SQL events

Reporting events– Previous releases only collected successful SQL events

– With negative SQL collection STAP may now also collect unsuccessful events

• Negative SQL events are not filtered by any other policy rule fields

– Your may now see events in your standard reports that you think you have not filtered for

• Resolve by cross reference with a “Exception Report” showing “Error Code”


Control collection of HOST Variables

Many customers

– Do not need to collect host variables and want to reduce any performance impact

– Host variables could contain NPI data values that we don’t want ‘externalized’

Defaults:

– Prior to V10 default: host variables were collected by default

– V10 default changed: Will not collect host variables

To include them:

– Specify, on a per-rule basis, whether host variable information will be sent to the appliance for

activity that matches that rule

If no rules in policy request HOST Variables we will see some reduced overhead


Logging Rule and Special Actions


Non Collection rules - Event Logging Rule

After audit events are collected and shipped to the Guardium Collector, the events must be

stored/logged by the Collector

Logging Rule tells the Guardium System what/how to store events

– A Logging Rule requires just a single Access Rule with an ACTION, no other values required.

– ‘DB Type’ can be blank or select value ‘DB2’.

– This rule can be in its own Policy or a rule within the DB2 collection Policy

• This policy rule is needed to tell Guardium System to store the DB2 z audit event data

• ACTION should be any of the below options but Quick Parse Native has least overhead on Guardium

Appliance

– ‘QUICK PARSE NATIVE’

– ‘LOG FULL DETAILS’


Non Collection rules – Rule Action S-TAP Terminate

If an audit event matches a policy rule and that rule’s Action is S-TAP Terminate– S-TAP Provides an API through which the Guardium system can send a request to the S-TAP to cancel an

active DB2 thread

A DB2 CANCEL THREAD command is issued to the DB2 Subsystem by S-TAP as a result of a

request received from the Guardium system S-TAP issues the following message

– ADHG210I A thread termination request was received for thread [thread-token]

S-TAP Started Task ID requires authority to issue CANCEL THREAD command


Non Collection rules – Rule Action S-TAP Quarantine

If an audit event matches a policy rule and that rule’s Action is S-TAP Quarantine

The User of the audit event can be quarantined/denied access to run SQL for:

– A specific DB2 subsystem(s)

– A specified period of time

Note: Quarantine does not take effect immediately – also known as ‘leakage’.

– The SQL statement that produces the event to trigger the quarantine is completed before the quarantine takes effect

The Quarantined User’s SQL executed during quarantine period will receive a -807


Multi-streaming


Multi-stream multi-appliance support

When multi-stream mode is enabled, S-TAP audit events can be spread

over multiple connected appliances.

The maximum number of multi-stream appliances that are supported is six

– (APPLIANCE_SERVER + APPLIANCE_SERVER_n where n can be 1 - 5)

New Parameters in OPTIONS (ADHPARM) member

– APPLIANCE_SERVER_LIST(FAILOVER|MULTI_STREAM|HOT_FAILOVER)

– When APPLIANCE_SERVER_LIST is set to FAILOVER

• only a single appliance connection is active at one time

– When APPLIANCE_SERVER_LIST is set to MULTI_STREAM

• an appliance connection is established for each server listed


z/OS

DatabaseS-TAP

S-TAP load balances events

to different collectors using

a round-robin approach.

Each send of mega buffer is

<=200 events using default

settings

Use aggregation to merge

events for reporting and

analysis

Events C <=200 events

Events A <=200 events

Events B <=200 events

Events D <=200 events

Events E <=200 events

Multi-stream, multi-appliance load distribution

Guardium

Collector

Guardium

Collector

Guardium

Collector

E

E

BA

A B

C

C

D

D

Guardium

Aggregator

© Copyright IBM Corporation 2015. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied.

IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or

representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs,

or services do not imply that they will be available in all countries in which IBM operates. Product release dates and / or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on

market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, and other IBM products and services are trademarks of the

International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.

Statement of Good Security Practices: IT system security involves protecting systems and information through prevention, detection and response to improper access from within and outside your enterprise. Improper

access can result in information being altered, destroyed, misappropriated or misused or can result in damage to or misuse of your systems, including for use in attacks on others. No IT system or product should be

considered completely secure and no single product, service or security measure can be completely effective in preventing improper use or access. IBM systems, products and services are designed to be part of a lawful,

comprehensive security approach, which will necessarily involve additional operational procedures, and may require other systems, products or services to be most effective. IBM DOES NOT WARRANT THAT ANY

SYSTEMS, PRODUCTS OR SERVICES ARE IMMUNE FROM, OR WILL MAKE YOUR ENTERPRISE IMMUNE FROM, THE MALICIOUS OR ILLEGAL CONDUCT OF ANY PARTY.

THANK YOUwww.ibm.com/security

http://www.ibm.com/security

http://www.ibm.com/security


HOT FAILOVER was introduced in DB2 on Z STAP in V10 last year.

Purpose of HOT FAILOVER

– PERSISTANCE, QUICKER SWITCH, SKIP POLICY PUSH on new connection

• At Start up of Agent, Hot Failover will keep the primary connection as well as all

secondary connections active on the appliance

• When Hot Failover is utilized, all data will be sent to the primary connection until it

becomes unavailable. At that time, data will then be sent to the first available

secondary appliance.

• When the primary connection becomes available, the transmission of data will

return to the primary appliance and will no longer be sent to the secondary

appliance.

• Only policies from the primary appliance are used in the S-TAP when Hot

Failover is utilized

FAILOVER


Original SYNTAX

– APPLIANCE_SERVER(hostname|ip_address) STILL PRIMARY SERVER

– APPLIANCE_SERVER_FAILOVER_1(hostname|ip_address)

– Still valid

Both the APPLIANCE _SERVER_FAILOVER_[1-5] and

APPLIANCE_SERVER_[1-5] parameters can be used to designate servers

for multi-streaming or failover

SYNTAX – FAILOVER|HOT FAILOVER|MULTI_STREAM


Newer SYNTAX

– APPLIANCE_SERVER_LIST(MULTI_STREAM|FAILOVER|HOT_FAILOVER)

Example parameter settings to enable multi-stream support:

APPLIANCE_SERVER_LIST(MULTI_STREAM)

APPLIANCE_SERVER(guardium1.company.com)

APPLIANCE_SERVER_1(guardium2.company.com)

APPLIANCE_SERVER_2(guardium3.company.com

All appliance connections defined as hot-failover are LIVE and available for

use, in the event the primary connection fails

SYNTAX – FAILOVER|HOT FAILOVER|MULTI_STREAM


With all settings of APPLIANCE_SERVER_LIST

– if all connections fails, and a spill file is specified (parameter

OUTAGE_SPILLAREA_SIZE), events are buffered to the spill file until a connection

becomes available.

– If no spill file is specified, and all connections are lost, data loss occurs.

SPILLAREA is allocated in MB of DATA SPACE

– Entire value is allocated at startup of Agent

What size should be used?

– Think in seconds or just a few minutes of network outage

OUTAGE SPILLAREA

Documents

S-TAP for DB2 on z/OS V10€¦ · © 2016 IBM Corporation 6 Audited events collected Security Guardium S-TAP for DB2 collects and correlates the following types of data – DML (Data