Snowflake is a fully managed data platform that enables users to store, process, and analyze large volumes of data across their cloud environments. Recently, Datadog’s Security Research Team posted a threat hunting guide to help defenders ensure the security of their Snowflake instances. Now, we’ve released an updated integration for Snowflake that converts many of these threat hunts into proactive detections—developed by our detection engineers and tested by our internal security team—that you can deploy in your environment.

In this post, we’ll outline the out-of-the-box (OOTB) detections in Datadog Cloud SIEM, made available through the updated Snowflake integration, to help you improve security alerting around your Snowflake instance. Then, we’ll discuss how our own security team tuned these detections for our environment, to show some practical examples of how teams can modify the OOTB detections to make them as actionable as possible.

Detect suspicious Snowflake activity with new OOTB detections

To roll out thorough Snowflake detections for our customers, the updated integration ingests the following additional data tables and makes them available in Cloud SIEM:

• External Access History
• Sessions
• Grants to Users
• Access History
• Data Transfer History
• Stages
• Login History
• Query History

The availability of log data from these tables in Datadog enables Cloud SIEM to provide the following OOTB threat detections for Snowflake environments:

Initial access

Use these detections to search for activity that suggest an attacker may have successfully gained access to your Snowflake environment.

• Login from anomalous location
• Login into Snowflake UI via password
• Login into Snowflake UI from proxy or VPN
• New client application sessions
• Known malicious client application sessions

Persistence

Use this detection to identify activity that could indicate an attacker has gained persistent access to your Snowflake environment.

• Admin level grant to user

Credential access

Use these detections to identify potential access of Snowflake credentials by an attacker.

• Snowflake brute-force attack
• Abnormal usage of OAuth tokens

Defense evasion

Use this detection to help you identify activity that could indicate an attacker is attempting to evade established defense protocols in your environment.

• Network policy modified

Collection

Use this detection to search for attempts by a potential attacker to collect data from your Snowflake instances.

• Anomalous data querying by user

Exfiltration

Use these methods to detect activity that could reflect an attacker exfiltrating data from your environment.

• Data stage export to anomalous external cloud bucket
• Data transfer to new location

How we adapted these detections at Datadog

Our OOTB threat detections are intended to get security teams up and running quickly with monitoring the security of their Snowflake instances. But as you use these detection rules, or if your environment has particularly unique security needs, you may find that additional modifications to the detections help you get more value out of them. The Threat Detection Engineering Team at Datadog has adopted many of these OOTB detections and modified them to ensure they are performing well for our own environment. In this section, we’ll walk you through the ways we fine-tuned these detections for our needs. While the needs of your environment will be different, you can use similar methods to flexibly adapt Cloud SIEM’s Snowflake detections.

OOTB rule cloning

As our production detection engineers roll out new detections, we clone the OOTB detections so that we can modify each rule’s query, severity, and runbook according to our environment.

The team manages our rules as code by using Terraform modules. As a result, there are two approaches we take for integrating default rules into our repository:

1. Terraform import: datadog_security_monitoring_default_rule
2. Terraform apply (create): datadog_security_monitoring_rule

With option 1, we’re incorporating the rule as is, without modifications to the severity, runbook, or suppression. However, importing the resource allows us to update the notification rules so that we can adjust how we’re alerted based on the severity of the associated case.

When we use option 2, we’re incorporating the rule with modifications to the name, runbook, severity, and/or suppressions. This allows us to link to the runbook the internal documentation detailing how to respond to signals, adjust the severity based on our environment, and tune the rule to avoid alerting on expected behavior. Modifying the name is a requirement of the Terraform provider, since no two rules can have the same name. (This option essentially creates a new rule, whereas option 1 imports the existing rule.)

Signal correlation rules

After cloning, the team decides if it’s better to use the modified rules independently or chain them together into a signal correlation rule, which combines multiple types of detections (including those with varying severity levels) into a new, more complex rule. This type of rule can improve fidelity without losing the value of a lower-severity signal.

For example, our team has a signal correlation rule that involves the following signals:

• User queries writing excessive data
• User accessing unusual number of databases
• User logins from different location

Excessive data involving these signals can be noisy, especially when the signals are of INFO or LOW severity. However, correlating these rules together can improve the fidelity of lower-severity signals. Our correlation rule generates a HIGH-severity signal if Cloud SIEM finds two or more INFO or LOW severity signals corresponding to these rules, so we know to investigate the emerging pattern of suspicious activity that could signal an attack.

Suppression rules

Suppressions are specific conditions in which you can tell Cloud SIEM not to generate a signal in order to improve the accuracy and relevance of your signals.

For example, relying on the knowledge that all human users can access Snowflake only via SSO, our team was able to use the following query to generate a list of all service accounts in our Snowflake instance:

select
  *
from snowflake.account_usage.users
where deleted_on is null
and (has_password = true or has_rsa_public_key = true);

Using this list, we created a suppression rule that we can attach to detection rules that don’t apply to service accounts, allowing us to filter out noisy signals.

Additionally, we created a suppression rule for IP addresses or users that have successfully logged in in the past, in order to cut down the noise in the “Snowflake brute-force attack” detection by decreasing the likelihood of false positives.

Workflows

You can also increase the value you’re getting from the new Snowflake detections in Cloud SIEM by using Datadog Workflow Automation, which allows you to orchestrate and automate your end-to-end processes. Creating a workflow in Datadog allows you to set specific actions to automatically occur in response to a particular signal or signals.

In our case, we created a workflow that:

1. Parses email addresses from any signal generated by specific Snowflake detections. The workflow uses these email addresses to identify users that triggered “User queries writing excessive data to results” and/or “User queries with an anomalously large number of records” detections.
2. Reaches out to the user associated with that email over Slack to confirm what actions they have taken in Snowflake.
3. If the user confirms that they have taken those actions, then the workflow auto-archives the associated signal, since the behavior was benign.
4. If the user is not found, the user denies having taken the actions, or a timeout occurs, then the workflow creates a notification in the responder team’s Slack channel prompting them to investigate further.

Next steps

If you’re interested in trying some of our OOTB Snowflake detections, here’s how to get started:

• Configure Datadog log ingestion: Use our documentation to help you enable the Snowflake integration. Provide the necessary Snowflake account credentials with appropriate permissions.
• Review and customize detections: Explore the pre-built detections within Datadog for Snowflake. You can customize them to better suit your specific needs and environment by using some of the strategies discussed in this post.
• Set up alerts and notifications: Configure alerts and notifications based on the chosen detections. This will ensure you receive timely warnings when suspicious activity is identified.
• Monitor and refine: Start using Datadog to monitor your Snowflake environment. As you gain insights, you can further refine your detections and alerts for optimal effectiveness.

If you’re new to Datadog, sign up for a free 14-day trial.