Using rules for file activity policies

A file activity monitoring policy specifies how Guardium handles different file activity events. Each policy consists of a set of ordered rules. Each rule in a policy defines a conditional action that is taken when the rule matches. The conditional test can be simple, for example a user accesses a specific location, or a complex test that considers multiple conditions. The action ranges from nothing to blocking the event. Multiple grouping and alerting actions can be combined and ordered to create sophisticated responses to matched rules.

Groups

Guardium uses the concept of groups for policy and report creation.

Guardium groups are created and maintained on the Guardium collector or Central Manager. Do not confuse Guardium groups with file system groups.

It is recommended that you consider a naming strategy for your groups, including groups of data sources (file servers), groups of files (such as by sensitivity level or combination of sensitivity level and application), groups of users (a list of all known users, “authorized” users, users with special privileges).

Guardium groups are created and maintained on the Guardium collector or Central Manager. Do not confuse Guardium groups with file system groups.

Rule Guidelines

• A overly broad rule (a rule that monitors too many files) can overload the system and increase processing and response time.
• A FAM rule can have more than one pattern in it. To protect both a directory and its contents, define a rule with two patterns /FAMtest/* and /FAMtest.
• A group comprised of file paths: each path must be unique irrespective of case. For example, these two paths can co-exist in a group: C:\ABC and C:\abcdef. However, these two paths cannot co-exist in a group C:\ABC and C:\abc. The Group builder is not case sensitive. It is not required to input members with all upper case characters or all lower case characters. However, in UNIX, which is case sensitive, the path /IBM/Guardium is different from the path /ibm/guardium. If the user wants to monitor both of these paths, the current Group builder has a limitation and will not see them as two paths.
• The ordering of rules in the security policy is very important. The rules are sent to the S-TAP as a set and are processed strictly in order. Any given user activity is checked against each rule in the policy in order. The first rule that meets the criteria of this file access is applied and subsequent rules are ignored. In most cases, put the most specific rule first and the most general rule last. For example, you have two rules:
  • Rule A: audit only all access to /data/*
  • Rule B: block, log violation and audit user 'joe' from accessing /data/salaries

  If you put Rule A first, and Joe tries to read /data/salaries, there is no need to go to the next rule, and Joe will be audited. If you put Rule B first, Joe is blocked from accessing /data/salaries and there is no need to go to the next rule.

Rule attributes

Rule name

A unique name.

Datasource

The datasource can be:

• Datasource selected from drop-down list
• Group selected from drop-down list
• Group created from selected groups in the Create New Rule window
• Manually entered path

Rule Action

The rule action is the action taken when the criteria are met. Actions are defined for:

• One action for any file access that matches the rule criteria
• Multi-action rule comprised of multiple actions, each one is per a specified command category or a specified group. Note that Continue to next rule is not supported when using Multi-action rules.

The rule actions are:

• Alert and audit: Send an alert directly generated from the sniffer with specific behavior, and log the event.
• Audit only: Log the event in GDM tables
• Block, log violation, and audit: Block access to the object, log a policy violation, and log the event. A blocking action requires an alert configuration as well.
• Ignore: No action taken.
• Log as violation and audit: Log this as a policy violation and log the event.

Notification types

• Email messages: You can specify a Guardium user email, or an external email. Emails are sent using the SMTP server configured for the Guardium system.
• SNMP traps: alerts the trap community configured for the Guardium system.
• Syslog messages: generates messages that are written to the syslog.
• Custom notifications: user-created notification handlers implemented as Java classes.

Rule criteria

For any given file access, rule criteria are used to evaluate whether a particular action should be taken. For any datasource or group of datasources (file servers), the rule criteria that you can specify include:

User: The OS user who is accessing files. This can also be a group of users, as defined in a Guardium group. If this is left blank then the rule applies to all users (except root).

File Path: This can be a Windows or UNIX file path, an individual file path, or a group of file paths, as defined in a Guardium group. This cannot be blank (except when removable media is selected). You can also select to monitor the subdirectories in the file path.

Wild cards in the name specification:

• The '*' character matches any number of any characters
• The '?' character matches one single character
• For UNIX, use back slash to escape * and ?

Tip: Wild cards take extra processing. Excessive use of wild cards impacts performance.

This matches. The file name, FAM.output, matches the name, FAM, and is located in a subdirectory of the given directory '/'.

UNIX

Usage:

• To match all files on disk, enter /*
• To match /tmp/My*File.txt exactly , use /tmp/My\*File.txt
• To match any file with a .txt extension in /tmp, use /tmp/*.txt

Example: The FAM rule pattern is: /FAM*

meaning

• Directory: /
• File name: FAM*

The rule in place has subdirectories selected: (Subdirs: Yes)

The file accessed is: /guardium/modules/SUPERVISOR/10.0.0/FAM.output

Windows: For Windows, you must specify the drive, such as C:\

Usage:

• To monitor all files on the C drive, enter C:\ and mark the Monitor subdirectories checkbox.
• To match any file with a .txt extension in C:\tmp, use C:\tmp\*.txt

GuardAPI examples: create policy with two rules

grdapi create_policy ruleSetDesc=policy1 isFam=true
grdapi create_fam_rule policyName=policy1 ruleName=rule1 serverHost="x.x.x.x" filePath="/famtest/*" command="DELETE" actionName="Alert and Audit" notificationType="SYSLOG"
grdapi create_fam_rule policyName=policy1 ruleName=rule2 serverHost="x.x.x.x" filePath="/famtest/*" command="READ" actionName="Alert and Audit" notificationType="MAIL"

policy1 -> rule1 -> "DELETE" -> "Alert and Audit" -> "SYSLOG"

policy1 -> rule2 -> "READ" -> "Alert and Audit" -> "MAIL"

GuardAPI examples: create policy with multi-Action Rule

Multi-Action Rule for FAM - Multi-action rules are comprised of multiple actions, each one is per a specified command category or a specified group. The commands in a FAM context are: Read, Write, Delete, Execute and File Operation. If the system does not support Multi-Action Rules, it ignores the rule and continues to the next rule.

grdapi create_policy ruleSetDesc=policy1 isFam=true
grdapi create_fam_rule policyName=policy1 ruleName=rule1 serverHost="x.x.x.x" filePath="/famtest/*"
add_action_to_fam_rule policyName=policy1 ruleName=rule1 command="DELETE, READ" actionName="Alert and Audit" notificationType="SYSLOG"
add_action_to_fam_rule policyName=policy1 ruleName=rule1 command="WRITE" actionName="Alert and Audit" notificationType="MAIL"

policy1 -> rule1 -> "DELETE, READ" -> "Alert and Audit" -> "SYSLOG"

policy1 -> rule1 -> "WRITE" -> "Alert and Audit" -> "MAIL"

Adding another action using commandGroupId, assuming commandGroupId=20000 exists, and it has "DELETE, WRITE"

add_action_to_fam_rule policyName=policy1 ruleName=rule1 command="READ" commandGroupId=20000 actionName="Ignore" notificationType=""

policy1 -> rule1 -> "READ, DELETE, WRITE" -> "Ignore"