Monitoring Policies

TrustLogix monitoring policies are used to safeguard your critical data and objects within different data sources like Snowflake, Databricks etc. These policies are designed to help data owners and governors to automatically identify, alert, and respond to suspicious activities, such as unauthorized data access, data exfiltration or account modification.

How TrustLogix Monitoring Works

The monitoring process is designed to be seamless and end-to-end. Once your data source is registered within the TrustLogix UI, the system will automatically create the out of the box monitoring policies which are curated data source specific security policies.

Some of these policies are enabled by default and the others need to be enabled to receive various alerts and notifications. Refer to https://docs.trustlogix.io/integrations/collaboration-tool section on how to configure various tools that can receive these alerts. Once enabled, the TrustLogix monitoring service will continuously scan your meta data and audit data to identify suspicious activities based on your configured policies. Any detected activity is then represented as a data risk, providing you with a clear, actionable alert.

TrustLogix System Policies

The default system-level policies are a great starting point for monitoring your data source. You can find these policies under the "Monitoring Policies" tab for your registered data source. While these pre-configured policies cover a wide range of common security concerns, you have the flexibility to customize them or create entirely new policies to meet your specific organizational needs. The user can also enable or disable this policy from the TrustLogix UI.

Creating a Custom Policy

Creating a custom policy allows you to tailor your monitoring efforts to your most sensitive data and business-critical operations. The custom policy creation flow is broken down into a few key sections.

1. Policy Details

First, provide a unique name and a descriptive purpose for your policy.

• Policy Name: A valid, unique name for your policy. It can contain letters, numbers, underscores or spaces.

• Policy Description: A brief description of what this policy is intended to monitor.

2. Principals and Conditions

This section defines who or what the policy will monitor.

• Principal Type: Select from All, User,User Role ,User IP, User Application. Choosing All monitors all of the Users, IPs, Roles and Applications.

• Condition Type: Specify whether the policy applies In ,Not In , Like or Not Like a defined list.

• List Type: Choose a Allowlist or Specific List. If you choose Specific List, you must enter the exact User names, IP addresses, User Roles or Application names to be monitored.

  • Allow List is prepopulated with some of the trusted applications but you can also add, update or delete them based on your requirement.

  • Specific List for certain principals and data sources will show a drop down of all the different objects in the data source.

3. Monitoring Resources and Actions

This is where you specify the object that you want to monitor as well as the activity types for this particular object.

• Resource Type: Select the type of data source object you want to monitor, such as Account, Database, Schema, Table, View, Privilege, or Role.

• Classification or Specific Names:

  • You can monitor objects based on their classification tags which you can define in the data source using the tagging feature or you can define them in TrustLogix UI (e.g., PII, Sensitive).

  • Alternatively, you can monitor specific object names (e.g., a particular table or schema).

• Action Type: Choose one or more actions to monitor. The available actions depend on the selected resource type (e.g., alter_table, delete, or copy for a Table).

• Data Size: For actions like copy or unload, you can set a data size threshold (in KB, MB, or GB). An alert will only be triggered if the data size involved exceeds this threshold.

4. Alert Management

Configure how and when you want to be alerted.

• Frequency:

  • Only First Occurrence: Triggers a single alert the first time the policy matches a record.

  • For Every Occurrence: Triggers an alert every time the policy matches a record.

  • After N Occurrences: Triggers an alert only after the policy has matched the specified number of times.

• Severity: Set the criticality of the alert to High, Medium, or Low based on business impact.

• Risk Category: Categorize the type of risk the policy addresses, such as Data Exfiltration, Regulatory Compliance, or Misconfigurations.

• Risk Control: Select the risk control for your monitoring policy such as CIS, NIST or GDPR. This is an optional field.

5. Alert Text and Recommendation

Customize the alert message and provide a recommended course of action.

• Alert Text: This message will appear on your "Risk Activities" page. You can use variables to create dynamic messages. For example, a message like "User <username> performed privileged actions on tables classified as <classification> at <occurredOn>" will automatically populate with the relevant details.

• Recommendation: A message that provides remediation or a recommended next step for the corresponding alert.

Data Classification and Allow list

For data sources that do not have the native Tagging or Data Classification capability, TrustLogix allows you to manage Data Classifications and Allow lists directly within the platform.

Data Classification

Data can be classified in two ways:

1. In Snowflake or Databricks platform: Classify objects directly within your data source using Tag capability.

2. In TrustLogix UI: Use the TrustLogix console to add classification tags like PII or Sensitive to different object types.

Allow list

Allow lists are used to define security team approved users, applications, or IP addresses that are not considered "Shadow IT." You can add the following to a Allow list:

• Users (e.g., Bob)

• Applications (e.g., Tableau)

• IP Addresses (e.g., 10.0.0.8 or a range like 10.0.0.8-10.0.0.18)

• Roles (e.g. ADMINROLE)

Adding a principal to a Allow list ensures that actions from that principal do not trigger a policy designed to detect non Allow listed activity.