Understanding ignore actions

Details about how data is handled when using ignore actions in policy rules.

Ignore session

The current request and the remainder of the session will be ignored. This action does not log a policy violation, but it stops the logging of constructs and will not test for policy violations of any type for the remainder of the session. This action might be useful if, for example, the database includes a test region, and there is no need to apply policy rules against that region of the database.

Table 1. Ignore session

Data logged or ignored between client and DB Server/S-TAP	Data sent from DB Server/S-TAP to Collector	Data from Span Port/ Network TAP to Collector
Ignore - SQL commands, SQL errors, Result Sets	Log in/ Log out Sniffer to S-TAP - One signal to S-TAP to stop sending activity for this session. If additional activity is sent by S-TAP, it is ignored at the sniffer level only. Ignore SQL commands Ignore SQL errors Ignore Result Sets	Ignore – SQL commands, SQL errors, Result Sets. SQL commands and errors coming from a Span Port or Network TAP are filtered at the Sniffer.

Ignore S-TAP session

The current request and the remainder of the S-TAP session will be ignored. This action is done in combination with specifying in the policy builder menu screen of certain machines, users or applications that are producing a high volume of network traffic. This action is useful in cases where you know the database response from the S-TAP session will be of no interest.

Table 2. Ignore S-TAP session

Data logged or ignored between client and DB Server/S-TAP	Data sent from DB Server/S-TAP to Collector	Data from Span Port/ Network TAP to Collector
Ignore - SQL commands, SQL errors, Result Sets	Log in/ Log out  Sniffer to S-TAP - One signal to S-TAP to stop sending activity for this session. Additional signals to S-TAP to stop sending activity to this session.	Not Applicable If there is a need to ignore traffic from a Span Port/ Network TAP, use Ignore session instead.

Ignore responses per session

Responses for the remainder of the session will be ignored. This action does not log a policy violation, but it stops analyzing responses for the remainder of the session. This action is useful in cases where you know the database response will be of no interest.

Note: For ignore response per session, since the sniffer does not receive any response for the query or it is ignored, then the values for COUNT_FAILED and SUCCESS are whatever the default for the table says they are, in this case COUNT_FAILED=0 and SUCCESS=1.

Table 3. Ignore responses per session

Data logged or ignored between client and DB Server/S-TAP	Data sent from DB Server/S-TAP to Collector	Data from Span Port/ Network TAP to Collector
Log – SQL commands  Ignore - SQL errors, Result Sets	Log in/ Log out  SQL Commands  Sniffer to S-TAP - One signal to S-TAP to stop sending activity for this session. Additional signals to S-TAP to stop sending activity to this session.	Not applicable This rule action is S-TAP-only implementations.

Ignore SQL per session

No SQL will be logged for the remainder of the session. Exceptions will continue to be logged, but the system may not capture the SQL strings that correspond to the exceptions.

Table 4. Ignore SQL per session

Data logged or ignored between client and DB Server/S-TAP	Data sent from DB Server/S-TAP to Collector	Data from Span Port/ Network TAP to Collector
Ignore - SQL commands Log - SQL errors, Result Sets	Log in/ Log out Sniffer to S-TAP - One signal to S-TAP to stop sending activity for this session. If additional activity is sent by S-TAP, it is ignored at the sniffer level only. Log SQL commands Log SQL errors Log Result Sets, if using extrusion rules	Ignore – SQL commands Log - SQL errors, Result Sets SQL commands are filtered at the Sniffer.

Selective Audit Trail

Use a Selective Audit Trail policy to limit the amount of logging on the appliance. This is appropriate when the traffic of interest is a relatively small percentage of the traffic being accepted by the inspection engines, or when all of the traffic you might ever want to report upon can be completely identified.

It is important to note that Ignore Session rules are still very important to include in the policy even if using a Selective Audit Trail. Ignore Session rules decrease the load on a collector considerably because by filtering the information at the S-TAP level, the collector never receives it and does not have to consume resources analyzing traffic that will not ultimately be logged. A Selective Audit Trail policy with no Ignore Session rules would mean that all traffic would be sent from the database server to the collector, causing the collector to analyze every command and result set generated by the database server.

Table 5. Selective Audit Trail

Data logged or ignored between client and DB Server/S-TAP	Data sent from DB Server/S-TAP to Collector	Data from Span Port/ Network TAP to Collector
Ignore - SQL commands Log - SQL errors, Result Sets	Log in/ Log out Ignore SQL commands, except for those defined by Audit-Only or Log Full Details rules. Log SQL errors Log Result Sets, if using extrusion rules	Ignore – SQL commands Log - SQL errors, Result Sets SQL commands are filtered at the Sniffer.