Thresholds

Thresholds are extensions of Column Access Policies that enable ALTR Administrators to set limits on Snowflake data access, such as limiting the number of values a user can access or limiting the times in which users can run queries against sensitive data. Thresholds can be configured to trigger a variety of actions, from triggering an in-app ALTR notification or completely restricting access to any sensitive data.

How to Create Thresholding Rules in ALTR

Thresholds extend the capabilities of Column Access Policies, so a Column Access Policy must be created first before you can begin using Thresholds.

Thresholds can be created on the Thresholds page, under Data Policy. To create a new threshold, click “Add New”. From here, you can specify:

1. A Name for the Threshold
2. The action to be taken when a threshold is triggered
   Generate Anomaly: This generates a non-blocking notification in ALTR
   Block: this blocks all access to columns to connected to ALTR to the user who triggered the threshold, replacing them with NULL
   Quicksand: Quicksanding is not available for Snowflake. For Snowflake databases, Quicksanding thresholds will have no effect.
3. Rules: These define what triggers the threshold.
   Time-based rules will trigger a threshold when the indicated data is queried at a particular time
   Access-base rules will trigger when a user queries a particular amount of data in a short time
   IP Address-based rules are not available for Snowflake Databases.
4. Locks Affected: Thresholds extend the protection of columnar data in column access policies. By specifying Column Access Policies in this section, the threshold will apply to all columns governed by those policies
5. User Groups: Thresholds can be set up differently for different roles in Snowflake. This section specifies the roles whose access will be governed by the threshold.

Once all of those sections are complete, selecting “Create Threshold” will create the threshold and begin enforcing additional governance on your columnar data.

What Happens When a Threshold is Triggered?

When a threshold is triggered, an “Anomaly” is generated in ALTR. Depending on whether the threshold is configured to block data, this anomaly may not not restrict access to the user who triggered the threshold.

If the Threshold is configured to block access, the user who triggered the threshold will no longer be able to query sensitive data in Snowflake. Any query they run on columns that are connected to ALTR will result in NULL values. This behavior will continue until an ALTR admin resolves the Anomaly.

Is the Threshold is only configured to generate an Anomaly, the user who triggered the threshold will be able to continue querying data in Snowflake.

Once an anomaly is triggered, an admin in ALTR can resolve the Anomaly in the Anomalies page. On this page, an ALTR administrator can easily see which users have triggered thresholds and which threshold they triggered. Closing an open Anomaly is as simple as clicking “Resolve Anomaly” and leaving an optional comment. If the threshold was configured to Block access to data, resolving an anomaly will allow the blocked user to regain access to sensitive data.

How ALTR Enforces Thresholds in Snowflake

ALTR uses a variety of tools and algorithms to enforce thresholds in Snowflake.

Time-Based Thresholds

When ALTR is invoked by Snowflake’s Dynamic Data Masking Policies for columns that are protected by time-based thresholds, a comparison of the current time to the threshold’s rules determines whether or not the threshold is triggered.

Access-Based Thresholds

Snowflake’s Dynamic Data Masking Policies invoke ALTR’s governance engine on every query on connected columns, but before result sets are determined. Because of this, ALTR must estimate the result set to make a governance decision for Access-Based thresholds. This process is called “Predictive Thresholding”.

ALTR’s query parsing engine uses a variety of mechanisms to estimate result set engines, such as parsing of limit stations and cacheing of table row sizes. However, this system may not always be able to accurately predict how many values will be returned by a query before the query executes - especially for more complex queries or if new values have been recently inserted to a table. To ensure that access-based thresholds properly trigger, ALTR monitors Snowflake warehouse activity and triggers the threshold after the query executes in hindsight. Because of this, ALTR is able to properly trigger access-based thresholds even if it was unable to properly predict the result set size before the query executed. This hindsight threshold triggering typically resolves within two minutes of the query completing.

Warning: Due to ALTR’s limited ability to predict the result set size of complex queries, there is a small window of time between query execution and when ALTR is able to access the number of rows returned by the query. Because of this, users violating thresholds may be able to access more data than intended, both on the query triggering the threshold as well as any queries made before ALTR is able to access the query results.

Note: Snowflake sends information about columns accessed to ALTR one-by-one. Because of this, if ALTR determines that a query is going to trigger a blocking Threshold, only the triggering column and other connected columns considered after the column triggering the threshold will be NULLed. ALTR has no control or insight in what order columns are sent by Snowflake for governance decisions, so this may appear random. This only applies to columns triggering a Threshold; any connected columns queried by a user after the trigger a blocking Threshold will always be Nulled.

Troubleshooting and FAQ

1. Why do I have to specify a Lock / Column Access Policy on a Threshold? Why do I have to indicate User Groups separately?
   Thresholds are extensions of Column Access Policies; by specifying Column Access Policies on a Threshold you are able to specify which policy, and therefore which Columns, should be considered by the Threshold.
   Thresholds enable users to specify separate User Groups (Snowflake Roles) from the Column Access Policy they extend so that rate liming and other Thresholding controls can be implemented on a more granular basis.
2. I created an IP Address or Quicksanding threshold and it’s not working.
   ALTR only supports IP Address and Quicksanding thresholds for our legacy databases offerings, not Snowflake. Reach out to support@altr.com if you are interested in learning more about our legacy products.
3. I created a blocking Access-Based threshold, but I was able to query more data than indicated on the threshold.
   ALTR is invoked before result sets are calculated and must estimate the size of the result set. If ALTR is unable to estimate the result set size, or estimates incorrectly, a query might not be blocked. However, once that query result is available in Snowflake’s logs (typically within 2 minutes), ALTR will trigger the threshold and future queries on sensitive columns will be blocked for the user.

‍