Snowflake Failed Login Attempts and Brute Force Detection Sentinel

Credential stuffing and brute-force attacks against Snowflake accounts are a leading cause of data breaches. Default Snowflake login monitoring requires manual log review. This sentinel automates that detection: every 15 minutes it queries SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY for user/IP pairs with more failed attempts than the configured threshold and immediately dispatches a Slack security alert with the offending user names and source IPs.

How it works

1. query_failed_logins (io.kestra.plugin.jdbc.snowflake.Query) connects over JDBC and retrieves every user/IP combination that accumulated more than inputs.max_failed_attempts failed logins in the past hour.
2. check_brute_force (io.kestra.plugin.core.flow.If) evaluates whether the result set contains any rows.
   • then, alert_slack (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) posts a formatted Slack alert listing each suspicious user name, source IP, and failure count.
   • else, log_no_threats (io.kestra.plugin.core.log.Log) records a clean-check entry for the execution run.
3. The errors block fires a Slack notification if the JDBC query itself fails, ensuring no silent monitoring gaps.
4. A Schedule trigger is preconfigured for every 15 minutes and ships disabled by default.

What you get

• Automated 15-minute polling of Snowflake authentication events.
• Immediate Slack security alerts listing suspicious user/IP pairs and their failure counts.
• Clean audit logs for every sentinel execution, confirming monitoring continuity.
• Failure alerting if the sentinel itself cannot reach Snowflake.

Who it's for

• Security engineers and SOC analysts monitoring Snowflake account access.
• Data platform leads responsible for multi-team Snowflake governance.
• Compliance teams needing audit evidence of continuous login monitoring.

Why orchestrate this with Kestra

Snowflake does not natively push brute-force alerts. Setting up an external SIEM to poll the LOGIN_HISTORY view requires infrastructure, credentials management, and custom logic. Kestra handles all of that declaratively: JDBC connection, parameterised SQL, conditional branching, Slack dispatch, and secret management, with full execution history for compliance review.

Prerequisites

• A Snowflake user with SELECT on SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY (requires the ACCOUNTADMIN or SECURITYADMIN role, or a custom role with the privilege granted).
• A Slack incoming webhook for the security alerting channel.

Secrets

• SNOWFLAKE_PASSWORD: Password for the Snowflake user in inputs.username.
• SLACK_WEBHOOK: Slack incoming webhook URL.

Quick start

1. Store SNOWFLAKE_PASSWORD and SLACK_WEBHOOK in your Kestra namespace secrets.
2. Import the blueprint and set account, username, and max_failed_attempts as needed.
3. Run manually to confirm the JDBC connection and verify the query executes against LOGIN_HISTORY.
4. Enable the Schedule trigger for continuous 15-minute security monitoring.

How to extend

• Add an io.kestra.plugin.scripts.shell.Commands task to call the Snowflake REST API and disable a compromised user account automatically.
• Route critical alerts to PagerDuty or OpsGenie by adding a webhook task in the then branch.
• Persist flagged user/IP rows to a security data lake table for longitudinal threat analysis.
• Widen the detection window by parameterising the DATEADD interval as an additional input.

Links

• Kestra Snowflake Plugin
• Snowflake LOGIN_HISTORY View
• Kestra Slack Plugin
• Kestra If Task