Understanding policies

A security policy contains an ordered set of rules to be applied to the observed traffic between database clients and servers. Each rule can apply to a request from a client, or to a response from a server. Multiple policies can be defined and multiple policies can be installed on a Guardium appliance at the same time.

Each rule in a policy defines a conditional action or several actions. The condition tested can be a simple test - for example it might check for any access from a client IP address that does not belong to an Authorized Client IPs group. Or the condition tested can be a complex test that considers multiple message and session attributes (database user, source program, command type, time of day, etc.), and it can be sensitive to the number of times the condition is met within a specified time frame.

The action triggered by the rule can be a notification action (e-mail to one or more recipients, for example), a blocking action (the client session might be disconnected), or the event might simply be logged as a policy violation.

A policy violation is logged each time that an alert or log-only action is triggered. Optionally, the SQL that triggered the rule (including data values) can be recorded with the policy violation. Policy violations can be assigned to incidents, either automatically by a process, or manually by authorized users (for more information, see Incident Management.
Attention: Correlation alerts can also be written to the policy violations domain (for more information, see Managing correlation alerts).
In addition to logging violations, policy rules can affect the logging of client traffic, which is logged as constructs and construct instances.
  • Constructs are prototypes of requests that GuardiumĀ® detects in the traffic. The combinations of commands, objects and fields included in a construct can be very complex, but each construct represents a specific type of access request. The detection and logging of new constructs begins when the inspection engine starts, and by default continues (except as described) regardless of any security policy rules.
  • Each instance of a construct detected in the traffic is also logged, and each instance is related to a specific client-server session. No SQL is stored for a construct instance, except when a policy rule requests the logging of SQL for that instance, or for a particular client/server session of instances (with or without values).

In addition to controlling the inclusion of SQL in client construct instances, a security policy rule can disable the logging of constructs and instances for the remainder of a session.  

In heavy volume situations, the parsing and aggregating of information into constructs and instances can be deferred by using the Log Flat (Flat Log) option. When used, the production of alerts and reports will be delayed until the logged information has been aggregated.

To completely control the client traffic that is logged, a policy can be defined as a selective audit trail policy. In that type of policy, audit-only rules and an optional pattern identify all of the client traffic to be logged.

Data-monitoring policies are installed from Protect > Security Policies > Policy Builder for Data or from Protect > Security Policies > Policy Installation.
Attention: On a new installation only (not on upgrades), a default policy is installed. It contains one rule, and the policy name is Default - Ignore Data Activity for Unknown Connections.