Guardium Project Overview

The project scope is to implement the IBM InfoSphere Guardium V11 VM appliances by utilizing the Guardium Installation Manager (GIM) to setup and monitor privileged user activities at ITProSec Toronto data center. During the course of the implementation we completed the following tasks:

ü How to install Guardium Collector and central manager?
ü How to deploy GIM, STAPS etc. for deployment
ü How to create Policies, reports etc. for monitoring
ü Any IBM Guardium links, tuning steps, troubleshooting steps
ü Identified and reviewed Guardium POC implementation and related policies, activities and reports run on the database servers in the project scope
ü Define UAT, Development & Production systems

o Create architecture for each environment.

o Oracle database servers on IBM AIX PSeries Servers

o Database servers on network segregated location

ü Assisted with network considerations to setup and configure the VM machines.

o Database servers on network segregated system

o Build Collectors & Central Manager/Aggregators (CM/Agg). (See, Appliance Specifications)

ü Reviewed and established database monitoring requirements

o Long term storage media and format.

o Guardium Discovery and Classification was installed for future scans.

ü Installed and configured Guardium Collectors, Guardium CM/Agg.

o Production environment was implemented with # Collectors & # CM/Agg. (# primary & #fail over).

o Test/UAT environment was implemented with # Collectors and # CM/Agg.

o # CM/Agg is stand alone Reporting Facility

ü Installed and configured GIM, S-TAP agents and inspection engines for the database servers in the scope.
ü Hold Monitoring Planning Sessions

o Created User Groups based on 51Test requirements planning session.

o Created a System Policies based on 51Test requirements planning session.

o Created a Reports based on 51Test requirements planning session

ü Created system alerts based on 51Test criteria collected during the planning session

ü Verified all reports, alerts and audit processes.

Best Practice

Infrastructure Best Practices:

Document the Deployment and changes: It’s important to document the initial design decisions as well as changes to them as the system and processes mature. Good documentation is essential to maintaining continuity as staff turnover occurs
Create and document processes for patches and upgrades

Guardium provides agent-based and agent-less architecture for monitoring of database assets. Agents support multiple operating systems over the variety of databases and their versions. A clear communication is needed between the IT, DBA and Security teams so that changes / updates to the databases and underlying OSes do not disrupt Guardium operations
Consistent repeatable processes for patching and upgrades ensures smooth continuous operation of Guardium components
Upgrades offer opportunities to improve with new features and functionalities
Create and maintain runbooks to provide consistent operations

Automate Where Possible to reduce operational overhead so that instead of ‘just keeping the lights on’, staff can focus on higher level tasks like compliance and security policy development and monitoring/managing security alerts
Communication plan: There must be a strong communication plan between all Business/App Owners, IT Ops, DB Ops and Sec Ops teams.

In the past, data protection programs were compliance focused and tactical. After years of headlines, breaches, and damaged customer confidence, security has now taken on a strategic data-centric focus.

	Traditional Compliance	Modern Security
Mindset	Reactive Regulatory compliance driven Tactical check-the-box security Perimeter security focus Blocking never implemented	Proactive Security driven Strategic risk-driven security Threat management model Data-centric security focus Blocking capability a ‘must’
Drivers	Privileged user activity monitoring Compliance Post-breach activity Just another tool in the toolbox	All user activity monitoring SOC/SEIM real time alerting Data discovery and classification People, process, and tool driven model Analytics and breach prevention Compliance

DP Maturity Level
The journey follows a maturity model. The IBM Database Audit and Protection Maturity Model follows the structure of the following capability maturity model index. The model provides the basis for organizations to identify gaps for improving the data security environment such as incorporating updated specifications for controls, processes, policies and procedures, and implementing new solutions or improvements to existing ones.

Database security and lifecycle

Regulatory compliance and auditing is only one aspect of database monitoring the database. A complete data security solution considers security monitoring challenges, setting the monitoring goals, data security lifecycle, and infrastructure constraints DAM goes through a lifecycle which includes:

LifeCyber Example 1:

1. Network Discovery (Data Audit & Protection (DP) Owner, Networking Team, Security Team)
2. Data Discovery & Classifcation ( DP Owner, Developers, Business Data Owners)
3. Vulnerability Assessments (DP Owner, System Admin(s), DB Admin(s)
4. DB Activity Monitoring ( DP Owner, SOC Operations, SIEM Operations, Compliance)
5. Blocking (DP Owner, Business Data Owner, Database Administrators)
6. Analytics (DP Owner, Risk, Compliance)

LifeCycle Example 2:

1. Find your sensitive data

In many organizations, it is difficult to know where the sensitive data is located. This is a task that must be automated because the environment is constantly changing as data moves to new databases and unstructured data stores such as HADOOP. To know where your sensitive information is located at any one point of time, you must repeatedly scan for this type of information on a continuous basis.

2. Monitor

After you know where your sensitive data is located, you can set appropriate monitoring and security controls to identify who has been accessing this information. For example, Payment Card Industry (PCI) requirement 10.2.1requires you to verify that all individual access to cardholder data is logged.

3. Analyze

Analyze your environment to understand where gaps are in your security policies. In today’s virtualized world, resources can be quickly allocated and deployed to meet the business needs. It is critical to analyze the data that these new applications embed into your infrastructure. This analysis helps drive the audit requirements to achieve compliance and security controls for these new applications.

4. Audit

Audit is used to validate your processes and procedures to achieve your security goals and identify gaps in the current processes. These goals should include validating the reliability of the information collected; change control processes are in effect; exception reporting is identified and working; archiving and restoring audit data for forensic events; and so on.

5. Assess

Assess your current environment to identify missing patches or configuration issues with your servers. Assess how database infrastructure is being used. For example, is there a security risk because individuals are sharing credentials? Is there a strong password policy in place? After assessing your environment, you must remediate the found issues.

6. Harden

Harden the environment means to close the gaps identified during the assessment phase. For example, we have identified that there is no strong password policy in place to login to the database. During the harden phase, this is corrected. After all of the gaps are remediated, you can tighten up your security policy.

7. Enforce

Enforce means to proactively identify security policies to alert and potentially block access to unauthorized resources. For example, if the only connection to the database is coming from the application server (10.10.10.10), then you can write a security policy to prevent any access from IP Addresses other than 10.10.10.10. This helps secure your environment from known and unknown attacks that are launched from unknown connections (everything other than 10.10.10.10).

Architecture components

From the architecture view, IBM InfoSphere Guardium components can be grouped into appliance and agent:

Appliances

· Collectors: The collector is the appliance used for real-time capture and analysis of the database activity.
· Aggregators: The aggregator appliance is used to off-load reporting activity from the collectors, and to provide consolidated reporting from multiple collectors.
· Central Managers: The central manager (CM) is specialized functionality enabled on an aggregator appliance. The central manager function is used to manage and control multiple Guardium appliances,

Agents

· Software TAP agent (S-TAP®): The S-TAP agent is installed on the database server and is used to monitor and relay the observed activity to the Guardium collector appliance.
· Guardium Installation Manager Agent (GIM): The GIM agent is installed on the database server and is used to facilitate agent installation, update, and configuration modification of agents.
· Change Audit System agent (CAS): The CAS agent is installed on the database server and is used to capture change audit information of configuration files and more on the database server.
· Instance Discovery agent: The instance discovery agent is installed on the database server and is used to obtain database, listener, and port information.

Central manager

The central manager (CM) is specialized functionality enabled on an aggregator appliance. The central manager function is used to manage and control multiple Guardium appliances, referred to as a managed environment. This function provides patch installation, software updates, and the configuration of queries, reports, groups, users, policies, and so on. There can only be one primary CM in a managed environment. In small environments, the aggregator appliance typically serves as both an aggregator and the CM. Whereas in larger environments, the CM runs on an aggregator, which does not perform aggregation, that is, does not receive data from collectors, referred to as a dedicated CM.

Central management

Central Manager is the Guardium appliance that monitor and control other Guardium units in a federated environment. Unmanaged Guardium appliances are referred to as stand-alone units.

Smooth and efficient operation of Central Manager unit is critical to the overall Guardium system performance. This section describes considerations about Central Manager efficiency and maintenance.

Guardium definitions

Central Manager houses most of the definitions of all the units that report to it. When users submit any report, query, or audit process on any managed unit in a federated (centrally managed) environment, definitions of this activity are retrieved directly from Central Manager. Therefore, latency between Central Manager and its managed units can be a contributing factor for potential user interface slowness on the corresponding managed units. Users can use either Central Manager or any of its managed units to modify those definitions. Regardless of the appliance where the definition changes were made, updated content (with an exceptions of Policies and Groups) is immediately available on all the appliances across the federated environment.

Enterprise architecture

CLIENT implementation represents an enterprise architecture for monitoring a numerous databases across multiple data centers and continents. This architecture example consists of many collector appliances and numerous S-TAP agents installed on mainframe and distributed database servers across data centers. The S-TAP agents are configured to capture and send the relevant database activities to the Guardium collectors for analysis, parsing, and logging. The collectors are configured to aggregate activities monitored to the respective aggregator appliance for central reporting. A dedicated Central Manager appliance provides federated management capabilities such as access management, patching, metadata repository, and more.

Appliance types

The Guardium appliance is deployed in one of two types - collector or aggregator. An aggregator can additionally be designated a Central Manger.

Collector

The collector is the workhorse appliance in the Guardium DAM solution and is used for real-time capture and analysis of the database activity. The collector receives and processes monitored-traffic in real-time from the S-TAP agents deployed on the database servers. Think of the collector as a transaction processing system, with potentially high disk I/O, where the “transactions” are the database-user activity being monitored.

Aggregator

The aggregator appliance is used to off-load reporting activity from the collectors, and to provide consolidated reporting from multiple collectors. The aggregator does not collect data from S-TAPs but receives the data from the collectors in a nightly batch file.

The aggregator is optional but recommended if several collectors are deployed. While not typical, an aggregator can receive data from other aggregators to provide enterprise-wide report. This is referred to as second-level aggregation.

Features

Central management

Central Manager is the Guardium appliance that monitor and control other Guardium units in a federated environment. Unmanaged Guardium appliances are referred to as stand-alone units.

Smooth and efficient operation of Central Manager unit is critical to the overall Guardium system performance. This section describes considerations about Central Manager efficiency and maintenance.

Enterprise architecture

Failover S-TAP configuration option:

In this configuration, the S-TAP is configured to register with multiple collectors, but only send traffic to one collector at a time. S-tap in this configuration sends all its traffic to one collector unless it encounters connectivity issues to that collector that triggers a failover to a secondary collector as configured. This is the most widely used S-TAP configuration to date.

Audit level

To determining the amount of data the solution will be processing and logging, you must understand your general audit requirements that then are translated to the audit levels. Audit levels are used as the guidelines for the amounts of data expected to be processed.

Privileged user audit

Audit only specific users and ignore all other connections; the audited users should be a finite list of non-application users (meaning – real people, and not application traffic); In this mode, S-TAP filters many of the sessions and only a small subset of the overall traffic is sent to the Guardium appliance (filtering is done on the session level by S-TAP).

Sensitive object audit

This is also know as “selective audit” that audits only specific database activity; a finite list of sensitive objects, and a finite list of SQL commands (for example, only DDL commands); in this mode, S-TAP sends all the traffic to the collector and the collector inspects all SQL statements and determines whether it is relevant.

Database activity monitoring

Database activity monitoring is the ability to monitor and audit activities into and out of the database server. These events are typically SQL events such as Select, Insert, Update, Delete, Drop, Create, and Alter. However, Database Activity Monitoring has evolved over the years to include more items than just the “activity” into the database. As described auditing requirements, these other areas are important in database activity monitoring as well:

· Blocking capabilities to prevent unauthorized access

· Data discovery and classification to help you locate sensitive data

· Importing external information to enrich the audit reports

· Identifying the “application user” from a pooled database user connection

Monitoring entitlement reports to identify privilege users and high risk accounts that have elevated privileges to sensitive data. Vulnerability assessment to identify gaps in the configuration of the database Server

Vulnerability assessment

Vulnerability assessment (VA) is a critical process in the security of database servers. VA is the process of identifying three types of potential issues:

· Database tier issues

· Operating system (OS) tier issues

· Database user activity in how they are using the database issues

Figure 4-7 shows three types of vulnerability assessment categories. Each one of these categories helps identify potential issues that should be resolved through your audit processes.

Policy

Two (2) Policy Types and Three (3) Policy Rules:

Guardium has two Policy Types:

Non-selective: A non-selective policy logs the following:

· All the client to server access traffic is logged into the collector with minimum granularity.
· All the database exceptions are logged.
· Server to client result sets that have explicit policy rules specified to log.

Selective: A selective policy logs the following:

· Database exceptions
· Client to server access that has explicit policy rules specified to log
· Server to client result sets that have explicit policy rules specified to log

Following figure shows the configuration panel where the selective or the non-selective policy type is defined.

There are three types of Policy Rules (Figure 5-8) (This is different in Version 11)

· Access rules are applied to the database traffic that comes from client to server (accessing the database).
· Exception rules are applied to database exceptions such as failed logins, SQL errors.
· Extrusion rules are applied to database traffic from the database to client (results sets). The database exceptions are excluded.

Performance optimization and tuning

This section discusses the built-in tools available to monitor and analyze the health of all InfoSphere Guardium components. Being able to leverage these tools is not only an essential part of ensuring that your Guardium environment is running smoothly, but can also be used when planning future expansion.

Configuring and interpreting these built-in tools means little if you do not know what corrective steps can be taken when issues are identified. Therefore, this section devotes considerable time discussing the various strategies available to get things running smoothly.

S-TAP optimization and tuning

Beginning in Guardium V9, the primary tool for determining the overall health and performance of S-TAP is the S-TAP Statistics report. The S-TAP Statistics report is based on information collected from both S-TAP and K-TAP on the host server, and can be displayed as an interactive report or as part of an audit process. The information is collected at a configurable interval by the guard stap process.

Creating S-TAP Statistics report

There are no pre-defined reports for S-TAP statistics. There is, however, a new

S-TAP statistics domain for the purpose of creating custom reports. The process

of creating custom reports is not covered in this section. Figure 7-1 shows an example report to get you started.

Figure 7-1 Sample S-TAP Statistics report

Interpreting the S-TAP Statistics report

To properly interpret the S-STAP Statistics report, it first helps to separate the fields in the report that are cumulative versus the fields that are real-time. Cumulative means that the values in the fields are not reset until done manually using a command on the host side - like the odometer in your car. Real-time fields are dynamic and do not required to be reset - like your vehicle’s speedometer.

Real-time values

There two real-time value fields:

System CPU Percent

The System CPU Percent field will be populated with the CPU utilization by all

processes on the host database server. It is useful for showing how busy the

host server is overall.

S-TAP CPU Percent

The S-TAP CPU Percent field is populated with the overall CPU utilization of

S-TAP for the entire system. It is calculated using the pcpu option from the ps

command.

Cumulative values

The cumulative value fields include the following:

· Total Bytes Processed so far

· Total Buffer Init

· Buffer Recycled

· Total Bytes Dropped so Far

· Total Bytes Ignored

· Total Response Bytes Ignored

Possible Performance Issues

Performance Issue 1: Analyzer queue overflow

Figure 7-8 depicts a scenario where a sudden increase in the analyzer rate at 8:43AM begins to overwhelm the sniffer. Note that even before this increase, the Analyzer/Parser appeared to be buffering some data, indicating that this appliance was already operating near its maximum performance.

During this spike in traffic, the Analyzer must start buffering large amounts of data, as shown by the increasing values in the Analyzer Queue Length. At approximately 8:48AM, the Analyzer/Parser buffers are full, and the sniffer begins to drop data as shown in the Analyzer Lost Packets column. This kind of performance issue does not appear to be an isolated incident on this machine, as indicated by the large number of lost packets, which existed prior to this event.

Figure 7-8 Analyzer queue overflow

There are a variety of reasons for issues with the Analyzer Queue overflowing, but the most common reason is that the sniffer cannot cope with the high rate of traffic being monitored. In these cases, you must reduce the amount of traffic being monitored by the appliance using one of these strategies:

Moving some of the S-TAPs to less busy appliances.

· Introducing rules to filter additional traffic. The most effective rule action to achieve filtering is the IGNORE STAP SESSION rule, because the sessions are ignored by the S-TAP itself instead of being sent across the network to the appliance.

· S-TAP load balancing. Sometimes, a very busy database server can overwhelm a collector all by itself. In these cases, it might help to load balance the traffic from this database to two or more collectors.

· Consider using a Selective Audit policy. By default, the collector logs all data sent to it from S-TAPs or Hardware TAPs. A Selective Audit policy changes this behavior by only monitoring the database traffic specified in the policy rules.

Performance Issue 2: Logger queue overflow

Figure 7-9 shows a sudden increase in the logger queue. The analyzer queue is also high but recovers after two minutes. The logger queue is different than the analyzer queue in that it is not circular and will continue to allocate memory until the sniffer reaches the 2.5GB limit. In this report, observe that as the logger queue starts to grow at 8PM, the memory consumed by the sniffer (shown in the memory column) begins to increase by a proportional amount. When the sniffer reaches the 2.5GB limit, it restarts.

Note that after the sniffer allocates memory, it does not release it even if the logger queue recovers. Therefore, it is possible to have a high sniffer memory utilization even if the logger queues are not holding any data.

Figure 7-9 Logger queue overflow

Sniffer restarts due to logger queue overflow is also shown in the collector’s syslog file (/var/log/messages). These messages come in two varieties. The first is a sniffer Memory Allocation Problem, which happens when the logger queues grow very quickly (see Figure 7-10).

Figure 7-10 Sniffer memory allocation problem.

The second type of restart due to logger queue overflow happens when the Guardium “nanny” process, which monitors sniffer memory utilization, detects that the sniffer is dangerously close to the 2.5GB limit and restarts it (see Figure 7-11). Usually, both types of restarts are caused by the same issues, the only difference being the speed at which the sniffer memory grows. Memory allocation problems happen when the sniffer memory grows very quickly, before the nanny process can react.

Figure 7-11 Nanny process killing the sniffer.

There are a few different reasons that can cause the logger queue to grow:

· Too much traffic or an overly aggressive policy with many heavy rules such as Log Full Details. Though the solutions for Analyzer Queue issues can also apply here, most times it may be sufficient to reduce the number of Log Full Details or policy violation rules in the policy, or make such rules less inclusive.

· Another possibility is that the logger may be competing for MySQL resources if there are an excessive number of reports, correlation alerts, or other internal processes running in the background. If your environment includes an Aggregator, consider running daily reports on that appliance instead.

Install Guardium VM Collector Image

Installation on Virtual Appliances

While IBM InfoSphere Guardium can be installed on any VMware product, the VMware ESX server is the recommended platform for a virtual solution.

Notes:

1. Hardware requirements for the virtual solution are restricted to the platforms supported by VMware.

2. When using the virtual solution, Database Activity Monitoring must be done via S-TAP agents.

3. Due to VMware’s performance limitations, it is not recommended to use the virtual solution when monitoring high volumes of database activity. The virtual solution is recommended for smaller environments and for the “Privileged Users Monitoring” audit mode.

Preparations

Preparing for the deployment of the appliance, the network administrator needs to supply:

· IP address for the interface card (eth0), and optionally an IP address for a secondary management interface connection.

· Default router IP address.

· DNS server IP addresses (up to three addresses), and add the new appliance to the DNS server.

· Hostname and domain name to assign to system

· Subnet mask for primary IP address

· (Optional) NTP server hostname.

· (Optional) SMTP configuration information (for email alerts): IP address, port, and if authentication is used, an SMTP user name and password.

· (Optional) SNMP configuration information (for SNMP alerts) the IP address of the SNMP server and the trap community name to use.

Virtual Appliance

The IBM InfoSphere Guardium Virtual Machine (VM) is a software-only solution licensed and installed on a guest virtual machine such as VMware ESX Server.

To install the IBM InfoSphere Guardium VM, follow the steps in Appendix B – How to Create the Virtual Image. A summary of the steps in the appendix is:

· Verify system compatibility

· Install VMware ESX Server

· Connect network cables

· Configure the VM Management Portal

· Create a new Virtual Machine

· Install the IBM InfoSphere Guardium virtual appliance

After installing the VM, return to Step 4, Setup Initial and Basic Configurations on page 6 for further instructions on how to configure the IBM InfoSphere Guardium system.

Setup Initial & Basic Configuration

The initial step should be the network configuration and must be done locally through the Command Line Interface (CLI) accessible through the serial port or the system console.

Enter the temporary cli password you supplied previously.

In the following steps, you will supply various network parameters to integrate the IBM InfoSphere Guardium into your environment, using cli commands.

In the cli syntax, variables are indicated by angled brackets, for example: <ip_address>

Replace each variable with the appropriate value for your network and installation (but do not include any brackets).

Note: Do not change the hostname and the time zone in the same CLI session.

Set the primary System IP Address

The primary IP address is for the ETH0 connection, and is defined using the following two commands:

· Store network interface ip <ip_address>

· Store network interface mask <subnet_mask>

Optionally, a secondary IP address can be assigned, but this can only be done from the GUI after the initial configuration has been performed. The remaining network interface cards on the appliance may be used to monitor database traffic, and do not have an assigned IP address.

Set the Default Router IP Address

Store network routes def <default_router_ip>

Set DNS Server IP Addresses

Set the IP address of one or more DNS servers to be used by the appliance to resolve host names and IP addresses. The first resolver is required, the others are optional.

· Store network resolver 1 <resolver_1_ip>

· Store network resolver 2 <resolver_2_ip>

· Store network resolver 3 <resolver_3_ip>

SMTP Server

An SMTP server is required to send system alerts. Enter the following commands to set your SMTP server IP address, set a return address for messages, and enable SMTP alerts on startup.

· Store alerter smtp relay <smtp_server_ip>

· Store alerter smtp returnaddr <[email protected]>

· Store alerter state startup on

Note: Configuring the SMTP server can also be done via the Guardium GUI (Admin console > Configuration > Alerter)

Set Host and Domain Names

Configure the hostname and domain name of the appliance. This name should match the hostname registered for the appliance in the DNS server.

· Store system hostname <host_name>

· Store system domain <domain_name>

Note: During basic configuration of the appliance, do NOT change the hostname and the time zone in the same CLI session. Change hostname, reboot, login and then change the time zone.

Set the Time Zone, Date, and Time

There are two options for setting the date and time for the appliance. Do one of the following:

Date/Time Option 1: Network Time Protocol

Provide the details of an accessible NTP server and enable its use.

· store system ntp server <ntpserver_name>

· store system ntp state on

Date/Time Option 2: Set the time zone, date and time

Use the following command to display a list of valid time zones:

· store system clock time zone list

Choose the appropriate time zone from the list and use the same command to set it

· store system clock time zone <selected time zone>

Store the date and time, in the format: YYYY-mm-dd hh:mm:ss

· store system clock datetime <date_time>

Note: Do not change the hostname and the time zone in the same CLI session.

Set the Initial Unit Type

An appliance can be a standalone unit, a manager or a managed unit; In addition, an appliance can be set to capture database activity via network inspection or STAP or both. The standard configuration would be for a standalone appliance (for all appliances), and the most common setting would use STAP capturing (only for collectors).

· store unit type standalone all appliances

· store unit type stap for collectors

Unit type standalone and unit type stap are set by default. Unit type manager (if needed) must be specified.

Note: Unit type settings can be done at a later stage, when the appliance is fully operational.

Reset Root Password

Reset your root password on the appliance using your own private passkey by executing the following CLI command (requires access key: „t0Tach‟):

· support reset-password root <N>|random

Save the passkey used in your documentation to allow future Technical Support root accessibility. To see the current pass key use the following CLI command:

· support show passkey root

Validate All Settings

Before logging out of CLI and progressing to the next configuration step, it is recommended to validate the configured settings using the following commands:

· show network interface all

· show network routes defaultroute

· show network resolver all

· show system hostname

· show system domain

· show system clock time zone

· show system clock datetime

· show system ntp all

· show unit type

Reboot the System

Reboot the system to complete the basic configuration. If the system is not in its final location, now is a good time to shut the system down, place it in its final network location, and start it up again. Remove the installation DVD before rebooting the system.

To reboot the system, enter the following command in CLI:

· restart system

The system will shut down and reboot immediately after the command is entered. Upon startup, the system should be accessible (via CLI and GUI) through the network, using the provided IP address and hostname.

Step 5. What to do next

This section details the steps of verifying the installation by logging on to the appliance; setting unit type, installing license keys, and other installations – patches, S-TAPs, Inspection Engines, CAS.

Verify Successful installation

1. Login to CLI - ssh cli@<ip of appliance>

2. Login to GUI - https://<ip of appliance>:8443

Login to the IBM InfoSphere Guardium web-based interface and go to the embedded online help for more information on any of the following tasks.

Set Unit Type

To set up a federated environment, configure one of the appliances as the Central Manager and all the other appliances should be set to be managed by the management unit. See “store unit type” command in the Appendices help book, under the CLI topic

Install License Keys

See System Configuration in the Guardium Administration help book. (Note: in federated environments, license keys are installed only on the Central Manager)

Specific product keys, which are based on the customer’s entitlements, must be installed through CLI or the GUI as described below.

From the GUI:

1. Log in as “admin” to the IBM InfoSphere Guardium console.

2. Navigate to Administration Console -> Configuration -> System

3. Enter the License Key(s) in the System Configuration panel

From the CLI:

1. Log in to the CLI

2. Issue the store license console CLI command to store a new license.

Store license console

3. Copy and paste the new license at the cursor location. Make sure to type an equal sign (=) at end of license code. Press Enter and then CTRL-D.

Install maintenance patches (if available)

Patches can be installed through CLI (see “store system patch” command) or through the GUI. See the Central Patch Management topic in Aggregation and Central Management help book. (Note: in federated environments, maintenance patches can be applied to all of the appliances from the Central Manager)

There may not be any maintenance patches included with the installation materials. If any are included, apply them as described below.

1. Log in to the IBM InfoSphere Guardium console, as the cli user, using the temporary cli password you defined in the previous installation procedure. You can do this by using an ssh client.

2. Do one of the following:

· If installing from a patch CD, Insert the CD into the IBM InfoSphere Guardium CD drive, enter the following command, and skip ahead to step 3:

o store system patch install cd

· If installing from a network location, enter the following command (selecting either ftp or scp):

o store system patch install [ftp | scp]

Respond to the following prompts (be sure to supply the full path name to the patch file):

o Host to import patch from: User on <hostname>: Full path to patch, including name: Password:

If installing using the fileserver function, enter the following command:

o store system patch install sys

3. You will be prompted to select the patch to apply:

Please choose one patch to apply (1-n,q to quit):

o Type the number of the patch to apply, and then press Enter.

4. To install additional patches, repeat steps 2 and 3.

Install S-TAP agents

Install S-TAP agents on the database servers and define their inspection engines

S-TAP is a lightweight software agent installed on the database server, monitors local and network database traffic and sends the relevant information to the IBM InfoSphere Guardium appliance (the collector) for further analysis, reporting an alerting.

To install an S-TAP, refer to the “S-TAP help book” included in the product manuals

To verify that the S-TAPs have been installed and are connected to the IBM InfoSphere Guardium appliance:

1. Log in to the IBM InfoSphere Guardium administrator portal.

2. Do one of the following:

Navigate to the Tap Monitor ->S-TAP tab, and select S-TAP Status from the menu. All active S-TAPs should display with a green background. A red background indicates that the S-TAP is not active.

Navigate to Administration Console ->Local Taps ->S-TAP Control, and confirm that there’s a green status light for this S-TAP

Define Inspection Engines

Define Inspection Engines for network-based activity monitoring.

Install CAS agents

Install Configuration Auditing System (CAS) agents on the database server.

More Information

For more information, go to the following online resources:

o IBM InfoSphere Guardium home page: http://www.ibm.com/software/data/info/guardium/

o Technical Support home page: http://www.ibm.com/software/support/

References

IBM Security Guardium 11.0.0

Latest

Tuesday, May 19, 2020

IBM Guardium V11.0 Project Implementation