Prioritizing Entities for Better Security Alerts

Asset and Identity Prioritization

Written by Tammy Truong and Kyle Derevyanik.

Back in September of last year, we shared our approach to Shifting from Detection 1.0 to 2.0 at Snowflake by adopting a security data lake architecture, creating a detection development lifecycle, and implementing Asset and Identity Prioritization + Risk and Entity Based Alerting to reduce alert noise and improve detection fidelity. In this blog post we aim to share specifically how we built and implemented Asset and Identity Prioritization in order to improve security alerts.

As a refresher, Asset and Identity Prioritization (AIP) seeks to assist analysts in identifying which alerts they should work first. Instead of trying to prioritize based on qualitative labels such as “critical” or “high”, analysts can leverage the quantitative risk scores that AIP provides for more rigorous caseload management. Our implementation of AIP helped us with the following initiatives:

1. Entity management framework: A prerequisite to prioritizing assets and identities is centralizing and standardizing those entities in our security data lake.
2. Quantitative risk score: Objective parameters quantify the risk that assets and identities present to the environment.
3. Dynamic risk severity: Quantitative risk scores have severities that dynamically adjust depending on the spread of the risk scores.
4. Standardization in threat detections: A common information model allows us to reference entities and also provide additional context in alerts for analysts i.e host metadata, privilege mappings to environment, etc.
5. Risk and Entity Based Alerting (REBA): AIP sets the foundation for Risk and Entity Based Alerting.

Entity Management Framework

At Snowflake, we have been successful employing an entity-centric approach to detection engineering and we recommend using entities to model things such as endpoints, users, services, and applications. The Entity Management Framework serves as a record of centralized assets and identities. It catalogs and maps contextual information such as unique identifiers, owners, and environment information back to a singular entity or asset. These contextual data points are then leveraged as parameters when determining how much risk an entity has accumulated over a period of time.

Entity Management Framework: Asset

Assets can include but are not limited to endpoints, applications, nodes, workloads, IP addresses, and domains. They are often not performing actions themselves, however, they can be a source of attack or a destination of attack. Asset data can be gathered from several sources of truth.

Some examples of asset data sources:

• Endpoint management solutions: Jamf or Intune
• Cloud providers: AWS, Azure, or GCP
• CI/CD resources: Jenkins
• Code repositories: Github

Identifiers and parameters that can be included in the asset management framework:

Entity Management Framework: Identity

The identity management framework holds information related to the various identities in the environment. Identities can be users, services, or even roles performing actions. Some examples of identity data sources are Workday, cloud environments (AWS, Azure, GCP), Github, and Okta. The identity framework also aggregates different characteristics of an identity based on a single common identifier, such as an email address. This approach is advantageous in situations where a threat actor gains access to a singular account and proceeds to move laterally — we have a common understanding of a persona/identity across different environments which allows an investigator to pivot along with the attacker.

Identifiers and parameters that can be included in the asset management framework:

It is important that both the asset and identity management frameworks are kept up to date to provide reliable and accurate risk assessments.

Quantitative Risk Score

Our entity prioritization algorithms use the parameters from the Entity Management Framework to generate quantitative risk scores for entities. Criticality of an entity is first mapped to scalar values and then is used to appropriately accumulate risk.

Asset Model

Identity Model

Scalar assignment is the main lever to tune the quantitative risk scoring process. For example, the environment parameter for assets can have the following qualitative and quantitative values:

One of the unique risk parameters for identities is the “privilege” score. The privilege score is determined by the sum of all the known permissions and also takes into account the environment for which the identity has access. The permission level and the sensitivity of the applicable environment are related by taking the product of their respective scalars. Privilege levels can vary across systems, so we first bucketed and normalized these levels into: administrator, modify, read-only, and no access. Then, we assigned the appropriate scalar values based on the risk level. Similarly, we bucketed and normalized the different environment categories into: restricted, sensitive, internal-only, and public. Scalar values for the different environment categories are similarly assigned based on the level of risk.

For example, if an employee has modify access in Github and read-only access in AWS, the privilege score for their identity would be 20 as calculated below:

Privilege Score = ∑ Permission Scalar Value * Environment Scalar Value

Once we have all the scalar values for our risk parameters, we can finally calculate the risk score for entities.

We determined that the parameters with adaptive values (like environment) can be incorporated into scoring functions in a straightforward fashion, but incorporating parameters with binary values (like expected) was a little more challenging. If an asset is not expected, does doubling its risk score according to the scalar function make sense? How does that compare to an asset that does not have any security agents enabled? Our strategy to solve the challenges with binary values was calculating the probability of those parameters occurring and then incorporating them back into the algorithm with the adaptive parameters. This way, the binary parameters impact the risk score more appropriately based on an entity’s similarities or differences to the other entities in the environment.

Ultimately, this is how we calculated the entity risk score:

Risk Score = Adaptive Parameter Scalar Values * Probability(Binary Parameter Scalar Values)

The benefits of creating our own entity prioritization algorithm included flexibility and customization. Additionally, the parameters and associated quantitative scalar values can be adjusted or even omitted as business risks change over time. As an example, if publicly exposed assets have been hardened and assessed as low risk to the business, they can be removed from the risk score calculation. Or, if certain business units are very high risk to the organization, business units can be a parameter rather than just contextual data. Privilege and environment buckets can also be as granular as needed.

Dynamic Risk Severity

Since entity risk scores are expected to change, we need a way to understand these scores in a relative sense. The question becomes: is this particular risk score significantly higher or lower in comparison to other scores? We visualized a sample set and the risk distribution was right skewed, meaning that most of the risk scores were consolidated towards the lower end of the risk spectrum with a fewer number of very high risk entities. Based on this understanding of the distribution, we chose to leverage PERCENTILE_CONT to map the entities to risk labels. Using a percentile-based threshold allows for the risk to be dynamic and updated according to the risk of the rest of the population.

There is no strict requirement to dynamically map risk the same way we chose to. We implemented the asset and identity risk score this way for the simplicity of introducing a new system. The raw calculated risk score can be incorporated directly into detectors and they would scale automatically.

Now we have an asset and identity framework that shows what an entity is, what the risk of the entity is with input from the parameters, and how that risk compares to the risk of other entities in the organization.

Asset Prioritization:

Identity Prioritization:

Standardization in Threat Detections

The Entity Management Framework serves as a record of centralized assets and identities for detections and prioritization. Standardizing detectors assists in pulling and surfacing the appropriate assets and identities to be able to reference with the Entity Management Framework. Centralization of entity data also provides analysts with additional context such as IP addresses, host names, and privileges. Both the threat detection and involved entities are inputs to risk and entity based alerting.

Risk and Entity Based Alerting (REBA)

Risk and Entity Based Alerting (REBA) utilizes the entity risk score together with other quantitative parameters extracted from detection metadata such as detection impact, likelihood, fidelity, and threat intelligence sequencing in order to generate alert risk scores.

For a deeper dive into REBA and how we used it to transform and advance threat detection at Snowflake, stay tuned for future blog posts.

If you want to connect to exchange ideas or discuss how others are solving similar challenges please feel free to reach out to Tammy Truong and Kyle Derevyanik.