Guardium for Mainframes is a security and auditing solution that tracks mainframe database activity - including access to sensitive data and unauthorized changes by privileged users - without impacting business processes. In addition to automating and simplifying regulatory compliance, the solution enables proactive, real-time database security by immediately identifying anomalous behavior as well as activities that violate corporate policies, and instantly generating policy-based actions such as security alerts. Guardium for Mainframes allows organizations to further simplify and reduce the cost of their security and compliance processes with a single unified solution for both mainframe and non-mainframe environments.
The Z2000 is similar to the standard G-2000; it has the same UI, and contains all the standard components and applications, such as Groups, Policies, Queries, Reports, Correlation Alerts, etc. The other chapters and books in the manual, describing these standard components are applicable for the Z2000 as well. In addition, the Z2000 integrates with the separately licensed/priced component applications: SOX Accelerator for Compliance, PCI Accelerator for Compliance, Data Privacy Accelerator, Central Manager Application, Archiving extension enablers, and Compliance Workflow Automation.
Guardium for Mainframes consists mainly of:
Z-TAP, a low-impact monitoring service for z/OS developed by NEON Enterprise Software which resides on the mainframe and tracks all database activities at the database level itself.
Z2000, a high-performance, Linux-based appliance developed by Guardium for efficient, off-mainframe analysis and storage of massive amounts of mainframe audit data. The appliance provides sufficient self-contained capacity for online storage of up to 4 billion database transactions with built in purging, archiving and aggregating capabilities to effectively manage the data collected.
Note: For Guardium on mainframe, recognize that a policy can have both z/OS and standard rules. Only z/OS rules and only specific fields within the z/OS rules are passed onto Z-TAP and are used to determine what data will be sent to the Z2000 appliance. Standard rules then define what to do with this data.
In addition to the standard Policy Rules that are analyzed on the appliance, the Z2000 introduces a new rule type that defines a set of filtering requirements, sends these rules to the Z-TAP Agent to be analyzed on the mainframe, and is used to filter database activity before sending data to the Z2000 appliance.
To create an IBM DB2 Z/OS rule:
Open Policy Builder.
See Policies for how to open policy builder or create, modify, clone, remove, and install a policy
Click on the Edit Rules... button to bring up the Policy Rules panel
See Policy Rule Basics for general information on dealing with policy rules
Click on the Add Access Rule... or Add Exception Rule... button to add a new rule or click the Edit Icon on an existing Rule line item to edit the rule individually
The attributes that can be tested for in each type of rule vary, but regardless of the rule type, each rule definition begins with the following four items:
Rule Description - Enter a short, descriptive name for the rule. To use a special pattern test, enter the special pattern test name followed by a space and one or more additional characters to make the rule name unique, for example: guardium://SSEC_NUMBER employee.
Category - The category will be logged with violations, and is used for grouping and reporting purposes. If nothing is entered, the default for the policy will be used.
Classification - Optionally enter a classification in the Classification box. Like the category (above), these are logged with exceptions and can be used for grouping and reporting purposes
Severity - Select a severity code: Info, Low, Med, or High (the default is Info).
Use the drop down box of DB Type to select IBM DB2 Z/OS. This will re-paint the panel for Z2000 - Guardium for Mainframe specific rules
Use the remaining fields of the Rule Definition panel to specify how to match the rule. These fields are used to set up filtering at the source (DB2 database).
Save the Rule
Continue Editing the Policy (Add more rules, change existing ones) - back to step 5
When done - Save the Policy
When this policy is Installed (See Policies), the Z/OS rules are sent to the Z-TAP agent and used to filter database activity before being sent to the Z2000 appliance. It is thus very important that filtering/selection of database traffic be done with care. For instance, a large batch jobs not properly defined in the rules could cause excessive information to be passed through the network and to a Guardium appliance.
For instructions on how to use combinations of groups, individual values, or help with regular expressions see Specify Values and/or Groups of Values in Rules or Regular Expressions for more information.
Note: When entering field values, take into consideration the following tips:
Enter field values in UPPERCASE
Fields with a prompt '<X>/<Y>' usually need to be specified with full specification (i.e. '/' included), and a possible wildcard character of '%' on either side of the '/'. For instance, when specifying a SSID/Group Name, it is best practice to fully qualify SSID, fully qualify Group Name, or use the wildcard '%' to aid in the qualification.
Fields with a prompt '<X>.<Y>' usually need to be specified with full specification (i.e. '.' included), and a possible wildcard character of '%' on either side of the '.'. For instance, when specifying a Creator.object, it is best practice to fully qualify Creator, fully qualify object, or use the wildcard character '%' to aid in the qualification.
Since IBM DB2 Z/OS rules need the fully qualified names ('X/Y' or 'X.Y') and standard rules expect only 2nd variable (the 'Y' in the example given), this means that if you want to use the same object of object group both in the IBM DBs Z/OS rule and in the standard rule, you need to put both the 'X/Y' and the 'Y' in that group.
Client IP - IP address of the client connecting to the database server
Net. Protocol - Network protocol type
SSID/Group Name - This is the DB2 subsystem ID/This is the data sharing group name (if applicable)
Note: In order for Z-TAP and Z2000 to match the rule this field has to be given in its full form: <SSID>/<GROUP-NAME>. For both <SSID> and <GROUP-NAME> the wildcard character '%', can be used as a substitute for part of a full name. Examples:
DGA1/DGA
DGA%/DGA
DGA1/D%
%/DGA
DGA1/%
Providing only SSID will cause Z-TAP to send DB2 traffic, but the rule will never fire.
User ID/SQL ID - This is the system userid/This is the SQLID used to access the data.
Note: This field, like 'SSID/Group Name', needs to be provided in its fully qualified form with or without the wildcard characters '%'. Only fully qualified names (that include '/') will be matched correctly. Following examples are all valid:
NLM1/NLM1
SAS2/NLM1
SAS%/NLM%
%/NLM1
SAS2/%
App. User - This field is currently *NOT* in use and should be left empty. Any value entered in this field will cause the rule to *NOT* fire and produce no results.
OS User - The Operating System user
Job Name - This is the jobname or address space name that is used to access the data.
Field Name - The field name.
Creator.object - This is the creator name and object name for the object being audited.
Note: For this field, either a fully qualified form or just an object name can be used:
user1.table1
%.table1
user1.%
or just:
table1
Command - A specific DB2 command or set of commands. Use the Collect Only drop down box to collect specific group types of DB2 commands. These group types for DB2 commands consist of zOS Audit Commands, Deletes, Dynamic SQL, Inserts, Object Maintenance, Plan/Package Maintenance, Query, Updates, User Authorization Changes, User Maintenance, and Utilities.
The Collect-only selection will be sent to Z-TAP and is used to specify which commands should be sent to a Z2000 appliance.
Command is a standard field and is only used by the Z2000 appliance and has no impact on Z-TAP data filtering. If provided, the Command entered enables a subtler match for the rule but the rule will only fire if the Command is a subset of the Collect-Only selection.
To enable Z-TAP to send multiple command sets, multiple rules need to be defined. For example, to collect INSERTS and DELETES, two separate rules need to be defined, the first specifying 'zOS Audit Inserts' and the second 'zOS Audit Deletes'.
Note: If in Collect Only drop down box 'zOS Audit Dynamic SQL' is selected, the only possible Action is LOG_ONLY.
MVS System - This is the MVS system name where the process that accesses the data is running.
Note: When
specifying the MVS System, the value needs to have a wildcard character
before and after, either one of these
will work %<systemname>% or %system=<systemname>%
For example for a system called SYSA, the 'MVS System' field has to state:
%SYSA% or in a more precise notation %system=SYSA%
For report generation, the system name alone is available as Server Hostname
(in Access domain for example).
DBRM/Package Pattern - This is the name of the DBRM or Package that access the data to be audited
Note:
In order for Z-TAP to correctly send traffic, and filter at the
source, this field has to include the phrase (in lower case) "dbrm_or_package="
must precede the DBRM name and the DBRM or package name must be inside
single quotes and may contain wildcards.
dbrm_or_package='<VALID-DBRM-NAME>'
XML Pattern - A regular expression to be matched, in the Pattern box. You can enter a regular expression manually, or click the (Regex) button to open the Build Regular Expression tool, which allows you to enter and test regular expressions.
Period - To make the rule sensitive to a single time period, select a pre-defined time period from the Period list or click the (Period) button to define a new time period. See Time Periods for more information.
Audit Plan - Mark this checkbox to indicate that the transaction information, including the Plan Name (below), should be monitored.
Plan Name - The plan name that should be matched. It can only be matched if Audit Plan (above) is marked.
Note: The field 'Plan Name' can only be used if there exists at least one rule (not necessarily the one with the specified Plan Name) that has as its action 'LOG FULL DETAILS WITH VALUES'. Otherwise, if this field is not left empty the rule will never trigger.
Min. Ct. - Enter the minimum number of times the rule must be matched before the rule action (described below) will be triggered. The count of times the rule has been met will be reset each time the action is triggered or when the reset interval (also described below) expires. The default of zero is identical to 1, meaning that every time the rule is matched the action will be triggered.
Reset Interval (minutes) - Enter the number of minutes after which the rule counter will be reset to zero. The counter is also reset to zero each time that the rule action is triggered.
Mark the Continue to next Rule box to indicate that when this rule is satisfied and its action is triggered, testing of the same request, exception, or results should continue with the next rule. This means that multiple rules may be satisfied and multiple actions taken based on a single request or exception. If not marked (the default), no additional rules will be tested when this rule is satisfied.
Mark the Rec. Vals. box to indicate that when the rule action is triggered, the complete SQL statement causing that event will be logged and available in the policy violation report (but not anyplace else where the SQL is available). If not marked, the SQL String attribute will be empty. This box will be cleared and disabled whenever either the Allow, Audit Only, or Skip Logging action is selected; it will be marked automatically whenever any of the Alert actions, Log only, or Reset is selected; and it will be cleared automatically when any of the ”Log Full…” actions or the ”Ignore… ” actions are selected.
Select the Action to take when the rule is satisfied. See Rule Actions for additional information.
Note: The action of 'LOG FULL DETAILS WITH VALUES' will cause both the logging of values and the logging of change sets (including every value that was replaced or inserted into the database). Because both before and after values for all records that are affected will be stored, care should be taken when choosing this option as simple commands such as an UPDATE statement can possibly cause many rows to be updated and thus produce a large amount of data to be logged.
If an alert action is specified, the Notification pane opens, and at least one notification type must be defined. For instructions on how to add notifications, see Notifications, in the Common Tools book.
Click the Accept button to save the rule. This closes the Rule Definition panel and returns to the Policy Rules panel.
Note: Extrusion Rules are NOT supported in the Z2000 solution as Z-TAP does not send the returning data to the appliance and therefore extrusion rules cannot work.
In order to enable the Z-TAP support on the Z2000 the user needs to take care of the followings:
Install Z2000 license on the server (see the description of the 'store license' CLI command in the CLI Reference.)
Configure the unit type for 'ztap' support by running the following command in CLI: 'store unit type ztap'
To verify that the Z-TAP support is enabled and to inspect the currently reporting Z-TAPs, follow the procedure outlined below:
Log into the Guardium GUI as the admin user
Click on the Administration Console tab
Click on the S-TAP Control link in the left hand column menu under the Local Taps section to bring up the S-TAP Control panel.
Z-TAP is a type of S-TAP, specific to mainframes. See Configure S-TAPs from the GUI for a detailed description of information within this panel. The only difference in this display (S-TAP Control panel) is the S-TAP Host column, which normally would display the database IP address, displays the SSID of the DB2 database.
Note: You cannot edit inspection engines for Z-TAP on Z2000. On Z2000 the S-TAP Control panel should be used for viewing only. All Z-TAP configuration is to be done through the Z/OS rules. See Add or Edit Rules for IBM DB2 Z/OS for more information for setting up these policies.
Click the Done button when finished viewing.
The S-TAP Status Monitor displays status information about each inspection engine defined on each S-TAP Host. This report is reporting on current status and has no From and To date parameters. For a Z2000 appliance server, the S-TAP Status Monitor will also report on Z-TAPs as well - showing information such as the Z-TAP Host (DB2 SSID), DB Server Type (DB2), Status, Last Response, and Primary Host Name.
Log into the Guardium GUI as the admin user
Click on the Tap Monitor tab
Click on STAP Status to bring up the STAP Monitor Status panel