Snowflake Incident Detection, Triage and Containment

1.Configuring and testing alerts

Detection inside Snowflake starts with alerts. An alert has three parts: a condition (a query, for example one that counts failed logins), an action (such as sending an email or writing rows to a table), and a schedule that says when the condition is checked. There are two kinds. An alert on a schedule runs every *n* minutes or on a cron expression and checks the condition against all of the data. An alert on new data runs only when rows are inserted, and checks the condition against those new rows only.

Each alert also needs compute. A serverless alert lets Snowflake size the compute, up to the equivalent of an XXLARGE warehouse. The other choice is a virtual warehouse you name. For a security alert that rarely fires, serverless is usually cheaper, because a warehouse-backed alert costs at least one minute of warehouse time even when all it does is send an email.

To create an alert, a role needs EXECUTE ALERT on the account, and only ACCOUNTADMIN can grant that privilege. It also needs either EXECUTE MANAGED ALERT (for serverless alerts) or USAGE on the warehouse, USAGE and CREATE ALERT on the schema, and USAGE on the database. Alerts on new data also need SELECT on the table being watched. The schema owner's part of the grant looks like this:

GRANT CREATE ALERT ON SCHEMA my_schema TO ROLE my_alert_role; GRANT USAGE ON SCHEMA my_schema TO ROLE my_alert_role;

Sources1

2.Monitoring and triaging LOGIN_HISTORY

LOGIN_HISTORY is the main log for authentication events. It holds 365 days of login attempts, but rows can arrive up to two hours late. Keep that delay in mind when you decide how often an alert should poll it. Triage means reading a few columns correctly:

- USER_NAME is NULL: authentication failed before Snowflake could work out who the user was, for example because OAuth client credentials were invalid or a key-pair login named an unknown user. - CLIENT_IP is INTERNAL_SNOWFLAKE_IP/0.0.0.0: usually harmless. Opening a Snowsight worksheet creates one of these login events, and so does a Snowpark Container Services service logging in. - REPORTED_CLIENT_TYPE / VERSION: whatever the client says it is. Snowflake does not verify these values, so never clear an event because of them. - LOGIN_DETAILS: JSON that shows how Snowflake's malicious IP protection classified the source and whether it was blocked. Of the security-tool signals, this is the only one the sources describe. They do not cover the Trust Center. - FIRST_AUTHENTICATION_FACTOR_ID: the ID of the credential that was used. This tells you which key or token to revoke.

Sources2

3.Isolating an affected user

Once a user is confirmed compromised, ALTER USER ... SET DISABLED = TRUE is the strongest single action. It aborts every query and statement the user has running or scheduled, stops them starting new ones, and locks them out of Snowflake. If you need to stop the work but leave the user able to log in, ABORT ALL QUERIES is the narrower option. To end one particular session, call SYSTEM$ABORT_SESSION with its ID. An account administrator can find session IDs under Account » Sessions in the web interface. If a password may have leaked, ALTER USER ... SET PASSWORD with MUST_CHANGE_PASSWORD = TRUE replaces it and makes the user choose a new one at their next web login.

SELECT SYSTEM$ABORT_SESSION(1065153868222);

Sources34

4.Revoking key pairs and access tokens

Programmatic credentials have their own revocation commands. For a named key pair, a normal rotation keeps the old key valid for 24 hours so clients can move over. When the private key may be compromised, set the grace period to zero:

ALTER USER IF EXISTS example_user ROTATE KEY PAIR my_key
  PUBLIC_KEY = 'MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgK...'
  EXPIRE_ROTATED_KEY_PAIR_AFTER_HOURS = 0;

Programmatic access tokens (Snowflake's API-key-style credentials) are revoked with ALTER USER ... REMOVE PAT <token_name>. There is one catch: you cannot revoke a PAT from a session that was itself authenticated with a PAT, so the responder has to sign in another way.

Sources5678

5.Tightening network policies

To block an attacker's IP address, change the network rules. Network rules are schema-level groups of identifiers, and they do not say whether to allow or block anything. That is set by the network policy that lists them. The workflow is: create the rules, create or update a policy that references them, then activate the policy on an account, user or security integration. A policy has no effect until it is activated. If the same identifier appears in both the allowed and blocked lists, the blocked list wins, so you can block one address inside an allowed range:

CREATE NETWORK RULE block_access_rule
  MODE = INGRESS
  TYPE = IPV4
  VALUE_LIST = ('192.168.1.99');

CREATE NETWORK POLICY public_network_policy
  ALLOWED_NETWORK_RULE_LIST = ('allow_access_rule')
   ? =('block_access_rule');

Precedence matters when you scope a response. A user-level policy overrides the account policy, and a security-integration policy overrides both. Tightening only the account policy will not restrict a user who has a looser policy of their own. MINS_TO_BYPASS_NETWORK_POLICY lets a user skip a policy for a set time, but only Snowflake can set it.

Sources9

6.Suspending data sharing

If a consumer account is implicated, or a share is exposing the wrong objects, the provider has three levels of response. Removing the account from the share cuts its access immediately. If that account is added back later, it has to create its database again. Revoking object privileges from the share removes only those objects, and they can be added back without the consumers doing anything. Dropping the share instantly invalidates every database that consumers created from it. To add or remove accounts, the role needs OWNERSHIP on the share and the MANAGE SHARE TARGET privilege. Before you act, SHOW GRANTS OF SHARE lists which accounts have actually created a database from the share.

ALTER SHARE sales_s REMOVE ACCOUNT = org1.consumer1;

Sources101112

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.An alert on ACCOUNT_USAGE.LOGIN_HISTORY catches a malicious login within seconds.Why is that wrong?

   The view can lag by up to two hours, so detection based on it is delayed by up to that much.

   Covered in Monitoring and triaging LOGIN_HISTORY

2. 2.Disabling a user only stops future logins, so queries already running keep going.Why is that wrong?

   SET DISABLED = TRUE also aborts everything the user has running or scheduled.

   Covered in Isolating an affected user

3. 3.Tightening the account-level network policy blocks every user.Why is that wrong?

   A user-level or security-integration policy overrides the account policy, so users with their own looser policy are not affected.

   Covered in Tightening network policies