IBM Guardium v11.x Admin key terms

A lightweight agent installed on a database server host that captures traffic and reports it to a collector. It monitors local database activity without requiring network taps or span ports.

The Guardium appliance component that receives, parses, and stores audit data from S-TAPs and other sources. It enforces policies and generates alerts locally before forwarding to an aggregator.

A central Guardium appliance that receives audit data from multiple collectors, consolidates it, and runs enterprise-wide reports. It does not directly collect traffic from database hosts.

The Guardium appliance that administers configuration for aggregators and collectors, distributing policies, users, and schedules across the environment. It centralizes management but not necessarily audit data storage.

Any Guardium appliance registered to and controlled by a Central Manager, such as an aggregator or collector. It receives configuration updates and reports status to the central node.

Guardium Installation Manager, the framework that deploys, upgrades, and manages software modules such as S-TAPs and agents on remote hosts. It uses a client on each host that pulls packages from the appliance.

A set of ordered rules that Guardium evaluates against inspected traffic to detect access patterns, enforce logging, and trigger actions. Each rule contains conditions, a severity, and one or more actions.

A single conditional statement inside a policy, combining criteria such as source, object, command, or pattern with an action. Rules are evaluated in order and can log, alert, block, or ignore traffic.

A policy rule type that governs whether a database request is allowed, blocked, or logged based on user, source, object, and verb criteria. It is commonly used for real-time enforcement.

A Guardium component that sits in the database connection path and enforces policy decisions, such as terminating a session when an access rule matches. It enables real-time blocking rather than passive logging.

The collector subsystem that parses captured database protocol traffic into structured records of who accessed what, when, and from where. It feeds those records into policy evaluation and audit storage.

A tracked connection between a database client and server, identified by attributes such as source IP, user, and database. Guardium reconstructs sessions to attribute activity and apply policy consistently.

The detailed statement text captured for audited database activity, stored for investigation and reporting. Verbose capture increases storage needs and is usually scoped to specific rules or objects.

The records of database activity collected by Guardium, including session, statement, and exception details. It is retained according to purge and archive settings and queried through reports.

The scheduled removal of aged audit data from a collector or aggregator to control storage growth. Retention periods are configured per data type and must align with compliance requirements.

The process of exporting aged audit data to external storage before purging it from the appliance. Archived data can be restored for investigations or regulatory review when needed.

The configured policy determining how long each category of audit data remains on an appliance. It balances compliance obligations, investigation needs, and available disk capacity.

A structured query over Guardium audit data that presents findings in tables, charts, or graphs. Reports can be scheduled, exported, and grouped into dashboards for recurring oversight.

The saved configuration of a report, including its data source, selected attributes, filters, and grouping. It determines what data appears and how results are formatted.

A consolidated view combining multiple reports and charts for at-a-glance monitoring. Dashboards are often scheduled for delivery to oversight teams and executives.

A notification generated when a policy rule or threshold condition matches. Alerts can be routed by email, SNMP, syslog, or ticketing integrations and carry a severity for triage.

A classification assigned to a rule or alert indicating the risk level of a match. Severity drives escalation paths, dashboard prioritization, and incident triage decisions.

The workflow of investigating an alert or anomaly, gathering evidence, containing the threat, and documenting resolution. Guardium supports this through alerts, reports, and case tracking.

The end-to-end cycle of defining what to monitor, collecting and reviewing activity, investigating exceptions, and evidencing compliance. It links policy design to reporting and remediation.

A named set of permissions assigned to Guardium users that determines which functions and data they can access. Roles implement least privilege and separation of duties.

A directory service protocol Guardium can use to authenticate users and import group memberships. Integration maps directory groups to Guardium roles for centralized identity management.

Single sign-on, allowing users to authenticate once through an identity provider and access Guardium without separate credentials. It typically relies on SAML or similar federation standards.

The protection of data at rest and in transit using cryptographic algorithms. Guardium encrypts audit data, backups, and communications to prevent unauthorized disclosure.

The lifecycle handling of cryptographic keys, including generation, storage, rotation, and destruction. Proper key management ensures encrypted Guardium data remains recoverable and secure.

Transport Layer Security, used to encrypt communication between Guardium components and between clients and appliances. Certificates must be valid and trusted to avoid connection failures.

A database or application registered in Guardium for monitoring, with connection details and associated S-TAPs. Onboarding a data source defines what traffic is collected and inspected.

The Guardium mechanism for remotely configuring S-TAP behavior, such as which databases to monitor and whether to capture full SQL. Changes propagate from the appliance to the host agent.

The systematic diagnosis of Guardium issues using logs, health checks, and component status. Common areas include S-TAP connectivity, policy mismatches, and storage pressure.

Adjusting Guardium configuration and resources to sustain throughput and responsiveness. Typical levers include buffer sizes, purge schedules, index maintenance, and appliance resource allocation.

A routine verification of appliance and component status, including disk usage, service availability, and connectivity. Regular checks catch degradation before it affects audit collection.

The process of moving Guardium appliances and agents to a newer software version. It requires compatibility checks, backups, and coordinated sequencing across managed units.

An individual account in Guardium with assigned roles and permissions. Local and directory-backed users are managed centrally and audited for administrative activity.