Snowflake threat modeling: assets, entry points, exit points and shares

1.Cataloging critical assets

A threat model starts with an inventory of what an attacker would want. In Snowflake that is mainly two things: sensitive data, and the identities that can reach it. The documentation states the requirement directly: you need to know where sensitive data is stored and whether it is protected. You don't have to build that inventory by hand. Sensitive data classification finds sensitive data automatically and makes it easy to apply tags and masking policies to it. Snowflake has built-in categories such as name and national identifier, and you can add custom categories for data specific to your organization. Classification is set up and reviewed in the Trust Center.

The resulting tags make the catalog usable by other controls. The Trust Center's AI Security package, for example, looks for columns tagged with system classification tags such as SNOWFLAKE.CORE.PRIVACY_CATEGORY or SNOWFLAKE.CORE.SEMANTIC_CATEGORY. It reports when agents read those columns while no masking or row access policy is in place. Untagged sensitive data is not covered by checks like this.

Privileged roles are critical assets too. ACCOUNTADMIN is the most powerful role in the system and the only one that configures account-level parameters. A compromised ACCOUNTADMIN user is therefore a high-impact threat in its own right. The Trust Center Overview tab summarizes posture: findings from current scanners, secure authentication readiness, data security, and at-risk entities over a selected period. Its scanners report two kinds of finding. Violations are persistent misconfigurations. Detections are one-time events. The rest of this lesson relies on that distinction.

Sources12

2.Documenting entry points and network policies

With the assets cataloged, the next step is to list the ways in. The main inbound paths are connections to the Snowflake service and to the internal stage. Both are open by default: Snowflake accepts connections from any computer or device until a security administrator (or higher) restricts them with a network policy. Each undocumented entry point is effectively an open door.

A network policy does not list IP addresses itself. It refers to network rules, which group related identifiers, and puts them on an allowed list or a blocked list. New policies should use network rules rather than the older ALLOWED_IP_LIST and BLOCKED_IP_LIST parameters. When an identifier appears on both lists, the blocked list wins. Private connectivity rules (types AWSVPCEID and AZURELINKID) take precedence over IPV4 and IPV6 rules when a request arrives over private connectivity.

An allowed list blocks everything else of the same identifier type. You don't need to add the rest to a blocked list. A rule based on a private endpoint has no effect on requests from the public internet, though. If you want to allow only a VPC endpoint, you also need to block public IPv4 explicitly, as in this example:

CREATE NETWORK RULE block_public_access
  MODE = INGRESS
  TYPE = IPV4
  VALUE_LIST = ('0.0.0.0/0');

CREATE NETWORK RULE allow_vpceid_access
  MODE = INGRESS
  TYPE = AWSVPCEID
  VALUE_LIST = ('vpce-0fa383eb170331202');

CREATE NETWORK POLICY allow_vpceid_block_public_policy
  ALLOWED_NETWORK_RULE_LIST = ('allow_vpceid_access')
  BLOCKED_NETWORK_RULE_LIST=('block_public_access');

CREATE NETWORK RULE allow_access_rule
  MODE =  ? 
  TYPE = IPV4
  VALUE_LIST = ('192.168.1.0/24');

Sources3

3.Documenting exit points: egress and unloads

Network policies only control inbound traffic. For outbound traffic, the documentation points to external network access, so egress needs its own entry in the threat model. When a UDF or stored procedure has to reach an external endpoint, an administrator creates a network rule with MODE = EGRESS. The rule has a TYPE such as HOST_PORT or PRIVATE_HOST_PORT and lists the endpoint in VALUE_LIST. If no port is given, Snowflake uses 443. The administrator then includes the rule in an external access integration.

Each rule in the integration names one external location the code is allowed to reach. That makes the integration both the record of the exit point and the control on it. If the function is compromised, it can only reach the hosts the rules list.

Stages are another way data leaves the account. The Trust Center can raise a detection when a large amount of data is transferred to an external stage. Its Sensitive parameter protection scanner reports when PREVENT_UNLOAD_TO_INLINE_URL, REQUIRE_STORAGE_INTEGRATION_FOR_STAGE_CREATION, or REQUIRE_STORAGE_INTEGRATION_FOR_STAGE_OPERATION is changed from TRUE to FALSE. All three are TRUE by default for the best security posture, so switching one off widens an exit path.

Sources45

4.Threat-modeling data sharing configurations

Shares make data available outside the account boundary without any data movement. With Secure Data Sharing, nothing is copied or transferred between accounts. The provider creates a share, grants privileges on objects to it (either directly or through a database role), and adds consumer accounts. Shared objects are read-only for consumers.

That design affects the threat model in both directions. The risk is that grants propagate automatically: a new object added to a share, or a change to an existing one, is immediately visible to every consumer. A table granted to the wrong share is exposed straight away. The advantage is that the provider stays in control and can revoke access to a share or any object in it at any time. Reader accounts let you share with organizations that are not Snowflake customers. Each reader account belongs to the provider that created it and can consume data only from that provider. One gap to record: the Trust Center does not support reader accounts.

Sources6

Exam traps

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

1. 1.A network policy on a user always overrides every other network policy.Why is that wrong?

   A user-level policy overrides the account-level policy, but a policy on a security integration overrides the user-level one.

   Covered in Documenting entry points and network policies

2. 2.Once data is shared, consumers hold a copy, so revoking the share cannot contain an exposure.Why is that wrong?

   Secure Data Sharing copies no data, and the provider can revoke access to a share or any object in it at any time.

   Covered in Threat-modeling data sharing configurations