Guardium’s policy analyzer is a feature that helps you better understand how your policies are functioning. It provides data to help identify frequently fired rules, optimize rule order, and evaluate rule changes. Policy analyzer provides useful data about installed policy rules; it is not  a data simulator.

Policy analyzer became available in v11.0. It works with standalone Guardium systems or managed units in a centrally managed environment. Policy  analyzer  does  not analyze  push-down policies from z/OS S-TAPs, session-level polices, or FAM policies.

This article provides a quick overview of the policy analyzer.

Policy analyzer can run in 2 modes: continuous and ad hoc.

1. Continuous analysis runs continually in the background. It records and evaluates data at predefined intervals and is useful for observing longer-term trends in policy activity.
2. Ad hoc analyses run once, at a time you define, and are useful for evaluating specific policy changes. You can use the time and duration settings to evaluate traffic before and after modifying a policy to better understand the impact of the policy change.

 
You can use one mode or both together to gain a deeper understanding of your policy rules.

For both continuous and ad hoc analyses, the policy analyzer results page is broken into 3 sections. 

• The % fired among transactions for each rule shows how often rules are firing, expressed as a percentage of all transactions evaluated in the specified time frame.  The total may not be 100, since not all transactions result in a rule firing.
• The Top rules (fire count) chart shows the number of times that a rule fired during the analysis.  By default, it shows the top 5 rules based on rule firing count..
• The Details for all policy rules table shows details for each rule: its statistics as well as its  installation order, name, actions and which policy it is a part of.

This result shows that in the last 10 minutes, some rules did not fire at all. For example, rule 1 Failed Login-GDPR Personal Data Log Violation by Admin Users did not fire.  Some rules fired quite frequently. To see which rules fired the most, you can hover on the bars in the Top 5 rules fire count chart on the left. This result may be enough for you to gain some knowledge about your system and provide leads for investigation.

However, historical trends may be important for your analysis. If you need to look at rule behavior over time, you can change the time frame for continuous results, to view how rule fire counts and percentages vary over time. The screenshot below, shows the same system over a 30 minute period rather than just 10 minutes. (Note that the test system uses the default settings of recording data every 10 minutes.  You can change the interval to collect either more or less frequent readings).  

The top rules chart displays the fire counts of the 5 most frequently fired rules by default.  However, If you are interested in analyzing a specific rule (or set of rules) you can change which rules are displayed on the chart. Simply click on the chart name and select the rules of interest from the popup.

If the policy is re-installed during the analysis time period, a dotted vertical line will appear in the chart.

In V11.1, drill down capability on individual rules was added to both the Continuous and ad hoc results.  The drill down view provides information about the specific clients, users, and programs that  triggered the selected policy rule.  To access this drill down, select a rule and then click on Actions > Full SQL log details (or Violation log details if the rule is an exception rule).

On this test system, during the selected time period, only 2 client IP addresses triggered this policy rule. The first client triggered the rule about twice as often as the second. However, the DB user and source program values  are more evenly distributed.

On your Guardium system, you could see that a source program was triggering a rule significantly more than other programs. This could be a sign that the program is a batch program and should not be logged.  Another trend you might see is that a particular user is resulting in a lot of triggered rules. It may make sense to add this user to a group to watch them more carefully.  Alternatively, if that user has approved advanced access privileges, you may want to add that user to an admin group and track their access differently.

We’d love your feedback on this topic – have you used the policy analyzer?  What has it helped you to uncover?